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

Base HTTP-types (request, headers, response, status code, etc) on the ones from the http crate #92

Closed
sdroege opened this issue Nov 19, 2019 · 4 comments · Fixed by #93

Comments

@sdroege
Copy link
Contributor

sdroege commented Nov 19, 2019

Currently tungstenite defines its own types for all of this but internally uses the http crate already. It seems like it would make sense to re-use the types from the http crate instead as that would also allow easier integration with other code.

Doing this might also simplify e.g. #70 and could for example also allow the HTTP part of the WebSocket connection to be handled by another HTTP library with tungstenite only taking care of populating the request, parsing the response and then taking over the upgraded HTTP connection.

@agalakhov
Copy link
Member

Yes, this has to be done. The only reason for having own types is, the http crate did not exist at the time of Tungstenite creation. Now Tungstenite depends on http too and implements conversion between http types and own types in some cases. The plan was to switch to http completely but this did not happen yet.

@sdroege
Copy link
Contributor Author

sdroege commented Nov 19, 2019

Would you accept a PR doing that against master? Not saying that I'll be doing it anytime soon, but I can put it on my list (but if anybody reads this before there's a PR, please feel free to go ahead).

@agalakhov
Copy link
Member

Yes, please! It would be a breaking change, so it requires corresponding version increment.

sdroege added a commit to sdroege/tungstenite-rs that referenced this issue Nov 21, 2019
@sdroege
Copy link
Contributor Author

sdroege commented Nov 22, 2019

I started looking into this but it will probably take a while :) I've moved the headers over, not very beautiful yet but I'm going to clean that up once all the pieces are in place.

As part of this I'd also change a bit how serialization of all these types happens instead of having a big static write! block, for example.

sdroege added a commit to sdroege/tungstenite-rs that referenced this issue Nov 22, 2019
sdroege added a commit to sdroege/tungstenite-rs that referenced this issue Nov 22, 2019
sdroege added a commit to sdroege/tungstenite-rs that referenced this issue Nov 23, 2019
sdroege added a commit to sdroege/tungstenite-rs that referenced this issue Nov 23, 2019
sdroege added a commit to sdroege/tungstenite-rs that referenced this issue Nov 23, 2019
sdroege added a commit to sdroege/tungstenite-rs that referenced this issue Nov 23, 2019
sdroege added a commit to sdroege/tungstenite-rs that referenced this issue Nov 23, 2019
sdroege added a commit to sdroege/tungstenite-rs that referenced this issue Nov 23, 2019
sdroege added a commit to sdroege/tungstenite-rs that referenced this issue Nov 24, 2019
sdroege added a commit to sdroege/tungstenite-rs that referenced this issue Nov 24, 2019
sdroege added a commit to sdroege/tungstenite-rs that referenced this issue Nov 24, 2019
sdroege added a commit to sdroege/tungstenite-rs that referenced this issue Nov 24, 2019
sdroege added a commit to sdroege/tungstenite-rs that referenced this issue Nov 24, 2019
a-miyashita pushed a commit to givery-technology/tungstenite-rs that referenced this issue Jul 20, 2023
a-miyashita pushed a commit to givery-technology/tungstenite-rs that referenced this issue Jul 20, 2023
a-miyashita pushed a commit to givery-technology/tungstenite-rs that referenced this issue Jul 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants