broken? about rust-websocket

[cyderize]

You can use the sha1 from my git repository by using the temp branch of rust-websocket.

In Cargo.toml:

[dependencies.websocket]
git = "https://github.com/cyderize/rust-websocket.git"
branch = "temp"

I opened a pull request a few days ago to the owner of rust-sha1, but they seem to be hard to contact at the moment.

[BenTheElder]

Unfortunately this leaves packages that depend on websocket unable to publish (to crates.io) in the meantime. Perhaps if the PR is not accepted within a reasonable timeline a fork could be published under an alternate name or something? Local/relative path vendorizing unfortunately seems prohibited by cargo for published packages; as well as git dependencies.

[cyderize]

Yeah, not having sha1 working is pretty much why I haven't been able to publish this version to crates.io.

I've decided to use sha1-hasher now, since it works - hopefully that should make it possible to continue using the library. That version is in the sha1-hasher branch and is published as 0.9.6 on crates.io.

[BenTheElder]

Looks like a good solution. When you make the switch I'll finally move slack-rs to 1.0-alpha.

[cyderize]

The crates.io version should now be working, although you might want to wait a while before moving to 1.0-alpha.

I've still got to deal with associated types, and there will likely be some large changes to the API (I might try to mirror the stream splitting from RFC517 rather than having clones are Arcs everywhere).

[BenTheElder]

Ok. I've gone ahead and started updating because there is so much that needs to be changed in my code to reach 1.0, but none of the calls to websocket need updating since the switch to websocket's hyper so far.

[cyderize]

I mean you may also need to change some of the websocket calls eventually as well - but they shouldn't be too major anyway (and I'll happily help out when I finish the changes).

[BenTheElder]

Ok, I'll continue to track crates.io 's latest as much as possible. Thanks.

[BenTheElder]

So i've updated to 0.9.6, and updated my demo project, and while i'm not 100% certain it isn't my fault i'm getting ResponseError("Sec-WebSocket-Accept is invalid") when connecting to slack. I'm going to do some more debugging and report back.

[BenTheElder]

Well disabling the call to check res.validate(&key) after connecting seems to leave everything else functioning as expected, so I'd say there's a bug somewhere between slack and rust-websocket.

[cyderize]

Yes, there seems to be a problem with validation - I neglected a lot of client-side testing, and this doesn't appear to work. I'll have a closer look at it (I've put it in issue #13).

[BenTheElder]

Ok, thanks.

[cyderize]

I think I've fixed the issue in 0.9.7. The WebSocketKey was being written incorrectly.

In actual fact, slack should've completely rejected the connection since the header was invalid, but I suppose it's designed to be a bit more robust.

[BenTheElder]

I've re-enabled validation after switching to 0.9.7 and it seems to be working as expected.

[cyderize]

I've now removed the dependency on a separate SHA-1 crate, since OpenSSL can already do SHA-1 (and much faster than any Rust crates).

Version 0.10.0 introduces a different API, so see the examples in examples/client.rs and examples/server.rs.

I've removed the clone() and Mutex stuff, instead using a split() method to allow sending and receiving from different threads.

If you still need to be able to clone(), you'll have to put the use an Arc<Mutex<Client>>.