Re: [MERGE] c++-refactor HttpHdrCc

 On Tue, 04 Oct 2011 17:39:48 -0600, Alex Rousskov wrote:
> On 10/04/2011 04:19 PM, Amos Jeffries wrote:
>> On Tue, 04 Oct 2011 08:30:47 -0600, Alex Rousskov wrote:
>>>>>>>>> We got a malformed max-stale value. We have only
>>>>>>>>> two options when it comes to that value interpretation, I
>>>>>>>>> think:
>>>>>>>>>
>>>>>>>>> A1. Treat it as valueless max-stale.
>>>>>>>>> A2. Ignore it completely.
>
>>>>>>>>> we have three options when it comes to forwarding the
>>>>>>>>> malformed directive:
>>>>>>>>>
>>>>>>>>> B1. Forward our own valid directive.
>>>>>>>>> B2. Forward nothing.
>>>>>>>>> B3. Forward the malformed directive.
>
>
>>> A1 has a side effect of serving a possibly "too stale" object to
>>> the
>>> client. You may be confused by the old source code comments (now
>>> fixed
>>> by Kinkie) that valueless max-stale means "always stale". It
>>> actually
>>> means "never stale". Thus, A1 and B1 convert "possibly stale at
>>> some
>>> unknown point in time" to "never stale" which feels like a bad
>>> idea.
>>
>> I was going by the RFC 2616 section 14.9.3 clause on max-stale:
>> "If no value is assigned to max-stale, then the client is willing
>> to
>> accept a stale response of any age."
>>
>> Treating it compliantly as valueless when a value was sent (but not
>> understood or malformed) means the client will get incorrect
>> overly-stale objects.
>
> Not sure why you call such treatment "compliant", but yes, that is
> exactly why I oppose A1: I do not want to make things worse by
> serving
> overly-stale objects.

 Thats what the RFC said. valueless == anything -> very,very,very stale
 is fine.

 Very nasty, but compliant.

>
>
>> If we want the client _never_ to get stale objects then it must be
>> treated as max-stale=0 to override both the local max_stale
>> directives
>> and the RFC "anything" behaviour of valueless field.
>
> Indeed. I think that would be even better than A2! Let me call it A0
> to
> avoid conflicts with previously mentioned options:
>
> A0. Treat it as max-stale=0.
> A1. Treat it as valueless max-stale.
> A2. Ignore it completely.
>
> A0 is the safest, most "conservative" option IMO.
>
>
>>>> I think we might have to get around this by using the max_stale
>>>> directive (or refresh_pattern override value) to limit the
>>>> max-stale
>>>> value relayed upstream from the current Squid. If we consider this
>>>> to be
>>>> an administrative override determining that this Squid will not
>>>> emit
>>>> objects older than max_stale its reasonable to shrink the
>>>> requested
>>>> staleness range from the valueless "anything" and ensure we get an
>>>> object as current as we want, within the wider range of what the
>>>> client
>>>> wants.
>>>
>>> When max-stale=value is malformed, we do not know whether we shrink
>>> or
>>> extend it by supplying our own value. That is why I think A2 is the
>>> only
>>> acceptable option for Squid internal interpretation and B2 and B3
>>> are
>>> the only acceptable options for forwarding.
>>>
>>
>> If we do A2, ignoring the header text entirely results in using the
>> max_stale directives local values.
>
> I did not think of a local config taking over in the simulated
> absence
> of a max-stale directive. If the client-supplied max-stale always
> takes
> priority over a local config, than A0 becomes even more attractive!
>

 The result of what I ported from squid-2 was supposed to be:
   max_stale overridden by refresh_pattern max-stale=, overridden by CC
 header max-stale[=], overridden by CC no-cache.

>
>> If we do A1, the RFC requires "anything" and our max_stale
>> directives
>> will always be smaller or equal to that. Usually smaller (1 week) so
>> a
>> slight gain in worst-case freshness over a bare assumption of
>> "anything".
>
> but still possibly a lot more stale than the client can tolerate. I
> see
> no reason to do A1 if we can do A0. Do you?
>

 I can't. Agreed.

 Amos
Received on Wed Oct 05 2011 - 01:05:52 MDT