On 05/10/11 16:58, Alex Rousskov wrote:
On 10/04/2011 07:05 PM, Amos Jeffries wrote:
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.
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.
Since the client has not sent a valueless directive, we cannot really
apply the valueless directive meaning to what we got. All we know is
that there is a value that we cannot parse. The value could be garbage,
a very long integer, or even a poorly specified custom extension. It is
probably not worth the trouble detecting the difference.
A0. Treat it as max-stale=0.
A1. Treat it as valueless max-stale.
A2. Ignore it completely.
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.
Glad we reached consensus and even improved the implementation plan
after all. A0 it is!
Are you OK with B2? Do you think B3 is worth implementing?
I'm okay with either. Overall I think B3 is better on the outgoing just
in case it was an extension or big integer. But not strongly enough to
want it right now.
B3 will probably be needed when we re-enable "transparent" traffic
flag as meaning fully transparent/invisible proxy (3.4?). Until then
there is no real need.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.15
Beta testers wanted for 3.2.0.12
