Use upstream websocket crate.

[illegalprime]

Recently I've finished another release of the websocket crate, so there's lots of neat stuff to use. I wanted to see how other projects used this library, and I thought this would be a great place to check.

I have some questions on the implementation here that will inform the future design of the websocket crate:

1. Why is SSL disabled? The only thing I see stopping the use of SSL here is that you are creating a separate receiver and sender for the same connection (and an SSL stream can't be split up like that).
2. Why split up the stream into a read and writer and not wrap it in a Mutex<> or something?
3. It seems like all the fetch functions just check and set headers, is it worth keeping the structure or just building a list of headers and setting them in the client builder?

NOTE: this is not ready to be merged, there are some .unwrap() calls and it doesn't set any of the important headers listed later in the file.

ANOTHER NOTE: this websockets release is going to go through some more testing before being published, and is also blocked by hyperium/hyper#1107 being included in a hyper version.

Thanks!

---

• ./mach build -d does not report any errors
• ./mach test-tidy does not report any errors
• These changes fix #__ (github issue number if applicable).

• There are tests for these changes OR
• These changes do not require tests because _____

---

This change is 

[highfive]

Thanks for the pull request, and welcome! The Servo team is excited to review your changes, and you should hear from @asajeffrey (or someone else) soon.

[highfive]

Heads up! This PR modifies the following files:

• @KiChjang: components/net/Cargo.toml, components/net/websocket_loader.rs

[highfive]

Warning

• These commits modify net code, but no tests are modified. Please consider adding a test!

[SimonSapin]

CC @avadacatavra, @nox

[nox]

Why is SSL disabled? The only thing I see stopping the use of SSL here is that you are creating a separate receiver and sender for the same connection (and an SSL stream can't be split up like that).

That's exactly why, websocket isn't working with latest openssl.

Why split up the stream into a read and writer and not wrap it in a Mutex<> or something?

Because in the current setup, we block on reading in a thread, and we write on a different thread, so the Mutex<> would just deadlock, especially with openssl renegotiations which may require the writer end to need to read.

It seems like all the fetch functions just check and set headers, is it worth keeping the structure or just building a list of headers and setting them in the client builder?

No, we only do a subset of what the websocket RFC allows, so it's better to do the handshake ourselves, especially because I want to merge that code back with fetch::methods in the future.

[nox]

Note that I actually tried to update to last websocket before just disabling WSS, I ended up with mio errors.

[illegalprime]

@nox so as I understand it you would like to see:

1. updated openssl dependency (which is there already)
2. ability to skip the handshake process that comes with the crate (also exists, servo code already uses it)
3. a way to listen to events from channels and messages from the library at the same time

As far as I know no. 3 doesn't have a good answer yet, since select!() seems like its going away. Is it worth to change these channels to a mio or a tokio channel if the websocket crate gains support for (mio/tokio)?

[nox]

As far as I know no. 3 doesn't have a good answer yet, since select!() seems like its going away. Is it worth to change these channels to a mio or a tokio channel if the websocket crate gains support for (mio/tokio)?

Yep!

[nox]

@illegalprime I forgot to say it earlier, but thanks for looking at this btw!

[illegalprime]

I've merged tokio support for websockets, which I'm excited about. I'll be able to get to this soon. The changes in the crate also allow support for SSL in async mode.

[jdm]

Closing due to inactivity.