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 _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
