Re: [MERGE] c++-refactor HttpHdrCc

 On Mon, 03 Oct 2011 18:02:38 -0600, Alex Rousskov wrote:
> 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.

 Understood.

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

 Possibly. This does not make it a full case though. It seems to be one
 instance of B1 where our fixed valid value happens to be nil.

 ie A1->B2 is not valid. and for the reasons outlined below A2->B2 is
 not valid.

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

 Possible miscommunication here. I was reading your A* as what to do
 with the values from the point of parser sighting them onwards.

 A2 as I see it means produce 'other' key-value token from the parse.
 Ignoring it internally. The only compliant action on output is B3. This
 could lead to accepting a second instance of max-stale as the real
 max-stale. So I'm kind of against choosing this action.

 A3 as I see it means parse and accept as a unknown *non-nil* value of
 max-stale. Treating it internally as valueless (or zero value to be very
 conservative?), BUT the compliant output is B3. Without the problems of
 accidentally emitting 2 max-stale values, because even if ignored we
 record in the state that a max-stale was seen.

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

 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.

 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.

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

 Which leaves us in a mess because;
  A1->B1 seems intuitively the right thing, but has bad side effects.
  A1->B3 seems like a reasonable alternative to avoid the effects, but
 gambles on delta-seconds never changing.

 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.

 Amos
Received on Tue Oct 04 2011 - 02:50:12 MDT