obtuse trellis
im running a go webserver that gets interacted with by a client that does not send a "Host" header and also uses http version 1.1 (what is technically against the RFC), this throws an error 400, i already figured out that the error comes from the ``readRequest` function inside "server.go" what is part from the net/http module.
Yes, i am aware that this is not intended, but i do not have control over the client.
stoic cedar
The Go stdlib HTTP server does not care about the host header, and supports HTTP 1.1
could you show your code and the error that you're getting
obtuse trellis
the error is:
400 Bad Request: missing required Host header
it comes from here:
https://github.com/golang/go/blob/master/src/net/http/server.go#L1022
it can be triggered using curl like this:
curl "http://localhost:37215/" -H "Host:"
or just not sending a Host header at all
stoic cedar
Agh Ok, I stand corrected
RFC 7230 is extremely clear:
A client MUST send a Host header field in all HTTP/1.1 request messages.
A server MUST respond with a 400 (Bad Request) status code to any HTTP/1.1 request message that lacks a Host header field
yea so everything is "fine" on go's side and it does follow the RFC as expected, but my client doesn't that i don't have control over
stoic cedar
Personally... I'd probably stick it behind a reverse proxy that adds a host header
There's no good way of monkey patching the stdlib for this
The reason I'd do it behind a reverse proxy, is it's highly likely I'd be running a reverse proxy anyway, and not exposing the server directly to the internet
obtuse trellis
i've took a look at the conntrack option as well, but there seems to be no way to "inject" into a stream either
(i.e. parse the host header before and "replace" it with a fixed one)
running a reverse proxy would be quite sub optimal for me sadly
stoic cedar
You could look at libraries or frameworks that don't use the stdlib http stack but I'm not sure how reliant other frameworks are on it for basic request parsing
obtuse trellis
ended up patching directly in the sdk code for now until i find a better solution/move to other web framework
tulip vapor
yea so everything is "fine" on go's side and it does follow the RFC as expected,...
talk to your client deeply then
he/she just trying to use protocol without recognize it