Re: [websec] of quoted-string header field param value syntax (was: Strict-Transport-Security syntax redux)

[Julian Reschke <[e-mail]>]

On 2012-01-14 01:24, =JeffH wrote:
>
> In terms of this question of whether the STS header field directive ABNF
> should be..
>
> 1) directive = token [ "=" ( token | quoted-string ) ]
>
> ..or..
>
> 2) directive = token [ "=" token ]
>
> ..I can see both sides of the argument.
>
> However, I've been thinking about it and grepping thru specs as well as
> firefox and chrome code, which has led me to think that from an overall
> (specification) consistency perspective, I'm leaning towards spec'g it
> with quoted-string in the ABNF (ie, as (1)). And has been pointed out in

+1

> the discussion, it is sort of a moot point because the STS header field
> does not at this time make use of the quoted-string production, nor do
> we have on the table any extension directives that would do so.

It's not a moot point at all. If you don't spec it now, extensions will 
not ever be able to use quoted-string, because recipients parsing over 
those extensions will trip over them.

> In going through the FF and Chrome code, I note that both of their STS
> header field parsing methods appear to be special-case and AFAICT don't
> make use of other, more general HTTP header field parsing routines that
> are available in both implementations, and that are used to parse other
> HTTP response header fields. These latter more general HTTP header field
> parsing routines appear to be used for processing various of the other
> HTTP response and request header fields (and they appear to handle
> quoted-string). But it isn't clear why they aren't used for STS. It also
> isn't clear how uniformly these parsing routines are used for the
> panoply of HTTP header fields -- some other header fields appear to be
> special-cased as well (tho my c++ foo is wanting and the code is
> vast..). So yeah, it does seem messy.

It's true what right now there isn't a lot of re-use of header field 
parsers. This is likely because of historic reasons; different header 
fields have different parsing quirks.

But of course that's not an excuse to add unneeded special cases in the 
future.

Example: just a few weeks ago we discussed the "Prefer" header field in 
the HTTPbis WG, and we have been able to make it parse exactly like 
"Expect" (after fixing "Expect" as well, see 
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/327>).

Best regards, Julian