Re: Allow custom headers (Websocket API)
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 definitely help developers, > however where will we communicate this? >
Re: Allow custom headers (Websocket API)
* 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 limited >subset of HTTP, no? Anyway, perhaps a combination of a CORS preflight >followed by the HTTP Upgrade that then includes the headers is the >answer, would probably be best to ask some WebSocket library >developers what they think. I think that is the most obvious solution, yes. And no, I do not think you can support less HTTP for Websockets than what you need for minimal web servers (but a minimal web server does not do much beyond message parsing, you also do not need much more to support Websockets); either way, this should not be a problem because you can already reference any Websocket endpoint with and XMLHttpRequest and whatever else, so it's unlikely there are notable risks there. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de Available for hire in Berlin (early 2015) · http://www.websitedev.de/
Re: Allow custom headers (Websocket API)
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 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, perhaps a combination of a CORS preflight followed by the HTTP Upgrade that then includes the headers is the answer, would probably be best to ask some WebSocket library developers what they think. Agreed. Even if we don't make any change on the existing specs, we need to standardize (or just announce to developers) that they need to make servers understand that combination if they want to develop apps that uses custom headers. Then, client vendors could implement that.
Re: Allow custom headers (Websocket API)
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 get away with supporting a very limited > subset of HTTP, no? Anyway, perhaps a combination of a CORS preflight > followed by the HTTP Upgrade that then includes the headers is the > answer, would probably be best to ask some WebSocket library > developers what they think. > Agreed. Even if we don't make any change on the existing specs, we need to standardize (or just announce to developers) that they need to make servers understand that combination if they want to develop apps that uses custom headers. Then, client vendors could implement that.
Re: Allow custom headers (Websocket API)
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 headers is empty. > 3. Otherwise, follow the cross-origin request with preflight algorithm. https://fetch.spec.whatwg.org/#dfnReturnLink-7 > request's unsafe request flag is set and either request's method is not a simple method or a header in request's header list is not a simple header > Set request's response tainting to CORS. > The result of performing an HTTP fetch using request with the CORS flag and CORS preflight flag set. Authorization header is not a simple header. On Thu, Feb 5, 2015 at 10:48 PM, Florian Bösch wrote: > 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 requests (for instance > or XHR GET) across domains without a preflight request. It will > however not make the data available to the client (javascript specifically) > That's the tainting part. > unless CORS is satisfied (XHR GET will error out, and will throw a > glError on gl.texImage2D if CORS isn't satisfied). >
Re: Allow custom headers (Websocket API)
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, perhaps a combination of a CORS preflight followed by the HTTP Upgrade that then includes the headers is the answer, would probably be best to ask some WebSocket library developers what they think. -- https://annevankesteren.nl/
Re: Allow custom headers (Websocket API)
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 requests (for instance or XHR GET) across domains without a preflight request. It will however not make the data available to the client (javascript specifically) unless CORS is satisfied (XHR GET will error out, and will throw a glError on gl.texImage2D if CORS isn't satisfied).
Re: Allow custom headers (Websocket API)
* 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 specification in- >> stead. I do not really see why the Websocket on-the-wire protocol would >> have to be changed here. > >Wouldn't that require the endpoint to support two protocols? That >sounds suboptimal. A Websocket connection is established by making a HTTP Upgrade request, and the protocol is HTTP unless and until the connection is upgraded. Websocket endpoints already have to be robust against XHR pre-flight requests and other HTTP requests and "custom headers" would be an opt- in feature anyway, so it's not obvious that there would be any problem. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de Available for hire in Berlin (early 2015) · http://www.websitedev.de/
Re: Allow custom headers (Websocket API)
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 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 >> specified, >> > No further specification is needed because CORS already covers the case of > endpoints that do not understand CORS (deny by default). Hence above > assertion is superfluous. > 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. > > >> So, anyway, I think we need to make some change on the WebSocket spec. >> > Also bogus assertion. >
Re: Allow custom headers (Websocket API)
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 other miscalnea of HTTP beyond the handshake protocol (which is tacked onto HTTP). CORS is also tacked onto HTTP, and so if you enforce CORS on http, this will automatically apply to the handshake of a websocket, which goes over HTTP. And so still no change is required to the websocket protocol. On Thu, Feb 5, 2015 at 2:41 PM, Anne van Kesteren wrote: > 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, there is no change required to either to make one work with > the > > other, and both adequately deal with non-implementation by the endpoint. > A > > webserver with support for CORS and Websockets already implements both > > protocols, and so no additional burden is imposed regardless. > > The protocols in question are HTTP and WebSocket... CORS is very much > unrelated to most of this. It's just the solution we have for HTTP at > the moment and WebSocket has something similar, just not for headers > and that is the problem. > > > -- > https://annevankesteren.nl/ >
Re: Allow custom headers (Websocket API)
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 understand CORS. We could do e.g. when a custom header is > specified, > No further specification is needed because CORS already covers the case of endpoints that do not understand CORS (deny by default). Hence above assertion is superfluous. > So, anyway, I think we need to make some change on the WebSocket spec. > Also bogus assertion.
Re: Allow custom headers (Websocket API)
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, there is no change required to either to make one work with the > other, and both adequately deal with non-implementation by the endpoint. A > webserver with support for CORS and Websockets already implements both > protocols, and so no additional burden is imposed regardless. The protocols in question are HTTP and WebSocket... CORS is very much unrelated to most of this. It's just the solution we have for HTTP at the moment and WebSocket has something similar, just not for headers and that is the problem. -- https://annevankesteren.nl/
Re: Allow custom headers (Websocket API)
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 specified, (a) the client issues a CORS preflight to verify that the server does understand CORS and it is willing to accept the request. (b) the client issues a WebSocket preflight to verify that the server is a WebSocket server. (a) may work, needs change on the WebSocket spec to ask WebSocket servers to understand CORS preflight. It's not required for now. (b) may be implemented by issuing an extra WebSocket handshake without the custom headers but with Sec-WebSocket-Key, etc. just for checking that the server is WebSocket server, but this may be not no-op to the server. So, I think we should specify something new that is specified to be no-op. So, anyway, I think we need to make some change on the WebSocket spec. Takeshi On Thu, Feb 5, 2015 at 10:23 PM, Florian Bösch wrote: > 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 deployments. > > Either way, this will result in no change made, so you can burry it right > here. > > On Thu, Feb 5, 2015 at 2:12 PM, 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 CORS on >> websocket >> > requests as well). >> >> I think you're missing something. A WebSocket request is subject to >> the WebSocket protocol, which does not take the same precautions as >> the Fetch protocol does used elsewhere in the platform. And therefore >> we cannot provide this feature until the WebSocket protocol is fixed >> to take the same precautions. >> >> >> -- >> https://annevankesteren.nl/ >> > >
Re: Allow custom headers (Websocket API)
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 the other, and both adequately deal with non-implementation by the endpoint. A webserver with support for CORS and Websockets already implements both protocols, and so no additional burden is imposed regardless.
Re: Allow custom headers (Websocket API)
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 really see why the Websocket on-the-wire protocol would > have to be changed here. Wouldn't that require the endpoint to support two protocols? That sounds suboptimal. -- https://annevankesteren.nl/
Re: Allow custom headers (Websocket API)
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.
Re: Allow custom headers (Websocket API)
* 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 CORS on websocket >> requests as well). > >I think you're missing something. A WebSocket request is subject to >the WebSocket protocol, which does not take the same precautions as >the Fetch protocol does used elsewhere in the platform. And therefore >we cannot provide this feature until the WebSocket protocol is fixed >to take the same precautions. 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 really see why the Websocket on-the-wire protocol would have to be changed here. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de Available for hire in Berlin (early 2015) · http://www.websitedev.de/
Re: Allow custom headers (Websocket API)
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 opt into custom headers just fine I think. Just requires some set of people to do the work. -- https://annevankesteren.nl/
Re: Allow custom headers (Websocket API)
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 deployments. Either way, this will result in no change made, so you can burry it right here. On Thu, Feb 5, 2015 at 2:12 PM, 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 CORS on > websocket > > requests as well). > > I think you're missing something. A WebSocket request is subject to > the WebSocket protocol, which does not take the same precautions as > the Fetch protocol does used elsewhere in the platform. And therefore > we cannot provide this feature until the WebSocket protocol is fixed > to take the same precautions. > > > -- > https://annevankesteren.nl/ >
Re: Allow custom headers (Websocket API)
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 well). I think you're missing something. A WebSocket request is subject to the WebSocket protocol, which does not take the same precautions as the Fetch protocol does used elsewhere in the platform. And therefore we cannot provide this feature until the WebSocket protocol is fixed to take the same precautions. -- https://annevankesteren.nl/
Re: Allow custom headers (Websocket API)
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, 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 well).
Re: Allow custom headers (Websocket API)
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-header basis. > > Access-Control-Allow-Headers is not a preflight request per header, it's one > preflight request for all custom headers. I was saying you need to opt in on a per-header basis. I did not say each requires a distinct preflight. > CORS allows idempotent requests to be made without a preflight request. A > websocket setup is a GET request with the necessary headers for the > handshake set. > > Please don't break websockets and HTTP as they're specified and implemented > today. Thank you. 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. -- https://annevankesteren.nl/
Re: Allow custom headers (Websocket API)
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 request per header, it's one preflight request for all custom headers. CORS allows idempotent requests to be made without a preflight request. A websocket setup is a GET request with the necessary headers for the handshake set. Please don't break websockets and HTTP as they're specified and implemented today. Thank you.
Re: Allow custom headers (Websocket API)
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 browser. 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. Sounds like the extra bits of the protocol were not designed with the requirements of the web in mind. -- https://annevankesteren.nl/
Re: Allow custom headers (Websocket API)
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 wrote: > 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? > -- > https://annevankesteren.nl/
Re: Allow custom headers (Websocket API)
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? -- https://annevankesteren.nl/
