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.
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.
Thats what the RFC said. valueless == anything -> very,very,very stale
is fine.
Very nasty, but compliant.
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!
The result of what I ported from squid-2 was supposed to be:
max_stale overridden by refresh_pattern max-stale=, overridden by CC
header max-stale[=], overridden by CC no-cache.
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.
Amos
