Bad request after redirect

[diederikfaber]

Describe the bug

During a CI/CD script (jetbrains space automation) one of the steps in a gradle build is to download a .jar file. The response to the initial GET is a 307 temporary redirect with a new location specified in the Location header of the response. When the redirect is followed, a 400 Bad request is returned and the build obviously fails.

Manually downloading the file from this redirect location works, so the location itself is valid. We're using bearer tokens for authentication and these are also verified correct (and we don't get a 401).

Sample build script

I can't create a build script that fails continuously. Even our gradle build works in different automation configurations, the only difference (as far as I can tell) being the location returned in the redirect (I don't understand why that is, but ok).

I do have an excerpt from a gradle build log with debugging enabled.

I realize this is not a lot to go on, but hopefully this issue rings a bell somewhere.

Build log excerpt

[11:39:34] 2024-02-09T11:39:33.796+0000 [DEBUG] [de.undercouch.gradle.tasks.download.internal.DebugInterceptor] Sending request:
[11:39:34] > GET /my/file/location/blablabla/lib.jar
[11:39:34] > Authorization: Bearer *******
[11:39:34] > Accept-Encoding: gzip, x-gzip, deflate
[11:39:34] 2024-02-09T11:39:33.904+0000 [DEBUG] [de.undercouch.gradle.tasks.download.internal.DebugInterceptor] Received response:
[11:39:34] < HTTP/1.1 307 Temporary Redirect
[11:39:34] < Date: Fri, 09 Feb 2024 11:39:33 GMT
[11:39:34] < Content-Length: 0
[11:39:34] < Connection: keep-alive
[11:39:34] < Vary: Origin
[11:39:34] < X-Frame-Options: DENY
[11:39:34] < Content-Security-Policy: frame-ancestors 'none'
[11:39:34] < Referrer-Policy: no-referrer
[11:39:34] < Location: https://s3.eu-west-1.amazonaws.com/packages-cloud-prod-data.jetbrains.com/a_very_long_url_containing_my_file_location_blablabla_lib.jar?and=a&lot=of&parameters
[11:39:34] 2024-02-09T11:39:33.998+0000 [DEBUG] [de.undercouch.gradle.tasks.download.internal.DebugInterceptor] Sending request:
[11:39:34] > GET /packages-cloud-prod-data.jetbrains.com/a_very_long_url_containing_my_file_location_blablabla_lib.jar?and=a&lot=of&parameters
[11:39:34] > Authorization: Bearer *******
[11:39:34] > Accept-Encoding: gzip, x-gzip, deflate
[11:39:34] 2024-02-09T11:39:34.007+0000 [DEBUG] [de.undercouch.gradle.tasks.download.internal.DebugInterceptor] Received response:
[11:39:34] < HTTP/1.1 400 Bad Request
[11:39:34] < x-amz-request-id: SZKT6JP65FXKRD33
[11:39:34] < x-amz-id-2: oTW1eHp4rBUsX6tt9chuCsEXAV8RV2rj+r56uBYWk6L35+/jfiZCRQiIgDPuBBRn1CdOVVL7q7I=
[11:39:34] < Content-Type: application/xml
[11:39:34] < Transfer-Encoding: chunked
[11:39:34] < Date: Fri, 09 Feb 2024 11:39:33 GMT
[11:39:34] < Server: AmazonS3
[11:39:34] < Connection: close

[michel-kraemer]

Thanks for the debug log. I assume you're using the latest version of gradle-download-task?

[diederikfaber]

Yes, 5.5.0
Thank you for your quick reaction

[michel-kraemer]

I've just published a snapshot version 5.6.0-SNAPSHOT. It adds a new property validateStatus, which can be used to allow certain HTTP status codes. In your case, you can use it to download the body of the error response you're getting from your server. Just add the following line to your task configuration:

validateStatus { it == 400 }

Here's a complete example:

tasks.register<Download>("downloadFile") {
    src("https://example.com/404")
    dest(layout.buildDirectory)
    overwrite(true)
    validateStatus { it < 500 }
}

