Skip to content

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.

Sign up for GitHub

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

Jump to bottom
Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

use CONNECT method if request contains upgrade header #211

wants to merge 2 commits into from

Conversation

rofl0r
Copy link
Contributor

@rofl0r rofl0r commented Nov 20, 2018

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.

This was referenced Nov 20, 2018
Closed
Open
@dmwilcox
Copy link

dmwilcox commented Dec 29, 2018 •
edited
Loading

Just had a chance to build and test this and there are 2 things I could see be being a problem.

  1. because this uses the CONNECT code path it returns a 'HTTP/1.0 200 Connection established' response to the client -- even though the client never used CONNECT and thus may not be expecting it.

  2. I read RFC2616 as saying that Upgrade headers are for the immediate hop only. I may be misinterpreting and don't claim to understand all of the potential risks of passing them -- which is why I gated my work in PR WIP: Allow http upgrades w/o using connect method. #207 behind a config flag. You and the tinyproxy crew are much more likely to know the trade-offs and I defer to you on that -- but I wanted to point it out and ask if I'm not understanding it correctly.

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

$ nc -C 10.137.0.14 3128
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

HTTP/1.0 200 Connection established
Proxy-agent: tinyproxy/1.10.0-git-3-gf44d0f3

HTTP/1.1 101 Web Socket Protocol Handshake
Connection: Upgrade
Date: Fri, 28 Dec 2018 23:42:33 GMT
Sec-WebSocket-Accept: cBcVi9h4CSNKbf1RoRJaSJVUwis=
Server: Kaazing Gateway
Upgrade: websocket

My PR (#207) -- uglier code but expected behavior:

$ nc -C 10.137.0.14 3128
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

HTTP/1.0 101 Web Socket Protocol Handshake
Via: 1.1 tinyproxy (tinyproxy/1.10.0-git-3-gf44d0f3)
Upgrade: websocket
Sec-WebSocket-Accept: cBcVi9h4CSNKbf1RoRJaSJVUwis=
Connection: Upgrade
Date: Sat, 29 Dec 2018 00:05:36 GMT
Server: Kaazing Gateway

Stock tinyproxy (for comparison)

$ nc -C 10.137.0.14 3128
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

HTTP/1.0 400 WebSocket Upgrade Failure
Via: 1.1 tinyproxy (tinyproxy/1.10.0-git-3-gf44d0f3)
Content-Length: 77
Server: Kaazing Gateway
Date: Fri, 28 Dec 2018 23:51:15 GMT
Content-Type: text/html

<html><head></head><body><h1>400 WebSocket Upgrade Failure</h1></body></html>

@rofl0r
Copy link
Contributor Author

rofl0r commented Dec 29, 2018

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?

@vaneses
Copy link

vaneses commented Jun 25, 2019

Hi @rofl0r, are these changes planned to merge?

@rofl0r
Copy link
Contributor Author

rofl0r commented Jun 25, 2019

@vaneses: yeah, after someone tested it

@SPascareli
Copy link

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.

@rofl0r
Copy link
Contributor Author

rofl0r commented Nov 4, 2019

Is there any plans to merge this PR?

yes, as stated in my last comment, as soon as somebody tests it and reports that it works OK.
you could be the one, @SPascareli

@SPascareli
Copy link

Ok, can I just run it and see if this solves the problem, or do I need to do some more formal testing?

@rofl0r
Copy link
Contributor Author

rofl0r commented Nov 5, 2019

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 ?

@rofl0r rofl0r mentioned this pull request Dec 18, 2019
Closed
@rofl0r
Copy link
Contributor Author

rofl0r commented Apr 16, 2021

as this PR is quite old already, i rebased it on current master.
we still need a volunteer who tests this for both upgrade/websocket and regular browsing scenarios.

rofl0r added 2 commits May 2, 2022 14:22
@rofl0r
use CONNECT method if request contains upgrade header
6057ffc 
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
@rofl0r
connection upgrade: do not emit 200 header when establishing conn
991e47d 
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.
@Hagb Hagb mentioned this pull request Sep 20, 2022
Open
@Fopstronaut
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
5 participants
@rofl0r @dmwilcox @vaneses @SPascareli @Fopstronaut
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy