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

[Alex Rousskov]

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.


HTH,

Alex.


> Thursday, March 26, 2026, 4:00:59 PM, you wrote:
> 
>> On 2026-03-26 08:14, Anthony Pankov wrote:
>>>> Tuesday, March 10, 2026, 10:12:46 PM, you wrote:
>>> ...
>>>> httpsSslBumpStep2AccessCheckDone() callback calls
>>>> startPeekAndSplice() (for the second time!) that gets to an httpsCreate() statement/line.
>>> ...
>>>> I'm very confusing about many reference to "PeekAndSplice" name in code.
>>> There is startPeekAndSplice, doPeekAndSpliceStep,
>>>           // Disable caching for bumpPeekAndSplice mode
>>>> The ' bumpPeekAndSplice' name is puzzling.
>>>> It is different from stare, peek, bump mode and ever with 'client-first'.
>>>> May be you can comment  what  a historical meaning of PeekAndSplice name.
> 
>> PeakAndSplice is a nickname of a project (or a set of features). It does not mean "peak and then splice". It kind of means "code that supports peek, splice, and bump actions".
> 
>> Initial SslBump implementation did not support those actions. Then we had a separate/followup PeekAndSplice project that added support for those actions.
> 
>> Overall SslBump code quality is terrible. Poorly chosen names and many misleading comments are not the worst bits, but they certainly do not help.
> 
>> Alex.
> 
> 
> 
>