I think that the field is going to match the requirements of the HTTP spec:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2 message-header = field-name ":" [ field-value ] field-name = token field-value = *( field-content | LWS ) field-content = <the OCTETs making up the field-value and consisting of either *TEXT or combinations of token, separators, and quoted-string> That takes precedence over the desire to scrape together naive parsers in my view. Most people writing code are going to want to skip the need to write a parser altogether by using existing parser methods built in to their platform. This is a standards based specification and so it has to match the format already defined by the HTTP specification and aspirational or not, any code that fails to match quoted string is likely to break in future spec versions. On Sat, Oct 29, 2011 at 2:50 PM, Adam Barth <[email protected]> wrote: > On Sat, Oct 29, 2011 at 2:06 AM, Julian Reschke <[email protected]> > wrote: > > On 2011-10-29 10:21, Adam Barth wrote: > >> ... > >>> > >>> 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. > >> ... > > > > So your points were about quoted-string in general, not the question of > > allowing them for max-age, right? > > > > I'm asking because due the possible presence of extension parameters, > > recipients need to deal with quoted-string anyway, no matter whether they > > are allowed for max-age. > > I'm saying we shouldn't use quoted-string anywhere in the grammar > because it makes the error-handling ill-defined. > > Here's the code I wrote to parse the header: > > > http://src.chromium.org/viewvc/chrome/trunk/src/net/base/transport_security_state.cc?revision=106333&view=markup > > TransportSecurityState::ParseHeader > > I'm happy to change that code to allow the parameters to appear in any > order and to allow other semi-colin separated fields. Here's the > parsing algorithm I'm willing to implement: > > 1) Split the header field value on ";". > 2) Process each substring in sequence: > a) Remove leading and trailing LWS from the substring. > b) If the substring is a case-insensitive match for > "includeSubDomains", set the include-subdomains flag and continue to > the next substring. > c) If the substring contains at least one "=", let the characters > before the first "=" be the parameter-name and let the characters > after the first "=" be the parameter-value: > i) Strip leading and trailing LWS from both the parameter-name and > the parameter-value. > ii) If the parameter-name is a case insensitive match for > "max-age" and the parameter-value is non-empty and consists entirely > of digits: > A) Let the max-age be the number represented by the digits and > continue to the next substring. > d) Continue to the next substring. > > Notice that this algorithm defines behavior for all inputs and doesn't > balance quotation marks in extension parameters. Here's a > representation of that algorithm in ABNF: > > value = paramater *(";" parameter) > paramater = "includeSubDomains" / "max-age" "=" 1*DIGIT *LWS / extension > extension = <any character aside from ";"> > > If you want the specification to match the code, you need to take into > account the desires of implementors. In particular, you need to take > into account the fact that implementations need to do something for > every possible input and that browser implementors wish to be > instructed how to handle every possible input. > > The net-net of this discussion is that's what the code is going to do. > If you'd like the specification to match the code, I'd recommend > against adding aspirational quoted-strings to the grammar. > > Adam > _______________________________________________ > websec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/websec > -- Website: http://hallambaker.com/
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
