- From: Anne van Kesteren <annevk@opera.com>
- Date: Thu, 24 Jan 2008 10:55:43 +0100
- To: "Mark Nottingham" <mnot@yahoo-inc.com>, "Ian Hickson" <ian@hixie.ch>
- Cc: "WAF WG (public)" <public-appformats@w3.org>
On Wed, 23 Jan 2008 01:39:41 +0100, Mark Nottingham <mnot@yahoo-inc.com> wrote: > Question: the current BNF doesn't allow extensions to this header, ever, > period. Is that the intent of the WG? I think the idea is that if we ever need extensions we'll tweak the BNF in a backwards compatible way. For now it is important that anything that does not match the BNF will trigger an error. > If extensions may ever be even remotely possible (naturally, they'd need > to be backwards-compatible), that should be in the BNF. As it is, this > syntax isn't extension-friendly, because there's an ambiguity between > header extensions and extension methods. E.g., > > Access-Control: allow <example.com> method GET foo bar > > is "foo bar" a set of extension HTTP methods, or an extension to this > header? Those methods already match the Method grammar, as defined by RFC 2616, so they are part of the current Access-Control grammar. > The other reason I proposed the alternative syntax is that anyone who > has a Cache-Control header parser sitting around can reuse it, rather > than having to write something new. Parsing HTTP headers is notoriously > difficult, so minting a new syntax should be avoided if possible. Given that there are quite some subtle differences between how HTTP headers are parsed and how Processing Instructions are parsed (think of whitespace handling and all) I rather keep them as we have currently drafted them so that we don't get incorrect code reuse. -- Anne van Kesteren <http://annevankesteren.nl/> <http://www.opera.com/>
Received on Thursday, 24 January 2008 09:52:16 UTC