Re: forward bumped traffic to parent in plain form

Hello,

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.



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.




-- 
Best regards,
Anthony