-
Notifications
You must be signed in to change notification settings - Fork 226
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
Comments
Yes, this has to be done. The only reason for having own types is, the |
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). |
Yes, please! It would be a breaking change, so it requires corresponding version increment. |
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 |
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.
The text was updated successfully, but these errors were encountered: