Re: [access-control] Implementation comments

On Thu, 25 Sep 2008 19:01:57 +0200, Jonas Sicking <jonas@sicking.cc> wrote:
> On Thu, Sep 25, 2008 at 7:09 AM, Anne van Kesteren <annevk@opera.com>  
> wrote:
>>> I agree it's unfortunate, but I don't have a better alternative.
>>
>> Ok, lets try to formalize yours a bit more clearly (to me anyway): If  
>> the upload member has event listeners registered for the 'progress'  
>> event before send() is invoked pass some kind of force preflight flag  
>> to cross-site
>> access request.
>
> We'd also need to do it if 'load' has been registered. I would in
> general say that we should force it if any events have been
> registered. That will make it more compatible with future versions of
> the AC spec. For example say that a future version of the
> ProgressEvents spec adds a 'redirect' event or a 'stalled' event we'd
> want to force preflight as well.

Fair enough.


> As far as what to do when listeners are registered after send has been
> called I can see two solutions:
>
> * Registering listeners works just as usual, however no events are  
> dispatched.
> * calling addEventListener(NS) on the upload object throws an exception.
>
> I'm sort of inclined towards the latter since not firing is basically
> the same as silently failing, which can be hard for developers to
> debug. Implementations could log this into a developer logging
> mechanism if one is available (we have an error console in firefox),
> however I'm not really a fan of relying on this, and it only helps for
> local debugging.
>
> I'm in general ok either way though.

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.


> Sorry, i meant that i attached it along with the AC implementation in
> our bug database. I'll attach it here once it is more complete.

Ok.


>> I picked this route. Please review! :-)
>
> 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.



-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Thursday, 25 September 2008 17:13:37 UTC