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
I implemented an HTTP proxy server in Go using the net/http package. The server is supposed to handle and forward incoming requests without modifying them. The proxy server encountered a specific scenario where incoming HTTP requests have a double slash ("//") at the beginning of their path, for instance, //PAM-OAuth/oauth2/token.
What did you expect to see?
I expected the Go net/http library to forward the incoming requests as is, preserving their original form including the HTTP method, the path with the double slash and all request parameters.
What did you see instead?
What I observed was the HTTP request's method was inadvertently changed from POST to GET during the proxying process, and the request path was altered from //PAM-OAuth/oauth2/token to /PAM-OAuth/oauth2/token (removing the double slash). Moreover, the request parameters were lost during this process, leading to a failed request when it reached the final destination server.
I understand that the net/http package may be trying to sanitize the request path by removing the double slash. However, in the context of a proxy server, this automatic alteration of the request details leads to unintended consequences and erroneous behavior.
To resolve this issue, I propose adding an option to disable this automatic sanitization or clean-up in the net/http package, especially in proxy server scenarios. This would ensure that the incoming HTTP requests are faithfully forwarded as they are, without any alterations to the request method, path, or parameters.
Please consider this proposal as it would significantly improve the usability and robustness of the Go net/http package in handling complex real-world scenarios such as proxy server implementations.
I look forward to your feedback and am happy to provide any further details or clarifications as needed.
The text was updated successfully, but these errors were encountered:
“If permitted, a 301, 302, or 303 redirect causes subsequent requests to use HTTP method GET (or HEAD if the original request was HEAD), with no body. A 307 or 308 redirect preserves the original HTTP method and body, provided that the Request.GetBody function is defined.”
Where this comes into play on the server side is with path cleaning in (*ServeMux).Handlerhere. If the path is not clean, it is implicitly redirected using code 301, not the method-preserving equivalent code 308.
But that makes me wonder: should ServeMux.Handler just be changed to use code 308 instead of 301 unconditionally?