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/916d70e7-4ecc-46ce-b124-1a466dc0d2c4n%40googlegroups.com.
