[squid-dev] forward bumped traffic to parent in plain form

[Anthony Pankov]

Tuesday, March 31, 2026, 9:49:41 PM, you wrote:

> On 2026-03-31 12:32, Anthony Pankov wrote:

>> May be you can target me to the point behind all bumping/ssl  logic
>> where normal HTTP processing begin? I mean is there any creation of
>> ClientHttpRequest derived from previously processed CONNECT tunnel?
>> ClientHttpRequest with bumped ssl  as its I/O? That would do normal
>> things like a cache lookup and forwarding to peers.


> It is difficult for me to answer your question directly, and I worry that the question itself may be too loaded/misleading. ClientHttpRequest code may be used before and after the TLS connection is bumped, so that class itself does not represent a clear TLS/HTTP demarcation line. ClientHttpRequest also should not do I/O itself (but does trigger it).

> The best guidance I can provide at this time is my earlier sketch at https://ml-archives.squid-cache.org/squid-dev/2026-March/009992.html

> The closest my sketch comes to that demarcation line is clientNegotiateSSL() called from getSslContextDone() after that function calls httpsCreate(): On the code path altered according to that sketch,

> * client-Squid communication before clientNegotiateSSL() is TLS;
> * client-Squid communication after that is HTTP (on top of TLS).

> Please keep in mind that clientNegotiateSSL() calls itself in an indirect loop, so "after" means something like "after clientNegotiateSSL() gets ioSuccess and calls readSomeData()".


> Disclaimer: The untested narrative above is based on the master-derived code that I am currently working on. That code underwent lots of unofficial changes that are currently stuck in the Squid Project backlog. I hope that the overall picture is still about the same as far as this analysis is concerned, but some of those changes may seriously affect it, so YMMV.


The  question appeared because I tried to go from other end to understand what is forcing peer_cache connection to switch to https. It is definitely 
FwdState::noteConnection(){...
    // Check if we need to TLS before use
    if (const auto *peer = answer.conn->getPeer())...

I see that it process http CONNECT request which is breaking thing because 
if ...request->method == Http::METHOD_CONNECT..
I suggest that it establish https connection to cache_peer  which later will prevent forwarding traffic in plain format.
I think you know it because your advice was: "You definitely do not want to call FwdState::Start()".

My idea was to just comment FwdState::Start() to prevent further flow of CONNECT request to see what happen. It is (un)expectedly broke things preventing complete of TLS handshake.

Of course I read what you say about getSslContextStart() etc. but I'm not ready to call it without understanding. The problem is there are semi-wrapped OpenSSL API which is hard to identify on the fly and calls in various places via asyncs and callbacks.

 Just for note.

-- 
Best regards,
Anthony