[BUG]: Download Artifact - Content Stores Differing Content-Types Cause Errors
jack0x539 opened this issue · comments
What happened?
Afternoon!
When calling ActionsArtifactClient.DownloadArtifact
, the download is often, or always, redirected to another server that holds the actual artifact.
In my experience, if the artifact happens to sit on https://pipelinesghubeus10.actions.githubusercontent.com, then the Content-Type
returned is application/zip
and all is well, but if the artifact happens to reside on https://productionresultssa10.blob.core.windows.net, then the Content-Type
is zip
and it all starts to go wrong.
There's a check in HttpClientAdapter.BuildResponse
for the content type, which fails, then the response is read as a string, not a stream, and Connection.GetRawStream
attempts to cast the string as a stream, understandably gets null, and returns null to the caller.
Easy to fix badly; perhaps harder to fix well.
Versions
Octokit 10.0.0
Relevant log output
No response
Code of Conduct
- I agree to follow this project's Code of Conduct
I think this is happening to me as I'm getting a null stream back sometimes.
Is that not an issue with blob storage though? zip
isn't a valid MIME type is it?
I think this is happening to me as I'm getting a null stream back sometimes.
Is that not an issue with blob storage though?
zip
isn't a valid MIME type is it?
I agree, it's not a valid MIME type, but I'm assuming that those storage servers are way out of the remit of this repository, so there's not a lot that can be done about it from that side.
On this side, however, we could relax the restriction on MIMEs, or we could add a special case for zip
, allowing it to be treated as if it was application/zip
?
I think this is happening to me as I'm getting a null stream back sometimes.
Is that not an issue with blob storage though?zip
isn't a valid MIME type is it?I agree, it's not a valid MIME type, but I'm assuming that those storage servers are way out of the remit of this repository, so there's not a lot that can be done about it from that side.
On this side, however, we could relax the restriction on MIMEs, or we could add a special case for
zip
, allowing it to be treated as if it wasapplication/zip
?
Yeah agreed. Adding zip would be easy, I don't see any downside to it. Currently my pipelines are broken because of this issue.
But it's up to the maintainers. Hoping resolution doesn't take ages.
I'm guessing because it's not a "Standard" format that it doesn't parse it
Oh have you - I've just raised a PR too! Didn't know you were working on it