- 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
Updated draft: http://dev.w3.org/2006/waf/access-control/ 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. Cool! > 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. Added. -- Anne van Kesteren <http://annevankesteren.nl/> <http://www.opera.com/>
Received on Thursday, 25 September 2008 14:10:13 UTC