On 12/07/2011 01:19 PM, Amos Jeffries wrote:
> So, in theory ssl-bump is a form of intercept not a form of
> accelerator. Its use of prepareAcceleratorURL() to convert the partial
> to absolute URL unconditionally sets the accel flag with a mix of side
> effects. Some bad ones have been identified already.
>
> This patch changes the flag setting, to allow ssl-bump to use the URL
> preparation function without the side effects. I'm in half a mind to
> make a ssl-bump specific URL preparation function, but only after this
> is proven workable.
>
> Christos: as the person who appears to have the best testing ability for
> ssl-bump can you run your tests over the resulting Squid and check that
> the expected behaviours have not changed for the worse? I am fully
> expecting there to be several as yet unknown places needing to add a
> test of the sslBumped flag alongside testing accel flag.
Looks OK.
Also because accel and related flags are used in http authentication and
esi, I think too it is better to detach it from sslbumped requests,
where we should handle authentication with a different way...
The only objection is for the Config.onoff.ie_refresh parameter.
Look in the client_side_request.cc line 1027 inside block:
if (Config.onoff.ie_refresh) {
}
But does not look important....
>
> I'm expecting this to fix the need for ssl-bump to configure
> "always_direct allow" and for this to be the proper long-term fix for
> the bug 2519 status mixup in comment 52 (comment 53 has an adequate
> workaround for the bug patch while this gets tested).
Amos, this patch is not enough to replace the workaround in comment 53,
the workaround required.
>
> Amos
Received on Wed Dec 07 2011 - 17:00:02 MST
This archive was generated by hypermail 2.2.0 : Thu Dec 08 2011 - 12:00:04 MST