I need both versions of a URL to resolve properly, “www.example.com” and “example.com”. Currently only the root domain actually gets redirected as it should (302). The www url ends in a 404.
I need to be able to provide specific causes for the issue to justify changes since that will all be on a production environment, but this is not an area I am terribly familiar with. Please let me know if there is more I can add.
The root domain is setup as a redirect in the web.config.
<rule name="redirect non-www to www" stopProcessing="true">
<match url="(.*)" />
<conditions logicalGrouping="MatchAny">
<add input="{HTTP_HOST}" pattern="^example.com$" />
</conditions>
<action type="Redirect" url="https://www.example.com/{R:0}" redirectType="Permanent" />
</rule>
The www version is pulled in from the database by the backend C# code and the https url is put together there. This is the usual flow for this process and works for all other clients (some domains here include www and some don’t).
subdomain = "https://" + urlRow["DomainMask"].ToString();
return Redirect(subdomain);
We have a CNAME rule setup:
example.com. 0 IN CNAME our.domain.com.
our.domain.com. 0 IN A IP.Address
HSTS is enabled for the root domain “Strict-Transport-Security:max-age=31536000; includeSubDomains; preload”. I understand for to qualify for the preload list you need to redirect in a specific order that we aren’t doing.
We also have this rule in the web.config below the rule listed above.
<rule name="Redirect to https" stopProcessing="true">
<match url="(.*)" />
<conditions>
<add input="{HTTPS}" pattern="off" ignoreCase="true" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" redirectType="Found" appendQueryString="false" />
</rule>
I don’t understand why “www.example.com” would not be hitting this rule and getting updated to “https://www.example.com”. My conclusion is that it is likely failing before web.config rules are being processed. I have compared the “www.example.com” url to the other patterns in the web.config using IIS URL Rewrite module. I did not see any matches that would cause the the http -> https rule to not be reachable.
From what I have read it seems like it might help to put the root domain in the database instead and use our standard flow for that and then have a web.config rule for the www instead. That is just from reading on the [cio.gov site about HSTS Preloading](https://https.cio.gov/hsts/#:~:text=HTTP%20Strict%20Transport%20Security%20(HSTS,to%20a%20website%20over%20HTTPS.) (first step should be http root -> https root), but then again I am not doing all the redirect steps that are required for preloading so that might be incorrect thinking.
If I curl -I www.example.com I get:
HTTP/1.1 404 Not Found
Content-Length: 315
Content-Type: text/html; charset=us-ascii
Server: Microsoft-HTTPAPI/2.0
Date: Tue, 16 Jul 2024 20:54:06 GMT
Connection: close
If I do that same with curl -I https://www.example.com instead I get:
HTTP/2 200
cache-control: no-cache, no-store, must-revalidate
pragma: no-cache
content-length: 53147
content-type: text/html; charset=utf-8
expires: -1
server: Microsoft-IIS/10.0
x-aspnetmvc-version: 5.2
x-aspnet-version: 4.0.30319
x-frame-options: sameorigin
request-context: appId=cid-v1:e753b7a3-4976-4c1b-b66b-855926348c00
access-control-expose-headers: Request-Context
x-powered-by: ASP.NET
referrer-policy: no-referrer-when-downgrade
strict-transport-security: max-age=31536000; includeSubDomains; preload
date: Tue, 16 Jul 2024 23:29:46 GM
Adding a non-https binding sorted the issue out in our case
1