On 2012-03-26 08:38, =JeffH wrote:
>> >> sections 6.1.1 and 6.1.2 describe the syntax particular to
max-age and
>> >> includeSubDomains directives, and neither of those directives employ
>> >> quoted-string, and I don't think they need to or should.
>> >
>> > I think they should, because it's likely that people will write
parses
>> > that allow both, thus you'll have an automated (and totally unneeded)
>> > interoperatility problem.
>>
>> Well, i'm not terribly convinced about this, especially given my code
>> reconnaissance in Firefox and Chrome.
>
> When you checked Firefox, did it support quoted-string for extension
> directives? See?
I am not sure what you mean by "See?" -- the parsers for STS header in
both firefox and chrome are one-off hand-coded specific parsers, for
better or worse (I'm not sure why they were done that way), and neither
one supports quoted-string for anything in the STS header IIRC.
Yes (but I have inspected only the FF code).
The reason I asked "See?" is that you can't use the fact that FF doesn't
support q-s for the builtin parameters as argument against q-s. Right
now it's not using q-s at all; thus, it's currently not conforming to
the spec as written anyway and will have to be fixed.
If it was fixed to be conforming to the current spec, I would suspect
there's a good chance it would start q-s everywhere, instead of
special-casing based on the parameter name.
That said, given the present definitions of the STS directives...
max-age = "max-age" "=" delta-seconds
delta-seconds = <1*DIGIT, defined in [RFC2616], Section 3.3.2>
includeSubDomains = "includeSubDomains"
I'm not sure how to cleanly and unambiguously define them in terms of
both token and quoted-string (and retain max-age's basis on
delta-seconds). Perhaps you could propose how to do this?
Just define the base grammar for the overall parsing; such as "Expect"
in httpbis:
http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-19.html#rfc.section.10.3
or the "Prefer" I-D:
http://greenbytes.de/tech/webdav/draft-snell-http-prefer-12.html#rfc.section.2
You can still use ABNF to put additional restrictions on the value, but
these constraints then should apply to the parameter value after q-s
unescaping.
Note that I have a TODO to apply this change to Cache-Control in HTTPbis
P6 and haven't done that yet. The problem here is that implementations
of Cache-Control in browsers are incredibly broken (see?), so it's not
clear how much cleanup is possible at this point.
Let's not repeat these mistakes with entirely new header fields.
Also, we need to consciously realize that even if we define it in this
fancier way in the spec, the present HSTS implementations won't match
this, and may never do so. i.e. yes, you can submit bugs and wait and
see what happens.
...
Well, these implementations are non-conforming right now. The
interesting question is whether it's harder to change them to use q-s in
*some* parameters or to do so in *all* parameters. The former requires
that parser to special-case certain parameter names.
=JeffH
ps...
>> > I think they should, because it's likely that people will write
parses
>> > that allow both,
I think "likely" should in reality be "may" in the above. There's a ton
of parsers already written (firefox alone has several different ones
apparently from what I can discern) that don't follow the (relatively
recent) "parse parameter values in both token and quoted string forms"
mantra.
There are tons of broken parsers, yes. Some of them in the process of
being fixed. For instance, FF now processes q-s in Content-Type and
Content-Disposition, and Chrome recently started to do q-s in
Content-Disposition.
And so you're hoping both that existing parsers get updated to follow
the general guidelines in "3.1 Considerations for Creating Header
Fields"
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-19.html#rfc.section.3.1>,
and that new ones also adhere to said considerations.
I hope that new definitions follow the advice, and that implementations
of parsers for existing fields actually conform to what the
specification says (see examples about Content-Type and
Content-Disposition above).
Best regards, Julian
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
