Keep HTTP/1.0 CONNECT tunnel sockets open - #503
Merged
Merged
Conversation
ericmj
approved these changes
Sep 6, 2026
Member
|
Thank you! 馃挏 |
wahve3
added a commit
to Tymeslot/tymeslot
that referenced
this pull request
Sep 14, 2026
Since 1.15.3, every https:// request made through an HTTP proxy stalled
for 30 seconds and then failed with a tunnel timeout, taking CalDAV
sync, calendar availability and the video provider integrations with it.
The proxy tuple's fourth element holds the options for the socket opened
to the proxy, and mint picks its proxying strategy from the *target's*
scheme. An http:// target goes through Mint.UnsafeProxy, which hands
that socket straight to Finch, so it has to be passive. An https://
target goes through Mint.TunnelProxy, which speaks CONNECT over it first
by waiting on socket messages, so it has to stay in mint's default
active mode. 1.15.3 set mode: :passive for both, so the CONNECT reply
was never delivered and the handshake blocked until tunnel_timeout.
The option is now chosen from the target URL's scheme, which the caller
already has. A stalled CONNECT is bounded by the same 10s budget as the
connect itself rather than by mint's 30s default.
ProxySocketOptionsTest drives real sockets through a stub proxy on
loopback: the tests this got past asserted the option list the code
produced, so they moved with it.
One case stays broken: a proxy that answers CONNECT with an HTTP/1.0
status line and no keep-alive (tinyproxy does). mint 1.10.0 applies
HTTP/1.0 persistence rules to that reply and closes the socket before
the TLS upgrade, which then fails with {:dtls_upgrade, :notsup}. That is
fixed upstream in elixir-mint/mint#503 but not yet released; picking it
up is a dependency bump, not a change here.
Refs #97
Signed-off-by: Luka Breitig <24662784+wahve3@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fix HTTPS tunnel establishment through proxies that return a successful HTTP/1.0 response to
CONNECT, such as Tinyproxy.A successful
CONNECTresponse switches the underlying connection into tunnel mode. However, after the CONNECT response framing changes in #493, Mint finalized the response using the normal HTTP/1.0 persistence rules.Because HTTP/1.0 connections are non-persistent by default, this closed the underlying TCP socket before Mint attempted the TLS upgrade. On OTP 29, upgrading the closed socket resulted in:
Changes
Keep the underlying socket open after any successful
CONNECTresponse.Do not apply the response HTTP version or
Connectionheader persistence rules once a tunnel has been established.Add a unit test verifying that an HTTP/1.0
200response toCONNECTleaves the socket open.Add an end-to-end regression test using a Tinyproxy-style response: