Re: [AC] Access-Control-Allow-Origin header syntax
On Thu, Sep 25, 2008 at 12:35 PM, Anne van Kesteren [EMAIL PROTECTED] wrote: On Thu, 25 Sep 2008 21:26:05 +0200, Jonas Sicking [EMAIL PROTECTED] wrote: However I think that if we are using URI syntax for these headers we should treat them as URIs and not as opaque strings. Everywhere else in the product URIs are parsed and canonicalized before being compared. We specifically do not use string comparisons. I think for the sake of consistency with the rest of the web platform we should do the same here, anything else is just unexpected behavior. The point is actually that the header does _not_ take a URI. It did at some point, but you didn't like that. It takes the ASCII form of an origin instead, identically to The Web Socket Protocol in HTML 5. What says that an origin is not a URI? Sure, many URIs deny access, but it looks to me like they are still subsets of URIs. If we say that they are not URIs, why not go all out and invent a new syntax, such as http.org.example.www:80 to allow the site http://www.example.org? This would reduce confusion around them being URIs. However I think it would be better to keep them as URIs, while saying that if there is a path, or if the URI is not same-origin as the Origin header then deny access. / Jonas
[widgets] Preferences API
Hi All, I think we should dump the Widgets preferences API in favor of HTML5 DOM's storage API. Basically, preferences API basically replicates what DOM Storage already defines. Also, DOM storage is already implemented across three or four browsers and we can assume the specification to be fairly stable (or hopefully it will be by the time we get to CR). Dumping the preferences API will also avoid problems in the future as HTML5 becomes prevalent in the market. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
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
