Usually,
- IETF HyBi ML
http://www.ietf.org/mail-archive/web/hybi/current/maillist.html for
protocol stuff
- Here or WHATWG ML
https://lists.w3.org/Archives/Public/public-whatwg-archive/ for API stuff
On Thu, Feb 5, 2015 at 11:07 PM, Michiel De Mey de.mey.mich...@gmail.com
wrote:
Standardizing
On Thu, Feb 5, 2015 at 10:57 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Feb 5, 2015 at 2:48 PM, Bjoern Hoehrmann derhoe...@gmx.net
wrote:
A Websocket connection is established by making a HTTP Upgrade request,
and the protocol is HTTP unless and until the connection is upgraded.
On Thu, Feb 5, 2015 at 2:39 PM, Takeshi Yoshino tyosh...@google.com wrote:
To prevent WebSocket from being abused to attack existing HTTP servers
from malicious non-simple cross-origin requests, we need to have WebSocket
clients to do some preflight to verify that the server is not an HTTP
On Thu, Feb 5, 2015 at 2:39 PM, Florian Bösch pya...@gmail.com wrote:
On Thu, Feb 5, 2015 at 2:35 PM, Anne van Kesteren ann...@annevk.nl wrote:
Wouldn't that require the endpoint to support two protocols? That
sounds suboptimal.
CORS and Websockets are two separate protocols which each work
On Thu, Feb 5, 2015 at 2:48 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote:
A Websocket connection is established by making a HTTP Upgrade request,
and the protocol is HTTP unless and until the connection is upgraded.
Sure, but the server can get away with supporting a very limited
subset of
On Thu, Feb 5, 2015 at 1:27 PM, Florian Bösch pya...@gmail.com wrote:
CORS is an adequate protocol to allow for additional headers, and websocket
requests could be subjected to CORS (I'm not sure what the current client
behavior is in that regard, but I'm guessing they enforce CORS on websocket
On Thu, Feb 5, 2015 at 2:35 PM, Anne van Kesteren ann...@annevk.nl wrote:
Wouldn't that require the endpoint to support two protocols? That
sounds suboptimal.
CORS and Websockets are two separate protocols which each work off and by
themselves, there is no change required to either to make
The websocket wire protocol only comes into effect after a successful
handshake. The handshake involves a request to the endpoint by the client
(typically a GET) and a response by the endpoint (101 switching protocols).
As such websockets themselves do not concern themselves with headers and
the
On Thu, Feb 5, 2015 at 10:41 PM, Florian Bösch pya...@gmail.com wrote:
On Thu, Feb 5, 2015 at 2:39 PM, Takeshi Yoshino tyosh...@google.com
wrote:
To prevent WebSocket from being abused to attack existing HTTP servers
from malicious non-simple cross-origin requests, we need to have WebSocket
* Anne van Kesteren wrote:
On Thu, Feb 5, 2015 at 2:48 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote:
A Websocket connection is established by making a HTTP Upgrade request,
and the protocol is HTTP unless and until the connection is upgraded.
Sure, but the server can get away with supporting a
To prevent WebSocket from being abused to attack existing HTTP servers from
malicious non-simple cross-origin requests, we need to have WebSocket
clients to do some preflight to verify that the server is not an HTTP
server that don't understand CORS. We could do e.g. when a custom header is
* Anne van Kesteren wrote:
On Thu, Feb 5, 2015 at 2:29 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote:
It seems to me that pre-flight requests would happen prior to opening
a Websocket connection, i.e. before requirements of the Websocket proto-
col apply, so this would have to be covered by the
On Thu, Feb 5, 2015 at 2:44 PM, Takeshi Yoshino tyosh...@google.com wrote:
IIUC, CORS prevents clients from issuing non-simple cross-origin request
(even idempotent methods) without verifying that the server understands
CORS. That's realized by preflight.
Incorrect, the browser will perform
Standardizing the approach would definitely help developers,
however where will we communicate this?
On February 5, 2015 at 3:04:35 PM, Takeshi Yoshino (tyosh...@google.com) wrote:
On Thu, Feb 5, 2015 at 10:57 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Feb 5, 2015 at 2:48 PM,
Well,
1) Clients do apply CORS to WebSocket requests already (and might've
started doing so quite some time ago) and everything's fine and you don't
need to change anything.
2) Clients do not apply CORS to WebSocket requests, and you're screwed,
because any change you make will break existing
On Thu, Feb 5, 2015 at 2:29 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote:
It seems to me that pre-flight requests would happen prior to opening
a Websocket connection, i.e. before requirements of the Websocket proto-
col apply, so this would have to be covered by the API specification in-
http://www.w3.org/TR/cors/#cross-origin-request-0
2. If the following conditions are true, follow the simple cross-origin
request algorithm:
- The request method is a simple method and the force preflight flag is
unset.
- Each of the author request headers is a simple header or author request
On Thu, Feb 5, 2015 at 12:59 PM, Anne van Kesteren ann...@annevk.nl wrote:
That is not sufficient to allow custom headers. Cross-origin (and
WebSocket is nearly always cross-origin I think) custom headers
require a preflight and opt-in on a per-header basis.
Access-Control-Allow-Headers is
Hi
I'd like to propose a new feature to enable browsers to send custom headers
through the API.
The Websocket spec supports this, however the API does not expose this feature.
We're trying to integrate bearer token authentication using the Authorization
header,
this is mainly for single-page
On Thu, Feb 5, 2015 at 12:50 PM, Michiel De Mey
de.mey.mich...@gmail.com wrote:
All it says about CORS is the following
(Opening handshake section):
The |Origin| header field [RFC6454] is used to protect against unauthorized
cross-origin use of a WebSocket server by scripts using the
On Thu, Feb 5, 2015 at 1:22 PM, Anne van Kesteren ann...@annevk.nl wrote:
I'm not sure how this is relevant. We are discussing adding the
ability to the WebSocket API to set custom headers and whether the
current protocol is adequate for that.
CORS is an adequate protocol to allow for
On Thu, Feb 5, 2015 at 1:18 PM, Florian Bösch pya...@gmail.com wrote:
On Thu, Feb 5, 2015 at 12:59 PM, Anne van Kesteren ann...@annevk.nl wrote:
That is not sufficient to allow custom headers. Cross-origin (and
WebSocket is nearly always cross-origin I think) custom headers
require a preflight
On Thu, Feb 5, 2015 at 3:49 AM, Michiel De Mey de.mey.mich...@gmail.com wrote:
I'd like to propose a new feature to enable browsers to send custom headers
through the API.
The Websocket spec supports this, however the API does not expose this
feature.
Does the specification take similar
All it says about CORS is the following
(Opening handshake section):
The |Origin| header field [RFC6454] is used to protect against unauthorized
cross-origin use of a WebSocket server by scripts using the WebSocket API in a
web browser.
On Thu, Feb 5, 2015 at 10:19 AM, Anne van Kesteren
24 matches
Mail list logo
