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

ESI request forced HTTPS connection even if config.upstream_use_ssl is set to false #176

Open
kzolnowski opened this issue Jun 12, 2018 · 2 comments

Comments

@kzolnowski
Copy link

I'm trying to use offloaded SSL traffic with ESI. Handler config:

require("ledge").set_handler_defaults({
    upstream_host = "127.0.0.2",
    upstream_port = 80,
    advertise_ledge = false,
    upstream_use_ssl = false,
})

While trying to use ESI I've got error:

[error] 4219#0: *69822327 [lua] processor_1_0.lua:461: esi_fetch_include(): ssl handshake failed: handshake failed, client: 127.0.0.3, server: test, request: "GET / HTTP/1.1", host: "test"
[error] 4219#0: *69822327 SSL_do_handshake() failed (SSL: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol), client: 127.0.0.3, server: test, request: "GET / HTTP/1.1", host: "test"

I found that ESI proccessor is trying to use ssl handshake even if config.upstream_use_ssl is set to false, so I already fixed that in code (see attachment) ;)

esi_ssl_offload.diff.txt

@hamishforbes
Copy link
Collaborator

Hey Krzys!

Hmmm, It's actually little more complicated than that.

ESIs could be to an external server which does require HTTPS, so just disabling the handshake when our current upstream does not use SSL isn't correct.

We loopback ESIs with the same domain as the current request to the same IP and port as the current request was received on, the assumption being if we are handling a request for a domain then we can handle the ESI for that domain too.
Perhaps this optimisation should be configurable, allowing it to be disabled or the behaviour controlled to allow scenarios like yours to work

Also I think there's probably another bug here whereby a page on HTTP or HTTPS that has an ESI for the same domain but a different scheme is going to attempt to loopback to the wrong port.

@pintsized
Copy link
Member

Hey, I realise this is ancient but I think this is now addressed here: b6bd6e1

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

No branches or pull requests

3 participants