Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On Thu, 23 Jun 2011, Per-Erik Brodin wrote: Another question was raised in https://bugs.webkit.org/show_bug.cgi?id=61862#c17 The origin set on the dispatched message events is specified to be the origin of the event stream's URL. Is this the URL passed to the EventSource constructor or the URL after some potential redirects (even temporary)? Fixed to be the final URL (it used to not matter). On Thu, 23 Jun 2011, ilya goberman wrote: It is personalized on something that we send in the URL (cleint id I mentioned below) which identifies which user's data is requested. We do not use cookies. Ian was kind enough to explain to me how EventSource will function. Apparently EventSource will have withCredentials always set to true (false is not allowed). That means that using * for Access-Control-Allow-Origin will never work for the EventSource and I have to put request's Origin value in the response's Access-Control-Allow-Origin to enable CORS. It is not a huge deal, unless there are some proxies that will not pass Origin through (I do not really know if there are any). Thanks FWIW, I've since changed the spec so that you can specify whether to send credentials or not. When credentials aren't sent, you can use the * form. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On 2011-06-21 20:38, Ian Hickson wrote: 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? No, I think the resource sharing check failures are covered by the sentence Any other HTTP response code not listed here, and any network error [..] must cause the user agent to fail the connection. OK, is Last-Event-ID also not a custom header then? There are no custom headers here. Why would you think there are? The source of confusion was the fact that the list of simple headers in the CORS spec contained the Last-Event-ID header. Now that it has been removed and custom headers have been replaced by author headers it is clear that neither of the headers used with EventSource will trigger a preflight request. Another question was raised in https://bugs.webkit.org/show_bug.cgi?id=61862#c17 The origin set on the dispatched message events is specified to be the origin of the event stream's URL. Is this the URL passed to the EventSource constructor or the URL after some potential redirects (even temporary)? //Per-Erik
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On Sat, Jun 18, 2011 at 7:06 AM, ilya goberman gober...@msn.com wrote: We are a financial market data vendor streaming real-time market data. We currently have a cluster of servers servicing market data. These servers are hosted by our company and therefore have different domain from the client web pages domain. We try to have Comet connection to stream data from servers to clients (as opposed to long poll). The data _is_ personalized based on user subscription request. We generate client id we send with every comet request to identify clients. We currently use XHR, but it has limitation of growing response string and requiring periodic disconnects, so EventSource is just another delivery mechanism that does not require disconnects. So again 2 things: 1) EventSource is not really that different from XHR from our perspective, the only advantage is that it does not require periodic disconnects. (Actually now it does require disconnects because it incorrectly buffers response (fixed in the latest WebKit)). 2) XHR CORS changes should be backward compatible. We do not really want to find out that our servers stop working because a new browser is released. Indeed, changing XHR CORS is not really an option at this point given how widely it has been deployed. No-one is proposing to do that. And EventSource is generally agreed to be similar enough to XHR that it could share security model. So with that in mind, I still don't understand how you are using XHR and CORS today. On one hand you are saying that you are sending a header like: Access-Control-Allow-Origin: * On the other hand you are saying that you are sending personalized data. Is this data personalized based on the user's cookies? Or based on something that you send in the URL which identifies which user's data is requested? The reason I'm asking is that the CORS specification specifically does not allow the Access-Control-Allow-Origin: * header in requests that use cookies. And I believe that all existing CORS implementations follow that part of the specification. If you send that header the browser should reject the response and the XHR should just give you an error code. Again, note that this is not a change to CORS, this is how CORS has always been specified and implemented. / Jonas
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On Thu, Jun 23, 2011 at 5:09 PM, ilya goberman gober...@msn.com wrote: Jonas, It is personalized on something that we send in the URL (cleint id I mentioned below) which identifies which user's data is requested. We do not use cookies. Ian was kind enough to explain to me how EventSource will function. Apparently EventSource will have withCredentials always set to true (false is not allowed). That means that using * for Access-Control-Allow-Origin will never work for the EventSource and I have to put request's Origin value in the response's Access-Control-Allow-Origin to enable CORS. It is not a huge deal, unless there are some proxies that will not pass Origin through (I do not really know if there are any). The main argument for always having withCredentials set to true is that there was a lack of use cases for setting it to false. However this appears that whatever you're building is at least one such use case. I'm actually a bit reluctant to use the more complex and sensitive security model by default. It's very easy for people to share more information than they need and would be a reason for people to use XHR instead of EventSource which is unfortunate. I think we'll end up prototyping this soon in Firefox at which point this feature will have to pass through security review when we'll look at this more closely. / Jonas
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On Mon, 20 Jun 2011 13:14:54 +0200, Jonas Sicking jo...@sicking.cc wrote: Though possibly a safer way to think about it is that the Content-Type header should always be inspected to see if a preflight is needed, no matter if the header is set by the page or by the implementation. I think I like the latter approach more since it seems safer. Bah, Content-Type sucks. I created a new thread on public-weba...@w3.org to further discuss this (as well as something else I noticed): http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1222.html (I already renamed custom request headers to author request headers. I hope that will reduce some of the confusion I and others had with respect to Last-Event-ID and Cache-Control. I should probably add a note too at some point, once I find an appropriate location.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On 2011-06-20 21:28, Jonas Sicking wrote: On Mon, Jun 20, 2011 at 7:13 AM, Per-Erik Brodin per-erik.bro...@ericsson.com wrote: On 2011-06-20 12:53, Jonas Sicking wrote: Headers that the implementation adds doesn't need to be added to this list. For example the Host header is set by the browser in almost all situations, but it does not need to be added to the list of simple headers. Indeed, adding in there would an out right bad idea. So I'm not convinced that the Last-Event-ID header needs to be in the list. Only custom request headers are matched against the list of simple headers and Host is not a custom header set by the EventSource implementation, hence there is no need to add it to the list. In XHR Level 2 the custom request headers are the author request headers. An option would be to always match the list of simple headers against author request headers only. It seems like you are saying exactly what I was saying? Am I missing something? 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. Since this has the downside that all new specifications that want to use CORS will have to rely on the CORS spec being updated if any new custom headers are going to be used, I agree with your proposal to match only author supplied headers against the list of simple headers. //Per-Erik
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
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. 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? //Per-Erik
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
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=6254to=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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On Sun, 19 Jun 2011 00:25:57 +0200, Per-Erik Brodin per-erik.bro...@ericsson.com wrote: 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. Agreed. I can add that to CORS. I already added Last-Event-ID for that reason, but somehow missed Cache-Control. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On Mon, Jun 20, 2011 at 3:22 AM, Anne van Kesteren ann...@opera.com wrote: On Sun, 19 Jun 2011 00:25:57 +0200, Per-Erik Brodin per-erik.bro...@ericsson.com wrote: 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. Agreed. I can add that to CORS. I already added Last-Event-ID for that reason, but somehow missed Cache-Control. Wait, we don't have to add any headers to the CORS spec just because implementations of various specs needs to send those without doing preflight. The list of simple headers only affects which headers the *page* can immediately set without a preflight being required, for example through features like XMLHttpRequest.setRequestHeader. Headers that the implementation adds doesn't need to be added to this list. For example the Host header is set by the browser in almost all situations, but it does not need to be added to the list of simple headers. Indeed, adding in there would an out right bad idea. So I'm not convinced that the Last-Event-ID header needs to be in the list. / Jonas
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On Mon, 20 Jun 2011 12:53:02 +0200, Jonas Sicking jo...@sicking.cc wrote: On Mon, Jun 20, 2011 at 3:22 AM, Anne van Kesteren ann...@opera.com wrote: Agreed. I can add that to CORS. I already added Last-Event-ID for that reason, but somehow missed Cache-Control. Wait, we don't have to add any headers to the CORS spec just because implementations of various specs needs to send those without doing preflight. The list of simple headers only affects which headers the *page* can immediately set without a preflight being required, for example through features like XMLHttpRequest.setRequestHeader. Headers that the implementation adds doesn't need to be added to this list. For example the Host header is set by the browser in almost all situations, but it does not need to be added to the list of simple headers. Indeed, adding in there would an out right bad idea. So I'm not convinced that the Last-Event-ID header needs to be in the list. We could add Host as authors cannot set that anyway. But what you say makes sense. I will remove Last-Event-ID and add a note about how that list works. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On Mon, Jun 20, 2011 at 3:57 AM, Anne van Kesteren ann...@opera.com wrote: On Mon, 20 Jun 2011 12:53:02 +0200, Jonas Sicking jo...@sicking.cc wrote: On Mon, Jun 20, 2011 at 3:22 AM, Anne van Kesteren ann...@opera.com wrote: Agreed. I can add that to CORS. I already added Last-Event-ID for that reason, but somehow missed Cache-Control. Wait, we don't have to add any headers to the CORS spec just because implementations of various specs needs to send those without doing preflight. The list of simple headers only affects which headers the *page* can immediately set without a preflight being required, for example through features like XMLHttpRequest.setRequestHeader. Headers that the implementation adds doesn't need to be added to this list. For example the Host header is set by the browser in almost all situations, but it does not need to be added to the list of simple headers. Indeed, adding in there would an out right bad idea. So I'm not convinced that the Last-Event-ID header needs to be in the list. We could add Host as authors cannot set that anyway. But what you say makes sense. I will remove Last-Event-ID and add a note about how that list works. One thing to keep in mind though is that in the case of XHR, the Content-Type header is often in direct control of the page, even through means other than setRequestHeader. For example by creating a Blob with a specific content type using the .slice method. / Jonas
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On Mon, 20 Jun 2011 13:02:38 +0200, Jonas Sicking jo...@sicking.cc wrote: One thing to keep in mind though is that in the case of XHR, the Content-Type header is often in direct control of the page, even through means other than setRequestHeader. For example by creating a Blob with a specific content type using the .slice method. Maybe Blob and File when not packaged in FormData should force a preflight then? -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On Mon, Jun 20, 2011 at 4:06 AM, Anne van Kesteren ann...@opera.com wrote: On Mon, 20 Jun 2011 13:02:38 +0200, Jonas Sicking jo...@sicking.cc wrote: One thing to keep in mind though is that in the case of XHR, the Content-Type header is often in direct control of the page, even through means other than setRequestHeader. For example by creating a Blob with a specific content type using the .slice method. Maybe Blob and File when not packaged in FormData should force a preflight then? I don't see a reason to do that other than when the Content-Type has a value other than the ones listed in the simple headers description. All that I'm saying is that for XHR, there are at least two APIs which allows the page to set headers, .setRequestHeader and .send. Though possibly a safer way to think about it is that the Content-Type header should always be inspected to see if a preflight is needed, no matter if the header is set by the page or by the implementation. I think I like the latter approach more since it seems safer. / Jonas
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On 2011-06-20 12:53, Jonas Sicking wrote: Headers that the implementation adds doesn't need to be added to this list. For example the Host header is set by the browser in almost all situations, but it does not need to be added to the list of simple headers. Indeed, adding in there would an out right bad idea. So I'm not convinced that the Last-Event-ID header needs to be in the list. Only custom request headers are matched against the list of simple headers and Host is not a custom header set by the EventSource implementation, hence there is no need to add it to the list. In XHR Level 2 the custom request headers are the author request headers. An option would be to always match the list of simple headers against author request headers only. //Per-Erik
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On Mon, Jun 20, 2011 at 7:13 AM, Per-Erik Brodin per-erik.bro...@ericsson.com wrote: On 2011-06-20 12:53, Jonas Sicking wrote: Headers that the implementation adds doesn't need to be added to this list. For example the Host header is set by the browser in almost all situations, but it does not need to be added to the list of simple headers. Indeed, adding in there would an out right bad idea. So I'm not convinced that the Last-Event-ID header needs to be in the list. Only custom request headers are matched against the list of simple headers and Host is not a custom header set by the EventSource implementation, hence there is no need to add it to the list. In XHR Level 2 the custom request headers are the author request headers. An option would be to always match the list of simple headers against author request headers only. It seems like you are saying exactly what I was saying? Am I missing something? / Jonas
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On Sun, 19 Jun 2011, Per-Erik Brodin wrote: On 2011-06-17 21:57, Ian Hickson wrote: On Wed, 1 Jun 2011, ilya goberman wrote: Can EventSource be enhanced to support cross-domain requests via Access-Control-Allow-Origin header, just like it is already done for XHR? See http://en.wikipedia.org/wiki/XMLHttpRequest#Cross-domain_requests. Done. Great news! The same-origin check in step 4 under When the EventSource() constructor is invoked .. is still present. Oops. Fixed. 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? 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. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On Sat, 18 Jun 2011 00:31:42 +0200, Ian Hickson i...@hixie.ch wrote: The reason we _didn't_ send credentials by default for img was that most cross-origin images are going to be static, and it would be a huge pain for the server to have to do per-connection work to determine the HTTP headers each time. With EventSource, that's a non-issue, since the server is going to have to do lots of much heavier per-connection work anyway. I think we should change CORS to allow * for credentialed requests. People have already asked for that. 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.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On Sat, Jun 18, 2011 at 1:01 AM, Anne van Kesteren ann...@opera.com wrote: On Sat, 18 Jun 2011 00:31:42 +0200, Ian Hickson i...@hixie.ch wrote: The reason we _didn't_ send credentials by default for img was that most cross-origin images are going to be static, and it would be a huge pain for the server to have to do per-connection work to determine the HTTP headers each time. With EventSource, that's a non-issue, since the server is going to have to do lots of much heavier per-connection work anyway. I think we should change CORS to allow * for credentialed requests. People have already asked for that. 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.) Without the crossorigin attribute, we'd need to send the Origin header with every image request. That might or might not be desirable, but it's something to consider. Adam
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On 06/18/2011 01:31 AM, Ian Hickson wrote: On Fri, 17 Jun 2011, Jonas Sicking wrote: On Wed, 1 Jun 2011, Jonas Sicking wrote: We should probably consider adding the ability to specify if you want the request to happen with or without credentials (and default to the safe option which is without credentials). Why? For the same reasons that we're doing it for XHR and forimgs. For EventSource, the vast majority of streams are going to be user-specific, as far as I can tell, so the default should probably just be to send credentials. It is a very strange API inconsistency if XHR defaults to credentials=false, but EventSource to credentials=true. -Olli
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On Sat, 18 Jun 2011 15:23:21 +0200, Olli Pettay olli.pet...@helsinki.fi wrote: It is a very strange API inconsistency if XHR defaults to credentials=false, but EventSource to credentials=true. Not if we do not expose all of the features XMLHttpRequest has. Besides, .withCredentials was a bad idea. That is where the inconsistency with other cross-origin requests started. (In retrospect I very much wish I fought harder to keep the consistency.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On 2011-06-17 21:57, Ian Hickson wrote: On Wed, 1 Jun 2011, ilya goberman wrote: Can EventSource be enhanced to support cross-domain requests via Access-Control-Allow-Origin header, just like it is already done for XHR? See http://en.wikipedia.org/wiki/XMLHttpRequest#Cross-domain_requests. Done. Great news! The same-origin check in step 4 under When the EventSource() constructor is invoked .. is still present. 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. 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. //Per-Erik
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On Wed, 1 Jun 2011, ilya goberman wrote: Can EventSource be enhanced to support cross-domain requests via Access-Control-Allow-Origin header, just like it is already done for XHR? See http://en.wikipedia.org/wiki/XMLHttpRequest#Cross-domain_requests. Done. On Wed, 1 Jun 2011, Jonas Sicking wrote: We should probably consider adding the ability to specify if you want the request to happen with or without credentials (and default to the safe option which is without credentials). Why? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On Fri, Jun 17, 2011 at 12:57 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 1 Jun 2011, ilya goberman wrote: Can EventSource be enhanced to support cross-domain requests via Access-Control-Allow-Origin header, just like it is already done for XHR? See http://en.wikipedia.org/wiki/XMLHttpRequest#Cross-domain_requests. Done. On Wed, 1 Jun 2011, Jonas Sicking wrote: We should probably consider adding the ability to specify if you want the request to happen with or without credentials (and default to the safe option which is without credentials). Why? For the same reasons that we're doing it for XHR and for imgs. People will likely want to create even streams that are specific to a user. For example indicating that the value of a users stock portfolio has gone up or down. / Jonas
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On Fri, 17 Jun 2011, Jonas Sicking wrote: On Wed, 1 Jun 2011, Jonas Sicking wrote: We should probably consider adding the ability to specify if you want the request to happen with or without credentials (and default to the safe option which is without credentials). Why? For the same reasons that we're doing it for XHR and for imgs. For EventSource, the vast majority of streams are going to be user-specific, as far as I can tell, so the default should probably just be to send credentials. (That's what happens with script, the current way people try to solve this problem.) The reason we _didn't_ send credentials by default for img was that most cross-origin images are going to be static, and it would be a huge pain for the server to have to do per-connection work to determine the HTTP headers each time. With EventSource, that's a non-issue, since the server is going to have to do lots of much heavier per-connection work anyway. People will likely want to create even streams that are specific to a user. For example indicating that the value of a users stock portfolio has gone up or down. Agreed. But what's the use case for _not_ sending credentials here? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On Fri, Jun 17, 2011 at 5:31 PM, ilya goberman gober...@msn.com wrote: I do not really understand what specify the request to happen with credentials really mean. Can someone explain or point to an example? My opinion is that it should be the same for the XHR and EventSource and should also be backward compatible. 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. Thanks I'd love to hear more about this as it's directly related to the question Hixie asked. I take it you are sending that header from some set of URLs on your servers, which are then loaded using XHR (XDR in IE) from other sites? And you are wanting to (or perhaps are already) structuring that data such that it can be used with EventSource once browsers support it, and support using it in cross-site scenarios? Am I correct so far? If so, what type of data are you returning from these URLs? Given the header you are sending, it seems like this is not personalized data, but rather generic data which looks the same no matter which users browser is reading it. Or more specifically, you are not personalizing the response from these requests based on the users cookies, is this correct? Thanks! / Jonas
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
I brought this up a while ago as well: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-October/028868.html Echoing Ilya: this is actually a very important feature because generally you don't want long-lived connections (HTTP streaming) and short-lived connections (web page requests) going through the same hosts. -Nicholas __ Commander Lock: Dammit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of ilya goberman Sent: Wednesday, June 01, 2011 11:24 AM To: whatwg@lists.whatwg.org Subject: [whatwg] Enhancement request: change EventSource to allow cross-domain access Can EventSource be enhanced to support cross-domain requests via Access-Control-Allow-Origin header, just like it is already done for XHR? See http://en.wikipedia.org/wiki/XMLHttpRequest#Cross-domain_requests. I filed a request with WebKit bugzilla and they suggested to send it to you: https://bugs.webkit.org/show_bug.cgi?id=61862 The rationale and use cases are exactly the same as for XHR: it can be useful to access different domains. Is support for EventSource cross domains planned at all? It is supposedly one of the most requested features, but I do not know how it is tracked. Thanks
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On Wed, Jun 1, 2011 at 11:23 AM, ilya goberman gober...@msn.com wrote: Can EventSource be enhanced to support cross-domain requests via Access-Control-Allow-Origin header, just like it is already done for XHR? See http://en.wikipedia.org/wiki/XMLHttpRequest#Cross-domain_requests. I filed a request with WebKit bugzilla and they suggested to send it to you: https://bugs.webkit.org/show_bug.cgi?id=61862 The rationale and use cases are exactly the same as for XHR: it can be useful to access different domains. Is support for EventSource cross domains planned at all? It is supposedly one of the most requested features, but I do not know how it is tracked. I absolutely think we should do this. I was in fact quite surprised to find that this wasn't already the case. Getting event streams from other sites seems like a prime use case for EventSource. We should probably consider adding the ability to specify if you want the request to happen with or without credentials (and default to the safe option which is without credentials). / Jonas
