On Fri, 17 Jun 2011, ilya goberman wrote: > > I do not really understand what "specify the request to happen with > credentials" really mean. Can someone explain or point to an example?
It just means that the user's relevant cookies are included in the request. > My opinion is that it should be the same for the XHR and EventSource and > should also be backward compatible. They are. > We currently generate Access-Control-Allow-Origin:* in the server > responses for the XHR requests to allow cross-domain calls (and do not > really do anything beyond that) and I hope it will not be broken with > these new "credentials validation" changes. For EventSource (and for XHR when withCredentials is set) you need to explicitly give the origin that was included in the request in the response, instead of just using "*". Since EventSource is only useful when the server is dynamic, this isn't really a big deal. Just put the relevant logic in whatever script is generating the event stream. On Sat, 18 Jun 2011, ilya goberman wrote: > > I wish I could read what changes to XHR/ EventSource are done in some > spec... It's all public: http://www.whatwg.org/specs/web-apps/current-work/complete/comms.html#server-sent-events http://html5.org/tools/web-apps-tracker?from=6254&to=6255 On Sat, 18 Jun 2011, Anne van Kesteren wrote: > > I think we should change CORS to allow * for credentialed requests. > People have already asked for that. I don't have a strong opinion on this (though I do think the concern that authors will shoot themselves in the foot if we don't have at least a small barrier here is a valid one). Currently, the changes to <img>, <video>, <audio>, and EventSource are agnostic to this. > That would also allow dropping the crossorigin="" attribute which > complicates the request model for the elements it is applicable to a > lot. (Too much, in my opinion.) > > (I designed CORS in such a way it could be used for <img> and such > without the need to introduce new syntax.) We still need crossorigin="" actually because some sites break if you send an Origin: header on image requests. On Sat, 18 Jun 2011, Olli Pettay wrote: > > It is a very strange API inconsistency if XHR defaults to > credentials=false, but EventSource to credentials=true. EventSource doesn't really make much sense with credentials=false most of the time, so it seems simpler for authors to just not bother asking them to set it each time explicitly. On Tue, 21 Jun 2011, Per-Erik Brodin wrote: > > What I am saying is that currently CORS defines "custom request headers" > and that can be interpreted as all headers that are set by the API > implementations (such as "Last-Event-ID" set by EventSource but not > including the headers normally set by the HTTP loader, such as "Host"), > regardless if they are author supplied or not. Custom request headers is defined unambiguously as "A list of custom headers for the request. Empty, unless explicitly set". Since EventSource does not explicitly set it, it is empty for EventSource's purposes. On Tue, 21 Jun 2011, Per-Erik Brodin wrote: > On 2011-06-20 21:59, Ian Hickson wrote: > > > According to the CORS specification, a request is not to be > > > terminated even when the resource sharing check fails. However, when > > > using CORS with EventSource I think it may be justified since the > > > response is typically not returned right away. > > > > Not sure what you mean here. Could you elaborate? > > I misread the sentence "Do not actually terminate the request." in the > CORS spec as applying to both the resource sharing check pass and > failure cases. Ok. No change is require here then right? > > > The Cache-Control request header used with EventSource is not in the > > > list of simple request headers and a preflight request is not really > > > an option here in my opinion. > > > > Not sure what you mean by "simple request headers". The Cache-Control > > header isn't a custom header, so it doesn't affect whether you use a > > preflight or not. I've clarified the spec. > > OK, is Last-Event-ID also not a custom header then? There are no custom headers here. Why would you think there are? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
