Endpoint that should successfully return a 307 followed by a 200, ends up as a 400 bad request

[RCSandberg]

Background:

I'm calling an endpoint that is successfully returning a 307. The redirect should take me to a url giving me a 200 back. This has been verified with postman and web clients.

How I'm using Chopper:

• I'm making a Get request to the endpoint path.
• The endpoint I'm making my get request to requires me to pass an authorization header, and that works perfectly fine!
• I have no Request nor Response converters.
• I'm not providing a different http client. I'm using default setup by Chopper.

Problem:

Instead of the redirect being followed and granting me a 200 back as postman and web clients does, I'm getting a 400 bad request back. The reason phrase in my case is: "Authentication information is not given in the correct format. Check the value of Authorization header."

Question: The address I should be redirected to does not require an authorization header. Could that impact how this works? Answer: Seems like it.

I don't know if this issue lies in Chopper, or in the http client, or in the integration of the http client from Chopper.

Question: Any hints on what I might do or try? Answer: Seems like the problem originates from HttpClient.

My troubleshooting attempts:

I hooked up a the CurlInterceptor() and HttpLoggingInterceptor() and all seems fine with the initial request.

I set breakpoints following what happens, and it seems like the stream response after: final streamRes = await httpClient.send(await req.toBaseRequest()); in Future<Response<BodyType>> send<BodyType, InnerType>() method in base.dart gives me the 400 Bad Request.

Then I disable followRedirects on the baseRequest, I did this by adding baseRequest.followRedirects = false; in the toHttpRequest() method in request.dart

Then when I run the same get request I properly get the 307 back. I can see the bodyString as well as in the location property of the header in the Response and that the link seems to be completely correct! If I copy paste that into a web browser all is fine.

Question: Is there a correct way of disabling followRedirect? :) I assume there is a smarter/better and built in way to do that...

Troubleshooting update:

In Postman, under Settings, there is the possibility to switch on and off this feature:

Follow Authorization header Retain authorization header when a redirect happens to a different hostname.

That is switched OFF by default and when like so, the redirect works fine as my original claim. However, when I switch it ON then I get the same error message as when using Chopper while following directs.

400Authentication information is not given in the correct format. Check the value of Authorization header.

Question: Is this feature familiar to you, and can this be turned off somehow using Chopper? Answer: Seems like it is not possible by default. Could it perhaps be added as a feature?...

Troubleshooting update 2:

Okey, So I seem to have figured out that there is some special handling for Authorization header. See: https://github.com/dart-lang/sdk/issues/45410

So my main concern now seems to be how I can disable following redirects automatically for just certain requests. Question: Can you guide me there?

After some quick reading, I cannot see an easy way to do that. One way would be to allow to pass a followRedirects parameter as a bool to the Request-object that can do what I did request.dart, then it would be possible to write a RequestInterceptor to alter that bool... Or is there a better way currently implemented?

[JEuler]

Hi! Thank you for this precise investigation. As I understand, Chopper doesn't have any functionality to easily support this (using parameter). Maybe using the interceptor and changing the base request would work, but you will need to check against the request.url in the interceptor.

[techouse]

@RCSandberg as this has been fixed in https://github.com/dart-lang/sdk/issues/45410 is this still an issue?

[RCSandberg]

@techouse, I haven't checked. I hardly remember how I solved it, but I circumvented it somehow. Perhaps by changing how backend redirects our mobile app. I can see if I can refresh my memory and check.