Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

net/http: Host headers with ports never match routes in ServeMux #10463

jmhodges opened this issue Apr 15, 2015 · 2 comments


None yet
5 participants
Copy link

commented Apr 15, 2015

So, in (jmhodges/howsmyssl), we redirect all incoming requests that don't match the domain to the correct domain. This captures folks typing in and also folks coming in from the domains that are not yet used, etc.

That is, it uses code like

m.Handle("", doSomething)
m.Handler("/", redirectToDomain(""))

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:'
 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("", 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: 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.


This comment has been minimized.

Copy link

commented Jun 29, 2015

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.

@rsc rsc modified the milestones: Unplanned, Go1.5Maybe Jun 29, 2015

@jmhodges jmhodges referenced this issue Sep 25, 2015


enforce HTTPS #322

@bradfitz bradfitz modified the milestones: Go1.9, Unplanned Dec 8, 2016


This comment has been minimized.

Copy link

commented Mar 15, 2017

CL mentions this issue.

@gopherbot gopherbot closed this in f1e8803 Mar 24, 2017

@golang golang locked and limited conversation to collaborators Mar 24, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.