Re: #307 (untangle Cache-Control ABNF)

On 11/06/2012, at 11:16 PM, Julian Reschke wrote:

> On 2012-06-11 15:02, Mark Nottingham wrote:
>> 
>> On 11/06/2012, at 10:51 PM, Julian Reschke wrote:
>> 
>>> On 2012-06-11 14:44, Mark Nottingham wrote:
>>>> Assuming that the text isn't changing in substance, yes.
>>>> 
>>>> I think this is verging on editorial; if anyone has concerns about this direction, please speak up; otherwise, Julian go ahead.
>>>> ...
>>> 
>>> It's a bit more than editorial, because it tries to address the mismatch between the ABNFs for predefined directives (special-cased), and extension directives (token *and* quoted-string).
>> 
>> Ah.
>> 
>>> 
>>> Highlighting these changes:
>>> 
>>>  Cache directives are identified by a token, to be compared case-
>>>  insensitively, and have an optional argument, that can use both token
>>>  and quoted-string syntax.  Recipients MUST accept both forms.
>> 
>> The MUST is going too far here. I think that individual parameters can (and do) constrain the syntax.
> 
> Well, they should not. It's pointless. Do you expect a parser for cache-control to special-case every constraint it knows about? What happens with an extension header that has constrained syntax? Some parsers will apply the constraint, some won't.
> 
> It's the same discussion we've had for other fields (say WWW-Authenticate, Expect, Prefer, STS, ...); and the answer should be the same.
> 
> We can't change what's out there, but we need to provide guidance how to fix these parsers to make them reliable.

If we take this path, we'll be making any cache that doesn't correctly parse

  Cache-Control: max-age="5"

non-conformant. I don't think that's a reasonable thing to do; it's not improving security or interoperability (our two "major" criteria), only library reusability.

I *thought* we'd already discussed this; once I find some coffee, perhaps I'll dig in the archives.



--
Mark Nottingham   http://www.mnot.net/

Received on Monday, 11 June 2012 20:59:16 UTC