Re: [websec] Strict-Transport-Security syntax redux

[Adam Barth <[e-mail]>]

On Sat, Oct 29, 2011 at 1:19 AM, Julian Reschke <[e-mail]> wrote:
> On 2011-10-29 10:10, Adam Barth wrote:
>>
>> On Sat, Oct 29, 2011 at 1:07 AM, Julian Reschke<[e-mail]>
>>  wrote:
>>>
>>> On 2011-10-29 05:08, Adam Barth wrote:
>>>>
>>>> ...
>>>>>
>>>>> Except for RFC6265, which in the algorithm for parsing "Max-Age=", it
>>>>> algorithmically provides for ignoring a value that doesn't match the
>>>>> effective value ABNF of..
>>>>>
>>>>>  ["-"]*DIGIT
>>>>>
>>>>> ..which would catch the max-age="1" case, but doesn't seem to
>>>>> explicitly
>>>>> address..
>>>>>
>>>>>  max-age=
>>>>
>>>> That's handled by some more general processing rules in the spec.  The
>>>> net result is that it's ignored.
>>>>
>>>>> But in any case, perhaps (additional) browser implementor folk could
>>>>> chime
>>>>> in here -- do we really need to address such detail-level issues (both
>>>>> of
>>>>> the examples above and below) in the syntax/grammar we specify in specs
>>>>> such
>>>>> as these? Or is the new ABNF proposed in the original message in this
>>>>> thread
>>>>> sufficient?
>>>>
>>>> Generally, we prefer to be instructed exactly how to behave for every
>>>> possible input (even illegal ones).  There's a long history of
>>>> quoted-string not being implemented correctly by browsers.  I spec
>>>> this as just splitting the string on ; and then processing each
>>>> substring separately, ignoring bogus/future ones.  I know Julian has a
>>>> dream that all HTTP headers will be parsed the same, but quoted-string
>>>> is sufficiently ill-defined w.r.t. error handling that I prefer to
>>>> avoid it.
>>>> ...
>>>
>>> - when discussing generic parsing, we need to distinguish between legacy
>>> cases like cookies, and new headers, where we can do better
>>>
>>> - standardizing handling of broken headers is one thing (and in general I
>>> prefer not to), but that doesn't mean that when defining a new header
>>> field
>>> we shouldn't minimize the things a sender can get wrong; if we know that
>>> some recipients will accept both token and quoted-string anyway, then it
>>> seems like a good thing to simply allow them both, reducing the number of
>>> special-cases in parsing
>>>
>>> - not sure what you mean by "ill-defined w.r.t. error handling"; it's
>>> defined just like most other syntax elements in HTTP -- is there
>>> something
>>> *specific* to quoted-string you have in mind?
>>
>> Most of HTTP is ill-defined w.r.t. error handling.  We muddle through
>> with reverse engineering.
>> ...
>
> It's not ill-defined, but undefined (by design) - see
> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/186>.
>
> What I was trying to understand whether there's something special with
> respect to quoted-string?

Quoted string is particularly bad because it's hard to know what to do
with unbalanced quotation marks.

Anyway, I'm resigned to lose this argument in this forum.  It just
means we'll need to clean up the mess later in another forum.

Adam