Skip to content
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

Removed need for HTTPS sites to be proxied by tunnels only. Fixes #1293 #1344

Conversation

twolfson
Copy link

@twolfson twolfson commented Jan 8, 2015

As discussed in #1293, it is possible to want to do the same HTTP to HTTP proxying when talking to an HTTPS server. This PR allows that by removing the enforcement of HTTPS going to tunneling. In this PR:

  • Removed HTTPS requiring usage of HTTP tunnelling
  • Added test via @nylen
  • Updated documentation

@nylen
Copy link
Member

nylen commented Jan 8, 2015

There was nothing in the test server that was actually responding to that new request. Here's a working test: nylen/request@b16edd3

If you can pull that commit in and clean up the docs for the tunnel option (in the API section) we'll be good to go. Thanks for the PR.

@twolfson
Copy link
Author

twolfson commented Jan 8, 2015

Derp. That makes sense, thanks! I will let you know when the update is in.

@twolfson
Copy link
Author

twolfson commented Jan 8, 2015

Alright, I have cherry-pick-ed your commit and updated the documentation.

@nylen
Copy link
Member

nylen commented Jan 8, 2015

Oh... I think I missed something here...

By default, we still want to tunnel proxied requests to a HTTPS endpoint. If we had had a test for that behavior (like we really should have) then that test would have broken with this change.

What we should be adding here is the option to disable tunneling HTTPS requests.

Make sense?

@twolfson
Copy link
Author

twolfson commented Jan 8, 2015

Yep, I was considering this a breaking change by not adopting that behavior. I felt like the HTTPS/tunnelling default was a strawman that nobody uses.

I will add in the new logic.

@twolfson twolfson force-pushed the dev/dont.require.tunneling.sqwished branch 2 times, most recently from 8fa9d9c to 203e2a6 Compare January 8, 2015 18:53
@twolfson
Copy link
Author

twolfson commented Jan 8, 2015

Alright, I have fixed it. For what it's worth, it looks like request has been defaulting undefined to tunnel: false. Techincally, that still makes this a breaking change if people were using HTTPS and tunnel: false yet getting tunneling in the past.

@twolfson
Copy link
Author

twolfson commented Jan 8, 2015

I am going to change my implementation of explicitTunnel to line up with explicitMethod (as in it's a boolean).

@twolfson twolfson force-pushed the dev/dont.require.tunneling.sqwished branch from 203e2a6 to 8714f79 Compare January 8, 2015 19:50
@twolfson
Copy link
Author

twolfson commented Jan 8, 2015

Alright, all done and ready for review.

@nylen
Copy link
Member

nylen commented Jan 8, 2015

The default behavior when requesting a HTTPS endpoint should definitely be to tunnel. Otherwise the proxy can see the request which is not desired unless you know what you're doing.

I'm working on some more tests to get more comfortable with this change.

@twolfson
Copy link
Author

twolfson commented Jan 8, 2015

Ah, right. Sorry I was being fixated on my use case =/

@nylen
Copy link
Member

nylen commented Jan 8, 2015

No worries. It's a good use case, sorry it took me a little while to think through the implications.

It's time to rewrite tests/test-tunnel.js to be pure Node.js, using the Node core tests as a guideline:

That way we can test all combinations of (proxy HTTP, HTTPS) x (endpoint HTTP, HTTPS) x (tunnel true, false, undefined).

I'm working on it, probably won't be ready until this weekend though.

@twolfson
Copy link
Author

twolfson commented Jan 8, 2015

No worries. This PR isn't blocking me; I have been happily using my fork for the past day.

nylen added a commit to nylen/request that referenced this pull request Jan 25, 2015
Before, tunneling would default to false for http destinations and be
forced to true for https destinations.

Now, allow specifying `tunnel : false` to perform a regular GET request
to HTTPS destinations.  This is insecure, so make a note accordingly.

Supersedes request#1344 and fixes request#1293.
@nylen nylen closed this in 0da471f Jan 27, 2015
@nylen
Copy link
Member

nylen commented Feb 2, 2015

@twolfson version 2.52.0 is out on npm with this change (via #1374). Let me know if you have any problems using that.

@twolfson
Copy link
Author

twolfson commented Feb 2, 2015

Sweet, thanks!

@nylen
Copy link
Member

nylen commented Feb 2, 2015

@twolfson use 2.53.0 instead (see #1395, #1396).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants