Question: the current BNF doesn't allow extensions to this header,
ever, period. Is that the intent of the WG?
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?
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.
Cheers,
On 23/01/2008, at 6:58 AM, Ian Hickson wrote:
On Tue, 22 Jan 2008, Anne van Kesteren wrote:
Access-Control: allow <example.com> method GET
Access-Control: POST
Access-Control: PUT, DELETE, deny <example.org> method POST
Access-Control: GET
Will clients be able to parse this correctly? Please don't repeat
the
mistakes of the Set-Cookie header; this is very bad practice. It
would
be better to leverage existing syntax from other headers; e.g.,
Access-Control: allow="example.com"; method="GET POST PUT DELETE",
deny="example.org"; method="POST GET"
Good point. Is the rest of the WG ok with changing this? Jonas?
Oops, I missed that when I read the spec.
I recommend just changing the #Method from being comma-separated to
being
space-separated, as in:
Access-Control: allow <example.com> method GET PUT
--
Ian Hickson U+1047E )
\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _
\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--
(,_..'`-.;.'
--
Mark Nottingham [EMAIL PROTECTED]
