http: on redirect, headers are copied to new request

[fdietze]

On a HTTP 302 redirect, the headers of the original request are copied over to the new request.
AFAIK, copying headers in this case is wrong.

https://github.com/dart-lang/sdk/blob/master/sdk/lib/_http/http_impl.dart#L2493-L2498

This is causing problems in my application. My url works well with curl -L but does not with dart http.

[aam]

Thanks for the report.
What kind of request is being redirected (GET/HEAD/...)?
My understanding is that new request should point to new URL but otherwise be identical to the original one.
Can you provide a little more details as to why you think copying headers is wrong?

[fdietze]

In my case, it's a GET request.

The first http server checks my Authorization header and generates a pre-signed url to download a file from another host. When the Authorization header is also attached to the second request, the second request fails, because two auth mechanisms are provided at the same time.

It works fine with curl and http, but not with the dart http client. I tested it with 303 and 302 HTTP status codes.

$ http -v GET https://myfirsthost/file.mp3 "Authorization:Bearer $TOKEN" --follow
GET /file.mp3 HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
Authorization: Bearer TOKEN
Connection: keep-alive
Host: myfirsthost
User-Agent: HTTPie/2.4.0



HTTP/1.1 303 See Other
Apigw-Requestid: xxxxxxxxxxx
Connection: keep-alive
Content-Length: 0
Date: Mon, 22 Mar 2021 15:43:30 GMT
location: https://mysecondhost/file.mp3?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=[.......]&X-Amz-SignedHeaders=host



GET /file.mp3?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=[......]&X-Amz-SignedHeaders=host HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
Connection: keep-alive
Host: mysecondhost
User-Agent: HTTPie/2.4.0



HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Length: 9088353
Content-Type: audio/mp3
Date: Mon, 22 Mar 2021 15:43:31 GMT
ETag: "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
Last-Modified: Fri, 19 Mar 2021 12:25:30 GMT
Server: AmazonS3
x-amz-id-2: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
x-amz-request-id: xxxxxxxxxxxxxxxx
x-amz-server-side-encryption: aws:kms
x-amz-server-side-encryption-aws-kms-key-id: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx



+-----------------------------------------+
| NOTE: binary data not shown in terminal |
+-----------------------------------------+

[aam]

Aha, thanks for the details. It looks like Authorization header is a special case that is handled differently by different runtimes/languages(for example see https://developers.nest.com/guides/api/how-to-handle-redirects).
Perhaps we should consider stripping it in Dart as well.

Meanwhile, Dart developers have a control over whether redirects are automatically followed via https://api.flutter.dev/flutter/dart-io/HttpClientRequest/followRedirects.html, if redirects are followed manually developer can strip out headers as needed.

[fdietze]

Alright, the special case for 'Authorization' explains it.
Yes, following the redirect manually works if you have control over the http requests. But with libraries that use http internally, like flutter_cache_manager, it becomes a bit more tricky.

[RCSandberg]

Hi, I'd like to follow up on this as well. I seems to have run into the same(?) issue, but with a 307.

Can you confirm whether or not this seems to be the case?

I'm making a GET request to an endpoint that requires Authentication header to be set.
From that endpoint, I get a 307 which should redirect me to a new uri , which should give me a 200.
This has been verified with Postman and works as intended.

The uri I'm getting redirected to does not require an authentication header to be set and is on a new hostname. I have been able to figure out that the issue seems to have to do with that.

There is a setting in Postman (that is found under the Settings tab) that is disabled by default:

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

When I enable that feature in Postman, I get the same problem as I do with HttpClient when running httpClient.send()

[brianquinlan]

Fixed in https://dart-review.googlesource.com/c/sdk/+/229947

[Hixie]

#47246 also seems to be a duplicate of this?

[kevmoo]

Fixed in 57db739