Re: [MERGE] c++-refactor HttpHdrCc

From: Alex Rousskov <rousskov_at_measurement-factory.com>
Date: Mon, 03 Oct 2011 18:02:38 -0600

On 09/30/2011 09:30 PM, Amos Jeffries wrote:
> On Thu, 29 Sep 2011 17:59:13 +0200, Kinkie wrote:
>> On Thu, Sep 29, 2011 at 5:55 PM, 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.
>>>>>
>>>>> Since valueless max-stale results in possibly very stale content being
>>>>> served to an unsuspecting client, I think #2 is much safer (and
>>>>> compliant with HTTP).

>>>>> 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.
>>>>>
>>>>> While option B3 could be the best, it requires more parsing changes.
>>>>> Option B2 is much better than B1, IMO, and requires minimal changes.
>>>>>
>>>>> We currently implement A1 and B1.

Hi Amos,

    I sense misconmmunication. Please keep in mind that A* options are
concerned with internal interpretation of a malformed CC directive by
Squid while B* options are concerned with forwarding of a malformed CC
directive by Squid. We treat those two areas separately, and we do not
discuss a whole CC header.

> B2 is not a valid option AFAIK.

Why not? We can drop a CC directive if we consider it malformed, I
think. And if it is the only directive, we would drop the whole CC
header, of course.

In fact, don't we already implement B2 for all other malformed
integer-valued CC directives?

> HTTP does not offer the option A2 as you are discussing right now.
> Since we know the header we must either treat it as an option known (A1)
> or something unknown (A3).

A2 is "ignore it", which (from interpretation point of view) is
equivalent to "treat it as something unknown" because Squid ignores
unknown CC directives.

> * A3 means we can ignore it for operational purposes (like A2), the
> natural result being B3.

I do not understand the difference between A2 and A3. A2 does not imply
B3 though. A2 implies (either B2 or B3).

> A1 means we have to decide betrween B1 or B3. Treating it as a known
> directive which has been extended with some unknown extension value
> (B3). Or as definitely malformed and invalid (B1).

A1 can be combined with all three Bs. I would not recommend A1 at all
though because we may end up serving stale content to a client that does
not want it. If we have to gamble, it is better to server "too fresh"
than "too stale" content, IMO (it is also compliant!).

Thank you,

Alex.
Received on Tue Oct 04 2011 - 00:02:49 MDT

This archive was generated by hypermail 2.2.0 : Tue Oct 04 2011 - 12:00:05 MDT