After this, your destination file should contain the server error message. This might help us to identify the root cause. Let me know what you get. Thanks!

In order to use the snapshot, you have to add the following block to your settings.gradle file:

pluginManagement {
    repositories {
        maven {
            url "https://oss.sonatype.org/content/groups/public"
        }
        gradlePluginPortal()
    }
}

[diederikfaber]

Hi Michel,

Your snapshot worked perfectly, this is the response I got:

<?xml version="1.0" encoding="UTF-8"?>
<Error><Code>InvalidArgument</Code><Message>Only one auth mechanism allowed; only the X-Amz-Algorithm query parameter, Signature query string parameter or the Authorization header should be specified</Message><ArgumentName>Authorization</ArgumentName><ArgumentValue>Bearer *****</ArgumentValue><RequestId>1P2J4GTTPB8V9VVE</RequestId><HostId>GHY43plCmoKjd+7Avies81s8lQ95HfnWm61AMMqriCnhf/6ZTva2jEUhiPTLiEIi0WCEGbSUmPM=</HostId></Error>

Is this something you can work with?

Thank you for your effort.

Best regards,
Diederik Faber

[michel-kraemer]

Perhaps the request has to be signed:
https://docs.aws.amazon.com/AmazonS3/latest/userguide/RESTAuthentication.html

You can define your own headers with the header property.

[diederikfaber]

We're already providing authentication using the header property. The error says that only one authentication mechanism is allowed, but the second mechanism is added somewhere in the redirect. So that is out of my hands. If I leave out my own authentication header, then the first request is immediately denied and the redirect does not occur at all.

I've asked for support from jetbrains on this as well. I guess I have to wait for their feedback.
Your support so far is very much appreciated.

[dtretyakov]

@michel-kraemer I suspect that the issue is following when HTTP Client sends a request to the host1 which redirects to s3buckethost with presigned URL gradle download task preserves Authorization header from the initial request and sends it to the s3buckethost.

See the related issues in ktorio/ktor#1467

[michel-kraemer]

@dtretyakov Thanks for the pointer. I had the same thought. If that's the case then it might be an issue with Apache's HttpClient. I will try to figure out if there is a workaround or if the authentication headers can be reset after the redirect (just like it says in the Ktor thread).

[michel-kraemer]

I've asked for support from jetbrains on this as well. I guess I have to wait for their feedback.

@diederikfaber Sounds good. It'd be great if you could keep me posted.

[eghobo]

@michel-kraemer we have a similar problem with https://api.bitbucket.org/ and Repository Access Tokens, when we pass header 'Authorization: Bearer <repository_access_token> . Bitbucket redirects download requests to AWS S3, which doesn't accept this Authorization header.

[michel-kraemer]

Thanks a lot, @eghobo! That's valuable information. I was able to reproduce the issue.

It seems other HTTP client such as xh strip sensitive headers on redirect (https://github.com/ducaale/xh/blob/master/src/redirect.rs#L95-L101) but Apache HttpClient does not. If I understand HttpClient's source code correctly, it copies the original request on redirect, including all headers! It does clear the authentication cache indeed, but since you're sending the header directly, it's not in said cache and thus won't get cleared.

Now I need to figure out, if there is a way to remove sensitive headers on redirect like xh does, or if I need to implement a custom authentication scheme so the default mechanisms of HttpClient take effect. The issue with the latter is that BitBucket, for example, sends a 404 if the request is not pre-authenticated. A custom authentication scheme would require a 401 and some kind of WWW-Authenticate header in the server's response. However, maybe I can force pre-authentication if an Authorization header is provided in the request. I need to test this.

The good news is: now that I'm able to reproduce the issue, I can fix it. Just give me a day or two. I will get back to you as soon as possible.

[michel-kraemer]

I think I've fixed the issue. It would be great if someone could confirm that. I've uploaded a new snapshot 5.6.0-SNAPSHOT (see instructions above). You may have to call gradle with --refresh-dependencies to download the latest version of the snapshot.

After the fix has been confirmed, I can publish the new version.

Thank you so much for your help!!