Re: [MERGE] c++-refactor HttpHdrCc

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.

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

Cheers,

Alex.
Received on Tue Oct 04 2011 - 14:31:00 MDT