Re: [MERGE] c++-refactor HttpHdrCc

On 05/10/11 16:58, Alex Rousskov wrote:
> On 10/04/2011 07:05 PM, Amos Jeffries wrote:
>> 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.
>
>
>>>> 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.
>
> Since the client has not sent a valueless directive, we cannot really
> apply the valueless directive meaning to what we got. All we know is
> that there is a value that we cannot parse. The value could be garbage,
> a very long integer, or even a poorly specified custom extension. It is
> probably not worth the trouble detecting the difference.
>
>
>>> A0. Treat it as max-stale=0.
>>> A1. Treat it as valueless max-stale.
>>> A2. Ignore it completely.
>
>>>> 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.
>
> Glad we reached consensus and even improved the implementation plan
> after all. A0 it is!
>
> Are you OK with B2? Do you think B3 is worth implementing?

I'm okay with either. Overall I think B3 is better on the outgoing just
in case it was an extension or big integer. But not strongly enough to
want it right now.
  B3 will probably be needed when we re-enable "transparent" traffic
flag as meaning fully transparent/invisible proxy (3.4?). Until then
there is no real need.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.15
   Beta testers wanted for 3.2.0.12