[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?
zipisn'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?zipisn'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.
Sorry I need to re-open this - The content type is flowing through as null even though it's there:
It's on the headers object:
But then the ContentType property to easily access it returns null:
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