Re: [access-control] Implementation comments

Anne van Kesteren wrote:
>> Then I'll specify the former as special casing those methods here is 
>> something I rather not do. I'd much rather have addEventListener, 
>> addEventListenerNS, onprogress, etc. work consistently.
> 
> I've done it this way. The 'progress' and 'load' events are only 
> dispatched if a preflight request has been made.

Why just limit to those events? Seems simpler and more future proof to 
not fire any events on the upload object. That would also cover future 
events like 'redirect' and 'stall'.

>>> Looks great. The only thing I'd add is to be more explicit around the
>>> initial description of the cache that each cache entry always has
>>> exactly one of 'method' and 'header' empty and the other non-empty.
>>> I.e. that either of them always exist, but never both.
>>
>> Ok, will fix that tomorrow. Got to go now.
> 
> Added a note explaining the fields are mutually exclusive. Would it be 
> useful to note that (origin, url, method, header) form the primary key 
> of a cache entry? Since it's never needed by the specification in that 
> way I didn't add it, but let me know.

Yes, I think it would be helpful to add that information. It wasn't 
clear that the credentials flag wasn't part of the key until you put it 
this way (though the spec already clearly says so, just easy to miss).

Another thing that I think needs to be more clear is the fact that the 
preflight request is done without credentials. Right now it is just 
mentioned in a parenthesis saying that "No credentials, entity body, et 
cetera, are to be included". In fact, in most implementations I would 
imagine that credentials has to be specifically excluded since the 
normal mode of operation is to include credentials (in fact, our network 
code didn't have the ability to make cookie-less requests).

/ Jonas

Received on Monday, 29 September 2008 22:06:16 UTC