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

Handling of HTTP-redirects (follow HTTP 3xx redirects) #46

Closed
shmutalov opened this issue Jul 23, 2018 · 5 comments
Closed

Handling of HTTP-redirects (follow HTTP 3xx redirects) #46

shmutalov opened this issue Jul 23, 2018 · 5 comments

Comments

@shmutalov
Copy link

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

@agalakhov
Copy link
Member

agalakhov commented Jul 23, 2018

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.

psmit pushed a commit to psmit/tungstenite-rs that referenced this issue Nov 14, 2019
Update to the newest `tungstenite-rs` version
@bsergean
Copy link

This was filed here too -> #139

@daniel-abramov daniel-abramov changed the title Handling HTTP-redirects Handling of HTTP-redirects (follow HTTP 3xx redirects) Sep 10, 2020
@Redrield
Copy link
Contributor

If this is something that the maintainers would be fine with making a special case for, I can implement it

inikulin added a commit to inikulin/tungstenite-rs that referenced this issue Oct 14, 2020
…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.
inikulin added a commit to inikulin/tungstenite-rs that referenced this issue Oct 14, 2020
…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.
@daniel-abramov
Copy link
Member

I'm a bit indifferent :) But if it does not bring any adverse side effects, then why not?

@agalakhov, what do you think?

@daniel-abramov
Copy link
Member

Fixed by #148

inikulin added a commit to inikulin/tungstenite-rs that referenced this issue Dec 1, 2020
…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.
inikulin added a commit to inikulin/tungstenite-rs that referenced this issue Dec 1, 2020
…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.
inikulin added a commit to inikulin/tungstenite-rs that referenced this issue Dec 1, 2020
…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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants