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 16:09:34 +0200
To: "Jonas Sicking" <jonas@sicking.cc>
Cc: public-webapps@w3.org
Message-ID: <op.uh1ix81b64w2qv@annevk-t60.oslo.opera.com>

Updated draft:


On Mon, 15 Sep 2008 17:08:20 +0200, Jonas Sicking <jonas@sicking.cc> wrote:
> Anne van Kesteren wrote:
>>  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 think it is more arbitrary. The various content types actually affect  
request semantics and that different access control policies apply seems  
reasonable. Whether upload events are dispatched is different.

> 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. If a preflight request has been made dispatch  
'progress' events to the upload member.

> 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 :-)

> 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.

> 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.


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

I picked this route. Please review! :-)

> 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.


Anne van Kesteren
Received on Thursday, 25 September 2008 14:10:13 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:12 UTC