I have a client running SharePoint Server 2019 on IIS10, and they want to redirect http requests to https for one of a few Web apps/Alternate Access Mappings in their environment. So, the web app http://intranet and http://intranet.domain.com should be redirected to https://intranet and https://intranet.domain.com respectively but http://mysites , http://mysites.domain.com and http://CentralAdmin:12345 should not. Similarly, the internal SharePoint IIS sites like Security Token Service which are on host-named URLs like:
http://sp19-app:32843/SecurityTokenServiceApplication/securitytoken.svc
Should be left alone. I have an internal CA-generated cert for https://intranet and a Comodo cert for https://intranet.domain.com in place, with working SharePoint AAMs and IIS bindings, both are working, a full range of URLs can be visited.
Most guides to the IIS URL rewrite, including Ruslan's https://ruslany.net/2009/04/10-url-rewriting-tips-and-tricks/#redirect-https and this well-written one: https://www.namecheap.com/support/knowledgebase/article.aspx/9953/38/iis-redirect-http-to-https and this one: http://www.jppinto.com/2010/03/automatically-redirect-http-requests-to-https-on-iis7-using-url-rewrite-2-0/
grab all URLs on the site with (.*)
What I want to do is only grab and redirect the in-scope ones with this
(intranet)(.)*
or
^(http:\/\/intranet)(.)*
both of which I've tried, and while they don't redirect the critical service apps or MySites URLs, they don't consistently redirect the Intranet URLs either. I've validated all of the affected URLs in regex101.com's testing panel, which they come up looking good in, but is there a possibility that either my regex isn't as hot as I think it is or URL rewrite uses a different implementation of it?
For example, under Conditions, I have dutifully added:
{HTTPS}
pattern: ^OFF$
which to my mind means "If OFF appears at the start of the string, at the end of the string", which is clearly nonsense.
My understanding from reading on the topic is that the purpose of Conditions is to create exceptions, and this one stops HTTPS requests being redirected to HTTPS, which is very sensible.
How it arrives at that using the rule I've added is not clear to me though.
The actual redirect to part is :
https://{HTTP_HOST}{REQUEST_URI}
which seems to be the most sensible, as SharePoint URLs will contain query strings and all sorts of stuff after the ? or &.
URL rewrite is configured on an IIS site-by-site basis, so maybe I'm worrying over nothing and I don't need to modify the regular expression. If that's the case, as I suspect it probably is, I suppose I can just leave it. However, I hate having the solution but not knowing how it works, I'd much sooner be able to confidently write my rules and be certain they'll do precisely what I think they will and why.