I wonder if it depends on the way that the server does auth. Perhaps github does it differently than your server.
On thing that’s sort of unusual about github: if you don’t auth with raw.githubusercontent.com, it returns a 404 Not Found rather than a 401 Unauthorized. In the debug logs I can see that gradle is trying to do an HTTP HEAD on the artifact url, where it gets a 404 (which implies that it didn’t send auth info).
Perhaps gradle doesn’t auth until it does an HTTP GET, or it only auths if the server returns 404 Not Found?
As much as I’d like to, this probably isn’t as simple as me diving in and “fixing it”, as there’s some reason this behavior is in Gradle that I don’t have visibility into.
From what I can gather, the best practice is to not send auth info if you don’t have to. I suspect that Gradle (or the http client lib its using) is expecting a 401 challenge-response, and the 404 is throwing it off.
I can see a couple ways of handling this problem:
Turn pre-emptive auth back on (probably not happening)
Have gradle consider a 404 equivalent to a 401. ie, if it gets a 404, it will retry the GET/HEAD with an auth
Add a flag to the gradle dsl to turn pre-emptive auth on, something like this:
Did something change with this in Gradle 2? While this was working with 1.12 when I try to run a build where it will need to fetch a resource from GH in this way the build fails instead. I didn’t notice anything in the release notes and there aren’t any additional comments on the linked ticket.
Can we please get some movement on this? I can’t simply go in and unilaterally change this behavior-- gradle removed it for some reason and the devs need to discuss the options.
i also prefer option 3, because i´m using jenkins with maven repository plugin. if jenkins is secured and auth is not send, it returns 403 (forbidden). so not to forget or add each status code the flag “preemptive” is the best solution and please add it to one of the next versions!
I’m working on a gradle plugin to allow users to easily use a git repo as a maven repository, but I need this fixed in order for it to work. I’ll start diving into the source when I can to look into it, but it maybe a little while before I have time.
The pull request is just waiting to be reviewed by a member of the gradle team (has been for almost a month). I’m using it personally with a custom build, but someone from Gradleware has to approve it before it makes it into the main project.
So does this work with gradle 2.x and private repos? We cannot access our private repo with Gradle 2.x using https://:@ … format or by using the credentials {} within the repo definition. We would like to upgrade gradle (and our ide’s) but we cannot atm.
Hey Marcus, I have, though I don’t use anything in AS to call uploadArchives, that happens from the command line. That being said, all AS is doing is calling the same Gradle as the command line, so it should work from the Gradle pane on the right.