You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So, in https://howsmyssl.com (jmhodges/howsmyssl), we redirect all incoming requests that don't match the domain www.howsmyssl.com to the correct domain. This captures folks typing in howsmyssl.com and also folks coming in from the howsmytls.com domains that are not yet used, etc.
However, it appears that there are some clients that include the port in HTTPS requests and, on redirect, always re-include the port from the first request's Host header. Those requests will fall into a redirect loop with the above code. For instance, curl will just reuse a user-supplied Host header
$ curl -L -H'Host: example.com:443' https://example.com/
curl: (47) Maximum (50) redirects followed
This has caused a user to create a bug against howsmyssl because certain libraries and tools can't avoid re-including the port and fall into redirect loops.
So, I tried to fix this with routing by adding
m.Handle("www.howsmyssl.com:443/", doSomething)
to the code. However, it seems http.ServeMux will never match the port included in the route and, instead, only uses the incoming URI's host (not the Host header).
One might say to just 404 in the default case, but this will just cause the Host: www.howsmyssl.com:443 requests to 404, instead.
I have a gross hack to strip the port from all incoming requests' Host headers, before it hits the muxer, but this problem seems like one common to a lot of HTTPS services and could be better handled there.
Stripping all ports from Host headers seems ill-advised, but adding ports as a part of the muxer seems like it would work okay.
The text was updated successfully, but these errors were encountered:
Too late for Go 1.5. If this is going to be fixed in a later round, I suggest stripping the port in the (*ServeMux).Handler method just before invoking mux.handler. That is, drop the port in the argument to mux.handler but leave the request alone.
So, in https://howsmyssl.com (jmhodges/howsmyssl), we redirect all incoming requests that don't match the domain www.howsmyssl.com to the correct domain. This captures folks typing in
howsmyssl.com
and also folks coming in from thehowsmytls.com
domains that are not yet used, etc.That is, it uses code like
However, it appears that there are some clients that include the port in HTTPS requests and, on redirect, always re-include the port from the first request's Host header. Those requests will fall into a redirect loop with the above code. For instance, curl will just reuse a user-supplied Host header
This has caused a user to create a bug against howsmyssl because certain libraries and tools can't avoid re-including the port and fall into redirect loops.
So, I tried to fix this with routing by adding
to the code. However, it seems http.ServeMux will never match the port included in the route and, instead, only uses the incoming URI's host (not the Host header).
One might say to just 404 in the default case, but this will just cause the
Host: www.howsmyssl.com:443
requests to 404, instead.I have a gross hack to strip the port from all incoming requests' Host headers, before it hits the muxer, but this problem seems like one common to a lot of HTTPS services and could be better handled there.
Stripping all ports from Host headers seems ill-advised, but adding ports as a part of the muxer seems like it would work okay.
The text was updated successfully, but these errors were encountered: