[go-nuts] Re: net/http Http Server - fail with Proxy Protocol header (v1/v2)
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
[go-nuts] Re: net/http Http Server - fail with Proxy Protocol header (v1/v2)
> 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)
proposal: net/tspsock: filter/interceptor - concept with default
implementation for proxyprotocol (v1/v2) · Issue
[go-nuts] Re: net/http Http Server - fail with Proxy Protocol header (v1/v2)
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
[go-nuts] Re: net/http Http Server - fail with Proxy Protocol header (v1/v2)
> 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)
>>>
>>>
>>> proposal: net/tspsock: filter/interceptor - concept with default
>>> implementation for proxyprotocol (v1/v2) · Issue
[go-nuts] Re: net/http Http Server - fail with Proxy Protocol header (v1/v2)
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)
>>
>>
>> proposal: net/tspsock: filter/interceptor - concept with default
>> implementation for proxyprotocol (v1/v2) · Issue #65078 · golang/go
>> (github.com)
>>
>
--
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.
[go-nuts] Re: net/http Http Server - fail with Proxy Protocol header (v1/v2)
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)
>
>
> proposal: net/tspsock: filter/interceptor - concept with default
> implementation for proxyprotocol (v1/v2) · Issue #65078 · golang/go
> (github.com)
>
--
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/4aa1edea-4c34-44ea-80fb-84743443f77en%40googlegroups.com.
