Re: [MERGE] c++-refactor HttpHdrCc

 On Tue, 04 Oct 2011 08:30:47 -0600, Alex Rousskov wrote:
> On 10/03/2011 08:49 PM, Amos Jeffries 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.
>
>>>>>>> BTW, 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.
>
>
>> The new updated RFC texts from HTTPbis are now stating:
>>
>> "
>> A proxy, whether or not it implements a cache, MUST pass cache
>> directives through in forwarded messages, regardless of their
>> significance to that application, since the directives might be
>> applicable to all recipients along the request/response chain.
>> It is
>> not possible to target a directive to a specific cache.
>> "
>>
>> So we do not have B2 as a compliant option. If we receive it, it
>> MUST be
>> relayed.
>
> I disagree. The above HTTPbis text does not talk about malformed
> directives, which are the only subject of the current discussion. B2
> is
> acceptable for malformed directives, IMO, even though B3 would match
> the
> spirit of the above spec better.
>
>
>> Erasing it could be an option, but not a compliant one. Striping the
>> unknown-value to make it less strict than we received would be more
>> likely to add problems in downstream software which might understand
>> it.
>
> Squid can either drop the malformed directive completely (B2) or
> forward
> the original malformed directive (B3). B2 is easy to implement. B3 is
> not so easy and is probably not very useful in practice so I would
> not
> spend cycles on it, but it is Kinkie's call.
>
> Forwarding something other than the original is a bad idea, IMO,
> because
> it may result in more stale objects than the client wants to accept
> (B1).
>
>
>> That said, the spec clearly outlines it as delta-seconds so if its
>> not
>> parseable as delta-seconds its clearly malformed and B1 probably
>> should
>> not pass "max-stale".
>
> Exactly. Although, technically, it is easy to construct a well-formed
> max-stale value that Squid would consider malformed:
>
> max-stale=9999999999999999999999999999999999999999999999999999
>
> The same is true for virtually all integer-based values in HTTP. We
> can
> hope such values will never be found in real requests until we meet
> aliens that write software which can cache objects for eternity.
>

 Or the science and archival communities. They have particular accuracy
 requirements on the meaning of "forever".

>
>> Which leaves us in a mess because;
>> A1->B1 seems intuitively the right thing, but has bad side effects.
>
> Neither A1 nor B1 are the right things, IMO, because they may lead to
> responses that are more stale than what the client is willing to
> accept.
>
>
>> A1->B3 seems like a reasonable alternative to avoid the effects,
>> but
>> gambles on delta-seconds never changing.
>
> 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.

 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.

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

 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".

 Amos
Received on Tue Oct 04 2011 - 22:20:04 MDT