Http.jl

[EricForgy]

Extending #87 with tests passing.

[hustf]

For the development branch, I suggest we merge the PRs very quickly, then review the branch as a whole since there will probably be some to and fro. This one has some conflicts that you will probably want to resolve first.

I have three questions after just skimming parts of the code. They are not well thought out, but it may be better to put them to you now to avoid possible double work.

1. Will users be able to open websockets without performing the handshake? A tempting workflow might be to use websockets for internal communcation between processes. In deed that will be useful. But if someone does that, they are also open to attacks from, well, anywhere in some cases, something we probably don't want to encourage.

2. Can we write using AbstractStrings? That includes substrings. Which can save time by not copying whole blocks of memory. Since Javascript loves strings, a lot of the traffic on websockets will be strings, and the websockets are bound to become the bottleneck in any such application. Examples ought to include the best practice.

3. Can we treat strings differently than arrays? Strings don't change while occupying the same memory block (not sure if that applies to AbstractStrings), while arrays can be changed by other processes.

You will only see this tomorrow, of course, but happy Valentines to you and your wife!

[EricForgy]

1. Will users be able to open websockets without performing the handshake? A tempting workflow might be to use websockets for internal communcation between processes. In deed that will be useful. But if someone does that, they are also open to attacks from, well, anywhere in some cases, something we probably don't want to encourage.

No. We should strive to be 100% compliant with the IETF specs.

https://tools.ietf.org/html/rfc6455

A WebSocket package must always check for a handshake.

I suspect you might be thinking of the masks. A WebSocket client must always mask the payload when communicating with a server. This is for security reasons I don't fully understand (I'm still new too, but have spent a good chunk of time with the IETF spec recently).

HOWEVER, a WebSocket server must NOT mask the payload. The original WebSockets would throw an error if the frame used a mask, but that means you could not use the package as a client. I've taken this out so we can use this package as both client and server (even simultaneously). That is also why I added the field server to the WebSocket object. This idea is borrowed from @samoconnor's HTTP.WebSockets.jl.

We should check that a message sent from a server is not masked and a message sent from a client is masked and throw an error otherwise. If this is not currently implemented, it should be and I'll add it.

2. Can we write using AbstractStrings? That includes substrings. Which can save time by not copying whole blocks of memory. Since Javascript loves strings, a lot of the traffic on websockets will be strings, and the websockets are bound to become the bottleneck in any such application. Examples ought to include the best practice.

Sure. That would be no problem. WebSocket frames can represent either text or binary data (but both are just bytes). The original WebSockets.jl had two write methods: one with a String which assumes you want to send text and one with Vector{UInt8} that assumes you want to send binary. We can and should have a write method that can accept a byte array and still send it as text by specifying an opcode. This is possible in HTTP.WebSockets.jl and I could port that functionality here easily enough. WebSockets are all about sending bytes and don't care what the bytes represent. That is up to you.

3. Can we treat strings differently than arrays? Strings don't change while occupying the same memory block (not sure if that applies to AbstractStrings), while arrays can be changed by other processes.

Yes. Sure. We can treat them however you like. Open to suggestions. I feel half-way competent to implement some of this stuff now. My stuff may be in hackish form, but should hopefully clean up nice with help once working (two language problem in action).

You will only see this tomorrow, of course, but happy Valentines to you and your wife!

Ha! Thanks. Was too excited. Had to reply before sleeping 😊 Happy Valentine's Day! 💟

[EricForgy]

Both examples: chat.jl and server.jl are working now 👍

[hustf]

Will you be able to resolve the conflicts? I may be able to give a hand in the weekend.

[hustf]

Regarding my questions and your replies regarding strings. I had a go at something like it already, but my solution was slower than the current in the end. Also, 0.7 will open some new possibilities. So let's leave this speed improvement out for now is what I suggest.