-
Notifications
You must be signed in to change notification settings - Fork 715
use CONNECT method if request contains upgrade header #211
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
Just had a chance to build and test this and there are 2 things I could see be being a problem.
I have a feeling that the first issue could be a problem for many consuming libraries which I imagine would stop looking for the 101 status code after finding the 200. Perhaps we could try to merger our strategies -- handle upgrade websocket specially but not require a config option? Detailed testing output This PR (#211) -- note the extra HTTP 200 response before the websocket response comes in
My PR (#207) -- uglier code but expected behavior:
Stock tinyproxy (for comparison)
|
hi @dmwilcox, thanks a lot for your helpful review. i added a commit that addresses point 1 of your findings, as for point 2 i don't really have an opinion other than that because we're merely proxying the connection on, no further action should be taken from our side and the recipient should handle anything else. does that make sense ? are there more concerns, eventually regarding possible breakage with other scenarios where an upgrade header is used for other purposes, e.g. HTTP/2.0? |
Hi @rofl0r, are these changes planned to merge? |
@vaneses: yeah, after someone tested it |
Is there any plans to merge this PR? There are some applications that use websockets and don't work behind tinyproxy probably because of this. |
yes, as stated in my last comment, as soon as somebody tests it and reports that it works OK. |
Ok, can I just run it and see if this solves the problem, or do I need to do some more formal testing? |
right, we should also check whether it affects non-websocket use, so maybe you can additionally just use the proxy for your browsing for a day ? |
as this PR is quite old already, i rebased it on current master. |
this should allow using websockets or other upgraded connections on a standard (non-encrypted) proxified HTTP connection. testcase: $ telnet localhost 8888 GET / HTTP/1.1 Host: echo.websocket.org:80 Upgrade: websocket Connection: Upgrade Origin: http://echo.websocket.org Sec-WebSocket-Key: 5KNqfsPZ9m/BbeRlVpf7MQ== Sec-WebSocket-Version: 13
a tri-state connect_method enum was introduced for this purpose. if connect_method is set to CM_UPGRADE, the "HTTP/1.0 200 Connection established" response won't be emitted.
I built this using the master branch and it's working fine for me with Nostr. My regular browsing doesn't appear to be impacted either. |
this should allow using websockets or other upgraded connections
on a standard (non-encrypted) proxified HTTP connection.
addressing #101 , #207
anyone interested in websockets please test and report your findings here.