Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make WebSocket point to Fetch #180

Closed
annevk opened this Issue Sep 22, 2015 · 7 comments

Comments

3 participants
@annevk
Copy link
Member

annevk commented Sep 22, 2015

It seems upgrade-insecure-requests applies to WebSocket too. We should probably start thinking about some shared infrastructure between Fetch and WebSocket.

Credit: Christoph Kerschbaumer.

@annevk

This comment has been minimized.

Copy link
Member Author

annevk commented Sep 22, 2015

We should look into making WebSocket run over Fetch until the "upgrade" happens. That would ensure we don't keep running into this mess.

@annevk

This comment has been minimized.

Copy link
Member Author

annevk commented Sep 25, 2015

Making WebSocket run over Fetch is a non-starter unless we fork the whole protocol back in. (It does seem that this might be needed at some point, e.g., presumably rel=preconnect also works for WebSocket.)

So I guess maybe for now we should continue to duplicate requirements.

It seems @mikewest has already done so in https://w3c.github.io/webappsec/specs/upgrade/#websockets-integration. So maybe we should turn that into a monkey patch for HTML instead.

@annevk

This comment has been minimized.

Copy link
Member Author

annevk commented Sep 25, 2015

So seeing https://www.w3.org/Bugs/Public/show_bug.cgi?id=28841 it seems @mikewest wants to make this work in a different fashion. To stop throwing early errors and instead make it a network error of sorts. That makes sense if we ever want to migrate the connection algorithm to Fetch.

However, the IETF folks are not interested in updating the RFC. So either we keep various monkey patches around or perhaps merge these just before the step that establishes the connection. The latter seems better since e.g., HSTS is not otherwise covered.

@mikewest

This comment has been minimized.

Copy link
Member

mikewest commented Sep 25, 2015

I filed errata against the Web Sockets RFC for MIX, which I am assured means that it'll totally get taken care of whenever they update the spec: http://www.rfc-editor.org/errata_search.php?rfc=6455&eid=4398. I doubt that's going to happen anytime soon.

@annevk

This comment has been minimized.

Copy link
Member Author

annevk commented Sep 26, 2015

So when I asked about HSTS and things like cookies they didn't really seem to care much.

@annevk

This comment has been minimized.

Copy link
Member Author

annevk commented Sep 26, 2015

We could also just take over the entire "establish a connection" algorithm since I think most browsers just use Fetch...

@annevk annevk changed the title WebSocket: upgrade-insecure-requests Make WebSocket point to Fetch Mar 5, 2016

@annevk

This comment has been minimized.

Copy link
Member Author

annevk commented Mar 5, 2016

This can be fixed once whatwg/fetch#235 is fixed.

annevk added a commit that referenced this issue Mar 9, 2016

Update WebSocket to use Fetch's WebSocket alterations
This makes the following changes to the WebSocket API:

* Moves Mixed Content, HSTS, and cookie handling to the network layer.
* Makes sure that other things handled by the network layer now also apply to WebSocket, such as
  upgrading of insecure requests.
* Removes the unused "extensions in use" concept.
* Removes the "client-specified protocols" concept since that is entirely handled by the Web Socket
  Protocol specification (and still is with the Fetch alterations).
* Inlines the parsing of URLs since it's a lot less involved now. Also uses the URL parser rather
  than the "parse a URL" construct since there's no base URL.

Fixes #180.

annevk added a commit that referenced this issue Mar 10, 2016

Update WebSocket to use Fetch's WebSocket alterations
This makes the following changes to the WebSocket API:

* Moves Mixed Content, HSTS, and cookie handling to the network layer.
* Makes sure that other things handled by the network layer now also apply to WebSocket, such as
  upgrading of insecure requests.
* Removes the unused "extensions in use" concept.
* Removes the "client-specified protocols" concept since that is entirely handled by the Web Socket
  Protocol specification (and still is with the Fetch alterations).
* Inlines the parsing of URLs since it's a lot less involved now. Also uses the URL parser rather
  than the "parse a URL" construct since there's no base URL.

Fixes #180, https://www.w3.org/Bugs/Public/show_bug.cgi?id=27869, and
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26967.

annevk added a commit that referenced this issue Mar 10, 2016

Update WebSocket to use Fetch's WebSocket alterations
This makes the following changes to the WebSocket API:

* Moves Mixed Content, HSTS, and cookie handling to the network layer.
* Makes sure that other things handled by the network layer now also apply to WebSocket, such as
  upgrading of insecure requests.
* Removes the unused "extensions in use" concept.
* Removes the "client-specified protocols" concept since that is entirely handled by the Web Socket
  Protocol specification (and still is with the Fetch alterations).
* Inlines the parsing of URLs since it's a lot less involved now. Also uses the URL parser rather
  than the "parse a URL" construct since there's no base URL.

Fixes #180, https://www.w3.org/Bugs/Public/show_bug.cgi?id=27869, and
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26967.

annevk added a commit that referenced this issue Mar 10, 2016

Update WebSocket to use Fetch's WebSocket alterations
This makes the following changes to the WebSocket API:

* Moves Mixed Content, HSTS, and cookie handling to the network layer.
* Makes sure that other things handled by the network layer now also apply to WebSocket, such as
  upgrading of insecure requests.
* Removes the unused "extensions in use" concept.
* Removes the "client-specified protocols" concept since that is entirely handled by the Web Socket
  Protocol specification (and still is with the Fetch alterations).
* Inlines the parsing of URLs since it's a lot less involved now. Also uses the URL parser rather
  than the "parse a URL" construct since there's no base URL.

Fixes #180, https://www.w3.org/Bugs/Public/show_bug.cgi?id=27869, and
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26967.

annevk added a commit that referenced this issue Mar 10, 2016

Update WebSocket to use Fetch's WebSocket alterations
This makes the following changes to the WebSocket API:

* Moves Mixed Content, HSTS, and cookie handling to the network layer.
* Makes sure that other things handled by the network layer now also apply to WebSocket, such as
  upgrading of insecure requests.
* Removes the unused "extensions in use" concept.
* Removes the "client-specified protocols" concept since that is entirely handled by the Web Socket
  Protocol specification (and still is with the Fetch alterations).
* Inlines the parsing of URLs since it's a lot less involved now. Also uses the URL parser rather
  than the "parse a URL" construct since there's no base URL.

Fixes #180, https://www.w3.org/Bugs/Public/show_bug.cgi?id=27869, and
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26967.

@annevk annevk closed this in #840 Mar 10, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.