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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
...@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
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:
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
29 matches
Mail list logo
