On Wed, 23 Jan 2008 01:39:41 +0100, Mark Nottingham <[EMAIL PROTECTED]>
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/>
