@sstadelman thanks for the info! I am able to see the download request from SPM using Charles Proxy, I can even see the values from my .netrc file in the request but for some reason Github always replies with Status 404: Not Found
@MPLewis I tried the API you mention but unfortunately for me it seems to be downloading a zip of the entire repository (seems to be a similar functionality to the GitHub API described for Download a repository archive (zip)).
I believe the GitHub API for pulling a release asset is described here.
The tricky extra part is the requirement for a specific Accept header in order to receive the binary asset; without the header you only receive a JSON description of the asset details. @ksluder I can confirm that when passing the necessary Accept: application/octet-stream header in the curl request that it works (with ~/.netrc) so everything seems fine on the GitHub front (according to their design at least).
I raised the issue with this extra header requirement here:
@sstadelman I'm not familiar with requirements for GitHub Enterprise; were you adding support for pulling binary assets from the GitHub releases feature? And did it follow the API guidelines set out in the repos docs for "Get a release asset"? I'm just lost on how to indicate to SPM to include the Accept: application/octet-stream header (or if there is a way around this).
If there is no current way around this, would the Swift team consider adding something like a customHeaders: [String: String] = [:] parameter to the Target.binaryTarget method? Or is there a better way to resolve this?
It looks like Xcode 13 fails to add Swift packages that specify a binaryTarget with the URL of a GitHub asset in a private repo (even with a correctly formatted ~/.netrc file with suitable credentials):
Barring implementation of the proper delegate method, URLSession should follow redirects by default, making the response received by SPM the 200 from the redirected address, not the 302 that was initially received. As far as I can tell SPM doesn't implement the redirect delegate. However, this behavior may be different when using swift-corelibs-foundation rather than Apple's. Additionally, handling of auth challenges and credentials is certainly different on the open source version, as I still can't get Alamofire's test suite to pass, so that part of the functionality may just be broken. I don't know how SPM handles auth right now, but it doesn't implement the URLSession delegate to do so.
@tomerd@NeoNacho Any updates on this? I'd be happy to look into opening a PR if we agree on the approach... Is it a matter of adding 302 to the list of valid response codes or should the http client be revised?
PR is absolutely welcome, thank you for offering! as @Jon_Shier points out above this is less about adding 302 to the accepted response codes, and more about making sure SwiftPM use of URLSession is correct - in the sense of configuring URLSession to follow redirects.
Sorry, my point was, looking at the SPM code, SPM does not implement the delegate that would prevent automatic redirect handling, so the 302 -> 200 redirect should be working now, unless there's something I'm missing in SPM's URLSession implementation (it's surprisingly simple). However, I can't rule out issues in the open source version of URLSession or Apple's private fork of SPM.
@tomerd: looking at SPM's code and as @Jon_Shier points out, it seems like SPM's use of URLSession is correct insofar as it should follow redirects. It's my understanding that that's URLSession's default behaviour, is that being overridden somewhere?
@tomerd This is happening on Xcode 13. The issue is that it fails to add Swift packages that specify a binaryTarget with the URL of a GitHub asset in a private repo (even with a correctly formatted ~/.netrc file with suitable credentials). I suspect this could be because
A) the ensuing redirect isn't followed
B) Xcode doesn't read the netrc file