- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 7 Dec 2010 11:04:24 +1100
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Adam Barth <ietf@adambarth.com>, Bjoern Hoehrmann <derhoermi@gmx.net>, HTTP Working Group <ietf-http-wg@w3.org>
This is an attractive approach, but I'm concerned that opening up the 'core' grammar to accommodate this might make some existent implementations too strict -- e.g., they'll reject characters that were previously disallowed but now in the ABNF. I.e., the UA profile wouldn't be optional any more. To address this, we'd probably need to discriminate between produce and consume ABNF, just as we've done elsewhere. Regards, On 05/12/2010, at 6:59 AM, Julian Reschke wrote: >>> If we want to keep handling valid header fields properly, we *probably* >>> better start from the base grammar, and relax certain constructs. >> >> Feel free to propose a modification to the base grammar that matches >> every sequence of bytes and computes the needed segmentation. It's >> not at all obvious to me how to approach constructing the grammar from >> that starting point. > > It does not need to match any sequence. It's completely ok to state what it means not to match the grammar. > > So let's start with: > > content-disposition = "Content-Disposition" ":" > disposition-type *( ";" disposition-parm ) > > disposition-type = "inline" | "attachment" | disp-ext-type > ; case-insensitive > disp-ext-type = token > > disposition-parm = filename-parm | disp-ext-parm > > filename-parm = "filename" "=" value > | "filename*" "=" ext-value > > disp-ext-parm = token "=" value > | ext-token "=" ext-value > ext-token = <the characters in token, followed by "*"> > > We could relax requirements on ordering and cardinality of disposition-types: > > content-disposition = "Content-Disposition" ":" > ( disposition-parm / disposition-type ) > *( ";" ( disposition-parm / disposition-type )) > > and then relax the grammars for "token" and "quoted-string" to allow more characters that are not needed for detecting names and values. I think that would reduce the risk of defining something that breaks valid headers. -- Mark Nottingham http://www.mnot.net/
Received on Tuesday, 7 December 2010 00:04:58 UTC