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
Handling of HTTP-redirects (follow HTTP 3xx redirects) #46
Comments
Short answer: add an error handler. In case of redirect you get a new address within the error message and just connect again. This probably has to be added as an extra feature. If you can connect with redirect by other means, Tungstenite is able to upgrade an existing connection to websocket one, too. |
Update to the newest `tungstenite-rs` version
This was filed here too -> #139 |
If this is something that the maintainers would be fine with making a special case for, I can implement it |
…rver Following redirects inside the lib (snapview#148) has few flows: there is no redirect loop prevention in this case, in case of using the lib in proxy it's impossible to return the upstream response to browser, etc. With this change response is propagated to the lib's user, so it can decide what to do with it in case of redirects: either send it to browser for it to follow redirects or implement redirect following on their side.
…rver Following redirects inside the lib (snapview#148) has few flows: there is no redirect loop prevention in this case, in case of using the lib in proxy it's impossible to return the upstream response to browser, etc. With this change response is propagated to the lib's user, so it can decide what to do with it in case of redirects: either send it to browser for it to follow redirects or implement redirect following on their side.
I'm a bit indifferent :) But if it does not bring any adverse side effects, then why not? @agalakhov, what do you think? |
Fixed by #148 |
…rver Following redirects inside the lib (snapview#148) has few flows: there is no redirect loop prevention in this case, in case of using the lib in proxy it's impossible to return the upstream response to browser, etc. With this change response is propagated to the lib's user, so it can decide what to do with it in case of redirects: either send it to browser for it to follow redirects or implement redirect following on their side.
…rver Following redirects inside the lib (snapview#148) has few flows: there is no redirect loop prevention in this case, in case of using the lib in proxy it's impossible to return the upstream response to browser, etc. With this change response is propagated to the lib's user, so it can decide what to do with it in case of redirects: either send it to browser for it to follow redirects or implement redirect following on their side.
…rver Following redirects inside the lib (snapview#148) has few flows: there is no redirect loop prevention in this case, in case of using the lib in proxy it's impossible to return the upstream response to browser, etc. With this change response is propagated to the lib's user, so it can decide what to do with it in case of redirects: either send it to browser for it to follow redirects or implement redirect following on their side.
How to handle HTTP redirects? I am trying to connect to gitter API with no success:
https://github.com/shmutalov/gitter-rs/blob/develop-streaming/faye/src/lib.rs#L71
The text was updated successfully, but these errors were encountered: