Re: [access-control] Implementation comments (credentials flag)
On Tue, 30 Sep 2008 00:36:10 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: Jonas Sicking wrote: Yes, I think it would be helpful to add that information. It wasn't clear that the credentials flag wasn't part of the key until you put it this way (though the spec already clearly says so, just easy to miss). I added a note that says what the primary key is now. (The credentials flag is also part of it now.) [...] So in this case the credentials flag is actually part of the primary key. I.e. the spec says to not update an existing entry if a request is made with the credentials flag set to true, but the cache contains an entry with the credentials flag set to false. Instead a new entry should be created which will only differ in the value of the credentials flag (and possibly in the value of the expiry time). I suspect the simplest solution is to actually make the credentials flag part of the primary key everywhere. Indeed. It didn't seem to be worth the trouble to optimize for public non credentialed requests for URLs that already have a credentialed cache entry. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [access-control] Implementation comments
On Mon, 29 Sep 2008 18:03:43 -0400, Jonas Sicking [EMAIL PROTECTED] wrote: Anne van Kesteren wrote: 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. I've done it this way. The 'progress' and 'load' events are only dispatched if a preflight request has been made. Why just limit to those events? Seems simpler and more future proof to not fire any events on the upload object. That would also cover future events like 'redirect' and 'stall'. I don't see any reason to prevent synthesized events from firing. If we add more events we have to define when they dispatch anyway so that's not a problem. (This is different from whether registered events force a preflight or not, where it does make sense to have a catch-all.) (Will address your other comments later. Currently at a conference in Boston.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [access-control] Implementation comments
Anne van Kesteren wrote: On Mon, 29 Sep 2008 18:03:43 -0400, Jonas Sicking [EMAIL PROTECTED] wrote: Anne van Kesteren wrote: 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. I've done it this way. The 'progress' and 'load' events are only dispatched if a preflight request has been made. Why just limit to those events? Seems simpler and more future proof to not fire any events on the upload object. That would also cover future events like 'redirect' and 'stall'. I don't see any reason to prevent synthesized events from firing. If we add more events we have to define when they dispatch anyway so that's not a problem. (This is different from whether registered events force a preflight or not, where it does make sense to have a catch-all.) I agree we shouldn't prevent synthesized events. But why not say that no ProgressEvents are dispatch at all? Seems like you at least have to prevent 'abort' as well, so why not also 'loadstart' and 'error'. / Jonas
Re: [access-control] Implementation comments
On Mon, 29 Sep 2008 23:53:32 -0400, Jonas Sicking [EMAIL PROTECTED] wrote: I agree we shouldn't prevent synthesized events. But why not say that no ProgressEvents are dispatch at all? That would prevent synthesized ProgressEvent events. Seems like you at least have to prevent 'abort' as well, Why is that? so why not also 'loadstart' and 'error'. We could do that I suppose. It would require doing an origin check before returning on send() in the asynchronous case, but that shouldn't be much of an issue. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [access-control] Implementation comments
Anne van Kesteren wrote: On Mon, 29 Sep 2008 23:53:32 -0400, Jonas Sicking [EMAIL PROTECTED] wrote: I agree we shouldn't prevent synthesized events. But why not say that no ProgressEvents are dispatch at all? That would prevent synthesized ProgressEvent events. I mean that the implementation should not dispatch any ProgressEvents. I don't see a reason that synthesized 'load' or 'progress' events should be prevented, and it doesn't look like those are prevented now. Seems like you at least have to prevent 'abort' as well, Why is that? Otherwise you tell the 'abort' apart from 'error' to do server detection. so why not also 'loadstart' and 'error'. We could do that I suppose. It would require doing an origin check before returning on send() in the asynchronous case, but that shouldn't be much of an issue. Yes, I don't see a reason to do the origin checks after
Re: [access-control] Implementation comments
On Thu, 25 Sep 2008 19:12:54 +0200, Anne van Kesteren [EMAIL PROTECTED] wrote: On Thu, 25 Sep 2008 19:01:57 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: 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. Made change to the specification. http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ (Currently labeled as WD since we're publishing next Tuesday.) 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. I've done it this way. The 'progress' and 'load' events are only dispatched if a preflight request has been made. 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. Added a note explaining the fields are mutually exclusive. Would it be useful to note that (origin, url, method, header) form the primary key of a cache entry? Since it's never needed by the specification in that way I didn't add it, but let me know. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [access-control] Implementation comments
Updated draft: http://dev.w3.org/2006/waf/access-control/ On Mon, 15 Sep 2008 17:08:20 +0200, Jonas Sicking [EMAIL PROTECTED] 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/
[access-control] Implementation comments
"-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> new-zealand-swingers- new-zealand-swingers- Thread Date Refine search new-zealand-swingers- List Id: New-Zealand-Swingers-.googlegroups.com List Help: mailto:New-Zealand-Swingers-+help@googlegroups.com List Subscribe: - Posting Address: mailto:New-Zealand-Swingers-@googlegroups.com List Owner: - Mailing List System: GoogleGroups Archive Localization: Catalan catal Chinese Czech esky Danish Dansk Dutch Nederlands English French Franais German Deutsch Greek Hebrew Hungarian magyar Indonesian Bahasa Indonesia Italian Italiano Japanese Korean Lithuanian lietuvi kalba Norwegian Norsk Polish polski Portuguese Portugus Romanian Romn Russian Serbian srpski jezik Spanish Espaol Swedish Svenska Turkish Trke Ukranian Custom Logo: Article Writing amp;amp; Submission Service To 5,700+ Sites! robert-allen-home-business -- Thread -- -- Date -- Article Wrounded set? What would be the downside of always remembering that a server has granted a specific header for a specific amount of time and only delete that grant if the header exires, is updated by a later request, or is removed due to a failed security check? 3. I think we should look into putting more headers on the white list that doesn't require preflights. Specifically the following headers seems like they should be safe Range If-Unmodified-Since Cache-Control: no-cache since they can already happen in an HTML implementation that has a local cache (which I think is pretty much every implementation that I know of). I'm happy to add whatever headers people are ok with. I don't really feel knowledgeable enough to make security judgments about them though. Having said that, I would rather avoid adding header names of which only certain values are ok. Maciej Stachowiak wrote: Do caching HTML implementations normally send Range without If-Range? In general I would be wary of extending the set of headers allowed without preflight. Are there specific common use cases for these? I have heard Cache-Control: no-cache is fairly commonly used, though the only use cases that I can think of are for servers that don't properly set cache related headers, so it's possibly not something we should optimize for. The one header that I can give a semi good reason to add is Content-Language, which seems to make sense if we think Accept-Language is common enough to be put on the whitelist. However I'd be fine with leaving the header list as is for now and possibly whitelist more headers in a future version of the spec. / Jonas
