search

typicode / hotel

🏩 A simple process manager for developers. Start apps from your browser and access them using local domains
MIT License
9.98k stars 422 forks source link

5.11 X-Forwarded-Proto change seems to break my app's understanding of https #146

Closed bpicolo closed 7 years ago

bpicolo commented 8 years ago

Hola.

This might not actually be a result of 5.11, but just noticed it.

Hotel is passing X-Forwarded-Proto now as "https,http" which is confusing my destination app. The app thinks it isn't https because the framework is doing === 'https', roughly. Could the proxy pass from Hotel->my app be why it's adding that extra half? Seems like the proxy shouldn't add it's own there, though not sure?

I suspect it might make more sense for the reverse-proxy to not mention the protocol it's talking to the app over, if that's the case? It's really the connection to the reverse proxy that I'm worried about.

Thanks for all the work! Love the program.

natrim commented 7 years ago

seconding, it really should be only 'https' (when using https://*.dev, else 'http')

typicode commented 7 years ago

@bpicolo glad you like it and thanks for the report 👍 I'll see how to fix it

typicode commented 7 years ago

I did some research.

Hotel uses http-proxy and the behavior of http-proxy is to append protocols, the first one corresponding to the first proxy it goes through.

So when you access a server using https, it goes through a first https proxy then a second http proxy. That's why both protocol are present.

If possible, I would suggest retrieving the protocol using something like:

originalProto = forwardedProto.split(',')[0]

Since I haven't found spec for this header, for the moment, I prefer to rely on http-proxy implementation for this.