Handle HTTP<->HTTPS redirects automatically

[google]

Handle HTTP<->HTTPS redirects automatically

[kglowacki]

it does not seem to work when I original request is http and I get 301 to https, probably because of

"HttpURLConnection will follow up to five HTTP redirects. It will follow redirects from one origin server to another. This implementation doesn't follow redirects from HTTPS to HTTP or vice versa."

[jpd236]

Which HTTP stack are you using?

If you're using HurlStack, I think you can just call HttpUrlConnection.setFollowRedirects(true).

If you're using HttpClientStack for some reason, consider not using it, but you would probably still be okay if you customized the AndroidHttpClient being used under the covers to undo the default call to HttpClientParams.setRedirecting(params, false).

For other stacks, I think it feels more natural to me that the HTTP stack handles redirects internally rather than have them bubbled up to the Volley network layer and require that they be accounted for in retry policies. LMK if that doesn't make sense and I can take a closer look.

[jpd236]

Got it - thanks for the pointer.

Interestingly okhttp's stack changes that default behavior (and notes as much):

https://square.github.io/okhttp/3.x/okhttp/okhttp3/OkHttpClient.Builder.html#followSslRedirects-boolean-

So I'm still not 100% sure whether it would make more sense to do this at the HTTP stack layer or at the Volley layer. Either way, though, we should make this possible in some form.

[jpd236]

Having investigated this a bit more carefully, I don't think this is a change I'd be comfortable making to Volley, unfortunately.

Following redirects correctly in all cases is really tricky: have a look at OkHttp's code to do so. I don't think it's wise for Volley to try and imitate this logic; Volley's intent is to provide a light interface on top of network layers which is where this logic belongs.

If HttpUrlConnection supported a flag to enable this behavior, it'd certainly be reasonable to expose an API in HurlStack to access it if needed, but it does not.

So, my suggestions would be to either:

• Avoid encountering this scenario by making requests using the desired post-redirect protocol, be it HTTP or HTTPS, so that redirects don't change protocols
• Use a different HTTP stack implementation with Volley that supports this innately. There are various OkHttp-backed stacks floating around, for example. (The Apache stack might support them, though I wouldn't recommend this as it's deprecated per the Android platform, and I haven't tested).
• Extend HurlStack in your own app and override executeRequest to implement the redirect handling as desired. As noted above, it's tricky to do this generically, but if you know the backends you are hitting and the redirect scenarios you want to support then you might be able to cover a minimal set of reasonable cases more easily.