W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2008

Re: [access-control] Implementation comments

From: Anne van Kesteren <annevk@opera.com>
Date: Thu, 25 Sep 2008 19:12:54 +0200
To: "Jonas Sicking" <jonas@sicking.cc>
Cc: public-webapps@w3.org
Message-ID: <op.uh1rfsdc64w2qv@annevk-t60.oslo.opera.com>

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.


>> 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
Received on Thursday, 25 September 2008 17:13:37 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 February 2015 14:36:31 UTC