You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a service erroneously send a redirect from an SSL URL to a non-SSL URL, there is a high possibility that secure data (such as passwords) get sent over plaintext without the application's knowledge. There should be an option to prevent such redirects and I am in favor of preventing such redirects by default, though it may break some existing client code.
Hey @haridsv, just to be clear, Requests strips all body information and Authorization headers on redirect. We're pretty aggressive about this, so data shouldn't be resent on redirect regardless of SSL downgrading.
As for how we handle redirects to non-SSL URIs, I'm not sure we have a better option. There are some legitimate cases where services are now hosted on SSL secured servers, but need to redirect to older content that's still served in plaintext. We definitely don't want to raise an exception because that would break this behaviour.
Implementing a kwarg to do this could be possible, but we're under a feature freeze, so I'm not sure we'd add this option in the near future. It does seem like it could be useful to allow the user to require SSL only for connections, but that may belong in an extension. @sigmavirus24 do you have any thoughts here?
Implementing a kwarg to do this could be possible, but we're under a feature freeze, so I'm not sure we'd add this option in the near future.
Correct. We're not going to add this and it's unlikely we'd even add it in 3.0.
It does seem like it could be useful to allow the user to require SSL only for connections, but that may belong in an extension.
In reality, I think we could provide, in requests-toolbelt, a session that doesn't follow redirects from https to http urls. It should be easy to extend our redirect handling there.
In reality, I think we could provide, in requests-toolbelt, a session that doesn't follow redirects from https to http urls. It should be easy to extend our redirect handling there.
That probably would be fine, though I am not sure what the usage would look like.
When a service erroneously send a redirect from an SSL URL to a non-SSL URL, there is a high possibility that secure data (such as passwords) get sent over plaintext without the application's knowledge. There should be an option to prevent such redirects and I am in favor of preventing such redirects by default, though it may break some existing client code.
Expected Result
Exception raised for
requests.exceptions.SSLError
Actual Result
Redirection is automatically followed
Reproduction Steps
System Information
The text was updated successfully, but these errors were encountered: