Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access

2011-12-06 Thread Ian Hickson
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

2011-06-23 Thread Jonas Sicking
On Thu, Jun 23, 2011 at 5:09 PM, ilya goberman  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

2011-06-23 Thread Jonas Sicking
On Sat, Jun 18, 2011 at 7:06 AM, ilya goberman  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

2011-06-23 Thread Per-Erik Brodin

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

2011-06-22 Thread Anne van Kesteren

On Mon, 20 Jun 2011 13:14:54 +0200, Jonas Sicking  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

2011-06-21 Thread Ian Hickson
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 , 
, , 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  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

2011-06-21 Thread Per-Erik Brodin

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

2011-06-21 Thread Per-Erik Brodin

On 2011-06-20 21:28, Jonas Sicking wrote:

On Mon, Jun 20, 2011 at 7:13 AM, Per-Erik Brodin
  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

2011-06-20 Thread Ian Hickson
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

2011-06-20 Thread Jonas Sicking
On Mon, Jun 20, 2011 at 7:13 AM, Per-Erik Brodin
 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

2011-06-20 Thread Per-Erik Brodin

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

2011-06-20 Thread Jonas Sicking
On Mon, Jun 20, 2011 at 4:06 AM, Anne van Kesteren  wrote:
> On Mon, 20 Jun 2011 13:02:38 +0200, Jonas Sicking  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

2011-06-20 Thread Anne van Kesteren

On Mon, 20 Jun 2011 13:02:38 +0200, Jonas Sicking  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

2011-06-20 Thread Jonas Sicking
On Mon, Jun 20, 2011 at 3:57 AM, Anne van Kesteren  wrote:
> On Mon, 20 Jun 2011 12:53:02 +0200, Jonas Sicking  wrote:
>>
>> On Mon, Jun 20, 2011 at 3:22 AM, Anne van Kesteren 
>> 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

2011-06-20 Thread Anne van Kesteren

On Mon, 20 Jun 2011 12:53:02 +0200, Jonas Sicking  wrote:
On Mon, Jun 20, 2011 at 3:22 AM, Anne van Kesteren   
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

2011-06-20 Thread Jonas Sicking
On Mon, Jun 20, 2011 at 3:22 AM, Anne van Kesteren  wrote:
> On Sun, 19 Jun 2011 00:25:57 +0200, Per-Erik Brodin
>  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

2011-06-20 Thread Anne van Kesteren
On Sun, 19 Jun 2011 00:25:57 +0200, Per-Erik Brodin  
 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

2011-06-18 Thread Per-Erik Brodin

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

2011-06-18 Thread Anne van Kesteren
On Sat, 18 Jun 2011 15:23:21 +0200, Olli Pettay   
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

2011-06-18 Thread Olli Pettay

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 fors.


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

2011-06-18 Thread Adam Barth
On Sat, Jun 18, 2011 at 1:01 AM, Anne van Kesteren  wrote:
> On Sat, 18 Jun 2011 00:31:42 +0200, Ian Hickson  wrote:
>>
>> The reason we _didn't_ send credentials by default for  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  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

2011-06-18 Thread Anne van Kesteren

On Sat, 18 Jun 2011 00:31:42 +0200, Ian Hickson  wrote:
The reason we _didn't_ send credentials by default for  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  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

2011-06-17 Thread Jonas Sicking
On Fri, Jun 17, 2011 at 5:31 PM, 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?
> 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

2011-06-17 Thread Ian Hickson
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 s.

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 

Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access

2011-06-17 Thread Jonas Sicking
On Fri, Jun 17, 2011 at 12:57 PM, 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.
>
>
> 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 s.
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

2011-06-17 Thread Ian Hickson
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

2011-06-02 Thread Nicholas Zakas
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

2011-06-01 Thread Jonas Sicking
On Wed, Jun 1, 2011 at 11:23 AM, 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.
>
> 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


[whatwg] Enhancement request: change EventSource to allow cross-domain access

2011-06-01 Thread ilya goberman

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