Tunnel plain HTTP through a CONNECT-only proxy (connect:// scheme)#596
Merged
Conversation
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
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>
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
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.
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
HTTPTunnelPortrejects. This adds aconnect://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 noProxy-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 inproxy.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 thelang/*.txtfiles.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.