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, 15. April 2024 um 22:43:50 UTC+2: > > 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/b560cd36-0259-4d68-8cdc-710b72c40294n%40googlegroups.com.
