Skip to content

Tunnel plain HTTP through a CONNECT-only proxy (connect:// scheme)#596

Merged
xroche merged 3 commits into
masterfrom
fix-564-http-connect
Jul 16, 2026
Merged

Tunnel plain HTTP through a CONNECT-only proxy (connect:// scheme)#596
xroche merged 3 commits into
masterfrom
fix-564-http-connect

Conversation

@xroche

@xroche xroche commented Jul 16, 2026

Copy link
Copy Markdown
Owner

HTTPS already reaches the origin through a CONNECT tunnel (#85), but plain HTTP still used the absolute-URI request form, which a CONNECT-only proxy like Tor's HTTPTunnelPort rejects. This adds a connect:// proxy scheme (-P connect://host:port) that drives the proxy with CONNECT for every request: httrack opens a tunnel to the origin (port 80 for http, 443 for https), then sends the request origin-form with no Proxy-Authorization, the same way https does.

It can't be the default (CONNECT-to-:80 breaks proxies that only allow CONNECT on 443) and the issue rules out error-fallback auto-detection, so the mode rides the proxy scheme like socks5:// does. That keeps it ABI- and cache-safe (the scheme lives in proxy.name, no new struct field) and drops into the webhttrack GUI as one more entry beside HTTP and SOCKS5, since that page already builds the proxy string from a Proxy type dropdown. The tooltip was reworded to describe the mode and retranslated across the lang/*.txt files.

Test 57 fronts a plain-http origin with a CONNECT-only proxy (it 501s anything but CONNECT) and checks the request arrives origin-form, that dropping connect:// gets the classic form refused, that credentials ride the CONNECT and never reach the origin, and that a flooding proxy does not hang.

Closes #564.

xroche and others added 3 commits July 16, 2026 07:59
HTTPS already reaches the origin via CONNECT (#85), but plain HTTP still
used the classic absolute-URI form, which a CONNECT-only proxy such as
tor's HTTPTunnelPort rejects. Add a "connect://" proxy scheme that drives
the proxy with CONNECT for every request: httrack opens a CONNECT tunnel
to the origin (port 80 for http, 443 for https), then sends the request
origin-form with no Proxy-Authorization, exactly as https does.

It has to be opt-in (CONNECT-to-:80 breaks 443-only proxies) and the
issue rules out error-fallback auto-detection, so the mode rides the
proxy scheme like socks5:// does. That keeps it ABI- and cache-safe: the
scheme lives in proxy.name, no new struct field, and the webhttrack GUI
gains it as a third "Proxy type" entry (a scheme-prefix picker already).

Closes #564.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Xavier Roche <roche@httrack.com>
…view)

The htsblk `ssl` field is #if HTS_USEOPENSSL-only, so the new plain-http
CONNECT branch guarded its `!ssl` test the same way the socks block does;
without openssl there is no TLS, so the branch stays eligible. Reflow an
over-long comment for the diff-scoped clang-format gate, and correct the
raw-send note in http_proxy_tunnel now that it also runs for plain http.

Add a test case (review found the gap): every existing case used an
explicit origin port, so the new scheme-derived default port (80 for
http, 443 for https) was never exercised and a revert to a hardcoded 443
would have passed. A portless http origin now asserts the proxy sees
CONNECT to :80.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Xavier Roche <roche@httrack.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Xavier Roche <roche@httrack.com>
@xroche
xroche merged commit 938a873 into master Jul 16, 2026
53 of 55 checks passed
@xroche
xroche deleted the fix-564-http-connect branch July 16, 2026 07:22
xroche added a commit to xroche/httrack-windows that referenced this pull request Jul 16, 2026
The engine gained a connect:// proxy scheme (xroche/httrack#596): it
drives the proxy with CONNECT for every request, including plain HTTP,
which is what CONNECT-only proxies such as Tor's HTTPTunnelPort require.
The GUI had HTTP and SOCKS5 but no way to pick it.

Add it as a third row of the existing proxy type dropdown, reusing the
address/port/auth fields as the other two do, and map the row to its
scheme in compute_options() -- the same shape the build dropdown already
uses to map its rows onto non-contiguous engine codes.

The row order is what fixes the stored value: the tunnel goes last so
that the index keeps matching the code webhttrack's option10.html and
existing profiles already use (0 = HTTP, 1 = SOCKS5, 2 = tunnel), and
DDX_CBIndex keeps carrying it. An out-of-range code, from a hand-edited
or newer profile, selects HTTP in the dialog and emits a plain HTTP
proxy.

HTTP remains the default, so the emitted command line is unchanged for
existing projects.

LANG_PROXYTYPETIP is reworded engine-side by the same PR to describe all
three modes; no new LANG key is needed here.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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.

Plain http through a CONNECT-only proxy (tor HTTPTunnelPort) is refused

1 participant