W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2012

Re: WGLC #353: Multiple Values in Cache-Control headers

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Tue, 12 Jun 2012 01:04:24 +1200
Message-ID: <4FD5ECD8.3000308@treenet.co.nz>
To: ietf-http-wg@w3.org
On 12/06/2012 12:10 a.m., Julian Reschke wrote:
> On 2012-06-11 13:57, Mark Nottingham wrote:
>> ...
>>> If that is the case, we probably need to spend some more time on 
>>> clarifying this, as this different from similar header fields.
>>
>> How so? I thought we'd agreed we don't have shared microsyntax / 
>> model for our existing headers...
>
> At least for those headers that inherit MIME header field parameter 
> syntax (such as C-T and C-D) I believe the consensus was that 
> parameters can not get repeated. It might be hard to find something 
> normative on that, though.
>
> So let's rephrase this: optimally, we
>
> - defined this for all header fields in the spec (optimally globally 
> for all parameters of that header field), and
>
> - advise people defining new header fields to do so as well (-> 
> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-19.html#rfc.section.3.1>) 
>
>
>>>>> Can the definition of error recovery diverge per directive?
>>>>
>>>> I imagine so.
>>>
>>> Which makes it sound as if we should define it for all directives 
>>> defined in this spec (as bad as this sounds)...
>>
>>
>> If someone wants to point out specific instances where they believe 
>> it's important for security and/or interoperability, and it doesn't 
>> fall afoul of our stance on error handling, by all means.
>
> Right now we don't say anything what to do, for instance, with two 
> max-age directives? If this is an invalid header field instance, we 
> should say so. If it's not, we should say how to handle that.

* flag parameters can't exactly contradict, so dropping/merging 
duplicates and treating as one flag would seem okay. (only-if-cached 
must-revalidate, proxy-ravalidate, no-cache, no-store, no-transform, etc)

* time-delta parameters (max-age, s-maxage, etc) being conservative and 
dropping the larger or equal of the two seems the right handling.

* list of tokens ... maybe combine? it is possible one proxy adds 
no-cache="Foo" and another adds no-cache="Bar" and they both hit some 
downstream cache which needs to handle both Foo and Bar properly.
   Yes the right thing to do woudl have been no-cache="Foo Bar". But 
what if that is not done?


AYJ
Received on Monday, 11 June 2012 13:05:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 11 June 2012 13:05:28 GMT