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
wrote:
> Standardizing the approach would defi
* Anne van Kesteren wrote:
>On Thu, Feb 5, 2015 at 2:48 PM, Bjoern Hoehrmann 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 limite
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 wrote:
On Thu, Feb 5, 2015 at 2:48 PM, Bjoern Hoehrmann wr
On Thu, Feb 5, 2015 at 10:57 PM, Anne van Kesteren wrote:
> On Thu, Feb 5, 2015 at 2:48 PM, Bjoern Hoehrmann
> 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
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 reques
On Thu, Feb 5, 2015 at 2:48 PM, Bjoern Hoehrmann 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 HTTP, no? Anyway, pe
On Thu, Feb 5, 2015 at 2:44 PM, Takeshi Yoshino 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 idempotent reque
* Anne van Kesteren wrote:
>On Thu, Feb 5, 2015 at 2:29 PM, Bjoern Hoehrmann 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 speci
On Thu, Feb 5, 2015 at 10:41 PM, Florian Bösch wrote:
> On Thu, Feb 5, 2015 at 2:39 PM, Takeshi Yoshino
> 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 preflig
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 o
On Thu, Feb 5, 2015 at 2:39 PM, Takeshi Yoshino 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
> server that don't
On Thu, Feb 5, 2015 at 2:39 PM, Florian Bösch wrote:
> On Thu, Feb 5, 2015 at 2:35 PM, Anne van Kesteren 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, th
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
specifi
On Thu, Feb 5, 2015 at 2:35 PM, Anne van Kesteren 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 one work with th
On Thu, Feb 5, 2015 at 2:29 PM, Bjoern Hoehrmann 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-
> stead. I do not
On Thu, Feb 5, 2015 at 2:29 PM, Bjoern Hoehrmann wrote:
> It seems to me that "pre-flight" requests would happen prior to opening
>
Pre-flight request will not be made for GET, HEAD and OPTIONS as is
customary for idempotent requests and as is specified by CORS.
* Anne van Kesteren wrote:
>On Thu, Feb 5, 2015 at 1:27 PM, Florian Bösch 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
On Thu, Feb 5, 2015 at 2:23 PM, Florian Bösch wrote:
> 2) Clients do not apply CORS to WebSocket requests, and you're screwed,
> because any change you make will break existing deployments.
We can roll out a revision to the protocol that supports some kind of
CORS-like prefetching mechanism to op
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 dep
On Thu, Feb 5, 2015 at 1:27 PM, Florian Bösch 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
> requests as
On Thu, Feb 5, 2015 at 1:22 PM, Anne van Kesteren 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 additional headers
On Thu, Feb 5, 2015 at 1:18 PM, Florian Bösch wrote:
> On Thu, Feb 5, 2015 at 12:59 PM, Anne van Kesteren 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-heade
On Thu, Feb 5, 2015 at 12:59 PM, Anne van Kesteren 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 not a preflight
On Thu, Feb 5, 2015 at 12:50 PM, Michiel De Mey
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 WebSocket API in
> a web bro
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
wrot
On Thu, Feb 5, 2015 at 3:49 AM, Michiel De Mey 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 precautions to CORS?
-
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 ap
27 matches
Mail list logo
