Re: Feedback on Access Control

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       mnot@yahoo-inc.com

Received on Wednesday, 23 January 2008 00:40:30 UTC