https:// requests are redirected to http:// about node-unblocker HOT 9 CLOSED

Many thanks, sorry I never submitted a pull request.

from node-unblocker.

Good catch. Do you think you can put together a unit test and/or fix for this?

from node-unblocker.

It looks like the problem is unblocker.js on line 105:

https://github.com/nfriedly/node-unblocker/blob/master/lib/unblocker.js#L105

clientRequest.protocol = clientRequest.protocol || clientRequest.connection.encrypted ? 'https' : 'http';

in my test on an https connection, before line 105, both clientRequest.protocol and clientRequest.connection.encrypted are undefined so clientRequest.protocol is being incorrectly set to 'http'.

If I hardcode clientRequest.protocol to 'https' https://www.optimcore.com/proxy/http://example.com is correctly redirected to https://www.optimcore.com/proxy/http://example.com/

Let me know if this looks like I'm on the right track and I will continue. How would I go about correctly determining an encrypted connection. The comments state // default to express's more advanced version of this when available (handles X-Forwarded-Protocol headers)). Is this available now?

from node-unblocker.

Yea, it sounds like you're on the right track. I think the clientRequest.connection.encrypted setting is/was an undocumented feature that may have been removed in a more recent node.js :/

Are you using Express.js? If so, then clientRequest.protocol should be set, though, - see http://expressjs.com/en/4x/api.html#req.protocol (although perhaps they were depending on the same undocumented feature).

If there isn't a straightforward way to make it work with a complete URL in the redirect, though, you could look at just doing relative redirects (e.g.: Location: /proxy/http://example.com/) - it's not RFC compliant, which is why I tried to avoid it initially, but it works in practice - ever browser out there handles it correctly. There may be a few broken tests that will have to be updated if we go that route.

from node-unblocker.

I'm using a standard AWS Elastic Beanstalk Node.js application so as far as I'm aware I'm not using Express.js. Also it's seems over the top to have to reply on a dependency to determine if the request is secure.

I've done a bit of Googling and I can't find any up to date docs or recent StackOverflow posts outlining how to determine if a request is secure.

How do I run the tests, so I can fix this using relative redirects as you suggest?

I will be on holiday all of next week and as the request on my server will always be secure I've hardcoded clientRequest.protocol as 'https'. This obviously isn't a fix for everyone, but it's a quick workaround for me for now.

from node-unblocker.

Right, sorry, didn't mean to imply that you should be running express, I was more just curious if this was an issue that affected it as well.

The command npm test should work to run the tests; I don't think there are any extra requirements beyond grabbing the source from github and running npm install.

Glad to hear that you have a quick fix; I'll do some poking around and see what I can come up with, although I'm at work now and have family coming in later today, so it might also take me a bit of time to get to it.

What version of Node.js are you running on AWS?

from node-unblocker.

No worries, I didn't mean to imply anything bad. I'm new to Node.js so I don't really understand about Express etc.

I've just checked AWS and I'm running Node.js version 4.3.0. There's more info about Elastic Beanstalk Node.js configurations here. Wikipedia says the latest stable release of Node.js is 5.9.1, so AWS is quite behind. Do you think this could be an issue?

Have a great Easter with your family :)

from node-unblocker.

4.3 is the long-term support release, so it isn't as bad as it sounds.

from node-unblocker.

BTW, I released a fix for this in v2.2.0. Sorry it took so long. There's a test in place, so it shouldn't break again.

from node-unblocker.