Really I was unsure whether you can guarantee that the first few bytes of a
TLS "client hello" can never happen to be the ASCII characters P R O X Y
As a binary protocol I think it's unlikely to occur, but I've not
attempted to prove it.
On Friday 26 April 2024 at 02:30:51 UTC+1 Eli wrote
> And whilst HTTP is a text protocol (and can distingush between PROXY and
GET/POST/PUT etc), what about TLS?
Proxy protocol is sent as the first bytes on wire after TCP is established,
not carried via HTTP headers, so it is easily distinguishable from TLS.
I agree with all other points, but w
Ok I got your point
Thanks for the explanation.
I also checked some other well-known HTTP servers an all of them needs to
be configured to pass he proxy protocol (nginx, envoy ) so it seams the
right way to explicit configure the webserver.
Thank you very much!
Brian Candler schrieb am Montag
> My point is that a http server that is using the standard library always
reply with an "HTTP/1.1 400 Bad Request" when the proxy protocol is part
of the tcp package.
That's the correct response, because the request is not compliant with HTTP.
> So the net/http should just handle the http req
Hi,
thanks for the answer, but thats not the point.
I think it's fine to use a library or implement something to add something
to the http layer to parse the proxy protocol.
My point is that a http server that is using the standard library always
reply with an "HTTP/1.1 400 Bad Request" when t
Your answer was given here:
https://github.com/golang/go/issues/65078#issuecomment-1890419683
In other words:
- net/http handles HTTP
- go-proxyprotocol handles the proxy protocol
- you combine the two to get the behaviour you want
Orthogonal pieces which handle their own responsibilities are a G
