Open SvizelPritula opened 1 month ago
I will be happy to go through the details of the permessage-deflate spec – or rather even fix the bug myself, while some missing window bits support. However, the bug is extremely niche as these extension fields are very rarely used, so I'd prefer to try to get this merged and then do an improvement pull on top of that.
@kazk Would you be willing to relicense your PR under the MIT + Apache dual license as used by this crate?
If not, I believe we can use the code under MIT + Apache anyways, as long as we add a NOTICE
file to the repo that looks a little bit like this:
This crate contains code copied from the headers crate, licensed as follows:
*Insert copy of headers license here.*
Additionaly, we would probably have to add "Copyright (c) 2014-2023 Sean McArthur" to LICENSE-MIT
, which is odd, given that no part of the code in this PR was actually written by Sean McArthur.
In #328, @kazk implemented support for the
permessage-deflate
extention. Implementing this extention required the ability to parse theSec-Websocket-Extentions
header, so @kazk submitted a pull request to theheaders
crate. However, the maintainers of theheaders
crate don't wan't to support this header yet, as they don't wan't to commit to any particular API. As such, they suggested that it should be implemented in this or some other crate, tweaked as necessary and potentially moved into theheaders
crate in the future.This PR reverts the commit that reverted @kazk's commit that added
permessage-deflate
support. It also copies his implementation ofSecWebsocketExtentions
intended for theheaders
crate.The implementation of
SecWebsocketExtentions
relied on some internal utilities of theheaders
crate. I've removed some of those dependencies and re-implemented others. I have also gated the implementation behind the existinghandshake
feature, as well as any code that relies on it, since it relies on theheaders
crate, which in turn relies on many other HTTP crates.Blocking issues
headers
crate is licensed under the MIT license, while this crate uses a dual MIT+Apache license. We would need to add a proper license notice, or @kazk would need to consent to the re-licensing of his PR.Unresolved questions
deflate
feature without havingtungstenite
handle the Websocket handshake. There is aWebSocket::from_raw_socket_with_extensions
method to allow for exactly that, but it takes anExtensions
struct, which has no public constructor.WebSocketConfig::accept_offers
method, which implements the server part of extension negotiation and requires thehandshake
feature. This method is intended to allow fortungstenite
to be integrated into web frameworks. No similar public method exists for clients, although that might not be a big issue, since a client knows whether a request will be a Websocket request up front.WebSocketConfig::accept_offers
feels out of place on theWebSocketConfig
. We could make it a standalone function, perhaps in theextensions
module.SecWebsocketExtentions
implementation public. This is necessary to make theWebSocketConfig::accept_offers
method usable. This does mean that ifSecWebsocketExtentions
were to be added toheaders
in the future, switching to that implementation would (I think) be a breaking change. An alternative would be to haveWebSocketConfig::accept_offers
take and return aHeaderValue
, which it would parse itself. This would allow us to makeSecWebsocketExtentions
a private implementation detail.WebSocketConfig
and a new variant was added to theError
enum. Since this field and variant depends on thedeflate
feature, I've annotated both with#[non_exhaustive]
. I've done the same toProtocolError
, which currently has variants gated behindhandshake
. This sadly means that you cannot createWebSocketConfig
using the initializer syntax, instead you have to create an instance withWebSocketConfig::default
and mutate it afterward. Sadly, I see no way to avoid this. It would be possible to disable#[non_exhaustive]
if all relevant features are enabled.