Re: [MERGE] c++-refactor HttpHdrCc

From: Alex Rousskov <rousskov_at_measurement-factory.com>
Date: Tue, 04 Oct 2011 21:58:36 -0600

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?

Thank you,

Alex.
Received on Wed Oct 05 2011 - 03:58:48 MDT

This archive was generated by hypermail 2.2.0 : Wed Oct 05 2011 - 12:00:03 MDT