Re: [MERGE] c++-refactor HttpHdrCc

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.

> 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!

> 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?

Thank you,

Alex.
Received on Tue Oct 04 2011 - 23:40:00 MDT