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 wanted to mention that. 🙂 > > -eli > > > On Monday, April 15, 2024 at 4:43:50 PM UTC-4 Brian Candler wrote: > > > 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 request like they do without > the proxy protocol. > > Why should it do that? It would mask a configuration error - either that > the upstream device is sending with proxy protocol when it should be > sending plain HTTP, or that the downstream server has not been configured > correctly to interpret the proxy protocol. > > At worst, it would open security problems, when the upstream proxy > *thinks* it is successfully passing along source IP address information, > but the downstream server is ignoring it. > > Can you point to any other well-known HTTP server implementation which > ignores inserted PROXY headers like this? I know that Apache doesn't: you > have to configure each vhost to either use or not use proxy protocol. > > https://httpd.apache.org/docs/2.4/mod/mod_remoteip.html#remoteipproxyprotocol > > And whilst HTTP is a text protocol (and can distingush between PROXY and > GET/POST/PUT etc), what about TLS? > > On Monday 15 April 2024 at 21:06:37 UTC+1 HappyTobi wrote: > > 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 the proxy protocol is part > of the tcp package. > So the net/http should just handle the http request like they do without > the proxy protocol. > If someone needs to parse the proxy protocol, it's fine to implement or > add a 3rd party lib, but I think the "default" should just work. > > Brian Candler schrieb am Montag, 15. April 2024 um 20:41:50 UTC+2: > > 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 Good > Thing™ IMO. > > If you want to wrap this up in a library which has the same API as > net/http but implements proxy protocol, you are free to do so (and publish > it, if you wish). However, there is a very high bar for putting > functionality into the core Go library, because the backwards compatibility > promise means it has to be supported forever. > > > I have previously posted two issues on this topic, but neither has been > accepted > > I think that answers your question. > > On Monday 15 April 2024 at 17:47:24 UTC+1 HappyTobi wrote: > > Dear Gophers, > > I would like to bring to your attention. > There is an “issue” with the Go standard implementation when handling HTTP > requests that are extended by the proxy protocol v1 or v2. > > While the simple HTTP server works fine with regular requests, it fails > when a proxy protocol is added. > > > Example: > > Simple http server: > > *package* main > > > > *import* ( > > "*fmt*" > > "*net/http*" > > ) > > > > *func* hello(*w* http.ResponseWriter, *req* ***http.Request) { > > fmt.Fprintf(w, "*hello world**\n*") > > } > > > > *func* main() { > > http.HandleFunc("*/hello*", hello) > > http.ListenAndServe("*:8080*", *nil*) > > } > > The server is working fine when you do something like: > > curl -kv http://*localhost:8080/hello* > > > > But the implementation is failing when you add a proxy protocol (v1) to > the tcp request. > > curl -kv *--*haproxy-protocol http://*localhost:8080/hello* > > > > The issue arises because the implementation fails to read the HTTP > message, as the message starts with the proxy protocol. > Go read request function: > https://github.com/golang/go/blob/91c04826723a10f6778a935e743a34de81312489/src/net/http/request.go#L1068 > > > The proxy protocol is widely used, and it would be beneficial for the Go > standard implementation to handle such requests. > > > > I have previously posted two issues on this topic, but neither has been > accepted. I would like to open a discussion on this topic and work towards > implementing a solution that could be merged into the Go standard library. > Your input and feedback is more than welcome! > > Thank you all. > > > > Github issue links that I posted: > > net/http: Http Server (request) is not working with enabled Proxy Protocol > · Issue #64365 · golang/go (github.com) > <https://github.com/golang/go/issues/64365> > > proposal: net/tspsock: filter/interceptor - concept with default > implementation for proxyprotocol (v1/v2) · Issue #65078 · golang/go > (github.com) <https://github.com/golang/go/issues/65078> > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/4e914729-9d97-4822-83e6-6bceee907b2cn%40googlegroups.com.
