You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
HRP is currently overwriting the Host header on the proxied request in all cases (see here). By doing so it makes it impossible for the caller to set its own Host header value.
This is breaking my use-case where I have a reverse-proxy downstream of HRP listening on http://[::1]:4080. The request being made by HRP ends up having Host: [::1], which is incorrect, and there's nothing I can do about it.
As far as I can tell there's no real reason for this header to be being added. The original issue, #18, mentions that it was done to match the go implementation, but if you check the link you'll see that the go implementation is rewriting the Host in the URL, not the header. If someone needs the header to match the proxy URL's host they can set it manually on their request, but I don't believe it should be forced.
I have a branch here where I removed the line which is adding the header (commit), and will be using it for my own projects. It would be great to get this upstreamed though, as it's a fairly severe bug I'd say.
(btw: is this project maintained anymore? It seems to have stalled out)
The text was updated successfully, but these errors were encountered:
HRP is currently overwriting the
Host
header on the proxied request in all cases (see here). By doing so it makes it impossible for the caller to set its ownHost
header value.This is breaking my use-case where I have a reverse-proxy downstream of HRP listening on
http://[::1]:4080
. The request being made by HRP ends up havingHost: [::1]
, which is incorrect, and there's nothing I can do about it.As far as I can tell there's no real reason for this header to be being added. The original issue, #18, mentions that it was done to match the go implementation, but if you check the link you'll see that the go implementation is rewriting the Host in the URL, not the header. If someone needs the header to match the proxy URL's host they can set it manually on their request, but I don't believe it should be forced.
I have a branch here where I removed the line which is adding the header (commit), and will be using it for my own projects. It would be great to get this upstreamed though, as it's a fairly severe bug I'd say.
(btw: is this project maintained anymore? It seems to have stalled out)
The text was updated successfully, but these errors were encountered: