Re: [access-control] Implementation comments

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.

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.

>> 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).
>
> Ok. Not really a problem and implementations comments are great and welcome,
> but since the draft was stable for over a month I was hoping we could take
> it to Last Call and actually move it forward per W3C process. Too optimistic
> I guess :-)

I think these details are small enough that we can transition into
Last Call. I suspect we'll keep finding minor things like this for a
while, but that should stop of from getting into CR as I understand
it.

I do actually have another issue, i'll start a separate thread on that.

>> 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.
>
> The attachment make it.

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.

Received on Thursday, 25 September 2008 17:02:35 UTC