Re: forward bumped traffic to parent in plain form

Tuesday, March 10, 2026, 10:12:46 PM, you wrote:

> On 2026-03-10 10:50, Anthony Pankov wrote:
>>>> Monday, March 9, 2026, 3:55:40 AM, Alex wrote:
>>>>> Option A: Give up on trying to bump the client without talking to
>>>>> the TLS origin server first. Let Squid talk to the TLS origin
>>>>> server (directly or via a cache_peer) while bumping the client. We
>>>>> know that this part already works. Adjust Squid code to
>>>>> forget/close that TLS connection after the client gets bumped and
>>>>> forward subsequent GET requests to a cache_peer using a different
>>>>> plain text connection. This option is only viable if you can let
>>>>> your Squid talk to the TLS origin server (directly or via a
>>>>> cache_peer) during client bumping.

>> I choose an option A. 
>> I'm open to any startup hints for option A realization.

> In the context of your project, ignoring the necessary task of preserving existing behavior in other/out-of-scope cases:

> Existing code path (you may need to adjust some `if` statements to get your code to follow this path in your configuration/case):

> ConnStateData::parseTlsHandshake() calls
> startPeekAndSplice() (for the first time) that schedules
> ACLFilledChecklist::NonBlockingCheck().then(httpsSslBumpStep2AccessCheckDone)

> httpsSslBumpStep2AccessCheckDone() callback calls
> startPeekAndSplice() (for the second time!) that gets to an httpsCreate() statement/line.

> At this point, I am not sure, but I suspect that you do _not_ want your code to call httpsCreate(). You definitely do not want to call FwdState::Start().

> Instead, you may want to call getSslContextStart() that should [eventually trigger a] call to
> getSslContextDone() with a non-nil Security::ContextPointer that calls
> httpsCreate() with the transaction-specific security context (SNI, etc.).

> I am sure more changes will be needed, but the above may help you get started.

Thank you. I'll try.


-- 
Best regards,
Anthony