I'm using the maven-deploy-plugin 2.6, which I think comes from jenkins parent. That in turn uses maven-wagon, which uses http client 4, an up to date and common HTTP library in java.
> [...] which means that an HTTP client should be sending all request headers and authentication credentials to the Location header in the response (
>Some versions of Maven have broken HTTP client implementations and therefore are not respecting 3xx response codes
I do not believe this is correct, and the client behavior is not defective. The http spec is mum about what to do when a PUT gets a 302:
The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD.
It appears that httpclient does an automatic retry on PUT, and it looks like it does not carry over the Authorization header. It looks like curl does this as well (by default). I will have to look into httpclient but I imagine this is for security reasons - you do not want to accidentally send your Authorization header to an entirely different server.
Here's a discussion on the ietf mailing list:
The HTML living standard also addresses this:
It's a bit hard to read, I interpret it to mean that it will only send credential header if CORS is enabled - for security reasons, presumably. There's some discussion on Go's http client on the problem of replaying headers in general:
Given all of this, I think that the root problem might be in using redirect itself - it does not work with the scaffolding which Jenkins ships with, and I can't see evidence that this is a behavior any HTTP client would do, and which several (apache httpclient, go's http client, html standard, curl) do not.