Re: [access-control] Implementation comments

Anne van Kesteren wrote:
> On Mon, 15 Sep 2008 12:29:27 +0200, Jonas Sicking <jonas@sicking.cc> wrote:
>> It would seem very unfortunate and arbitrary from a users point of
>> view to not be able to get upload progress on text/plain POSTs but on
>> all other types of requests.
> 
> It also seems arbitrary that depending on registered event listeners 
> (also specifically before invoking send()) the server needs to support a 
> more elaborate protocol.

The distinction is arguably no more arbitrary than between when using 
the text/plain vs application/xml content types.

I agree it's unfortunate, but I don't have a better alternative.

> I don't really have a good counter proposal to this though. What Maciej 
> suggests might work, but it also feels dodgy.

My biggest problem with Maciejs proposal is that it's hard to implement 
robustly enough that it stands up against timing attacks.

>> I thought one of the use cases for Access-Control-Request-Headers was
>> for servers that needed to support a large amount of headers, possibly
>> even an unbounded set?
> 
> Would requests from a particular origin always use the unbounded set 
> though?

As I recall it Hixie brought up the use case of very large sets of 
headers so I'd forward the question to him.

>> What would be the downside of always remembering that a server has
>> granted a specific header for a specific amount of time and only
>> delete that grant if the header exires, is updated by a later request,
>> or is removed due to a failed security check?
> 
> It would quite drastically change the caching model again. It's 
> unfortunate these comments always come after we published some 
> supposedly stable draft. Does anyone read the editor's copy?

I never read anything but the editor copy. Sorry about this feedback not 
coming earlier. This was feedback based on implementing, not based on 
the publication. I didn't finish the implementation until a couple of 
days ago. (Technically speaking still early based on W3C process).

For what it's worth I also attached a fairly large test suite. 
Unfortunately it's currently fairly heavily relying on some mozilla-only 
javascript features (specifically the 'yield' keyword) but that can be 
fixed.

It's currently missing tests for redirects and cookieless requests as I 
haven't implemented those features yet. I'll publish the test suite once 
that is done.

> Anyway, we can do this I suppose. Instead of directly removing the 
> caching entry in case there is not a match we keep it intact if only the 
> headers or methods are not matched and add those to that cache entry 
> later if the preflight request turns out ok.

Yeah, that's what my implementation does. The only thing is that you 
have to remember the exiration time per header/method name.

Alternatively you can make each entry hold origin, target uri, 
credentials flag, expiry time and *one* header or method name.

When making a request, check if there is an entry for each header, as 
well as one for the method (minus whitelisted headers/methods).

When a preflight response is gotten, replace all entries that appear in 
the Access-Control-Allow-Headers/Methods response headers.

>> The one header that I can give a semi good reason to add is
>> Content-Language, which seems to make sense if we think
>> Accept-Language is common enough to be put on the whitelist.
> 
> Content-Language is a response header (it is on the response header 
> whitelist). Accept-Language is already on the whitelist.

Content-Language is allowed both in requests and responses. When in a 
request is describes the language of the entity in the request body (for 
example for a POST).

We already have Content-Language is the resonse whitelist and 
Accept-Language in the request whitelist. Seems logical to also allow 
Content-Language in the request, but it's not a big deal.

/ Jonas

Received on Monday, 15 September 2008 15:10:08 UTC