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.
