Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

error: unable to unpack tarball to temporary directory: TarHeader #19636

Closed
andrewrk opened this issue Apr 12, 2024 · 2 comments
Closed

error: unable to unpack tarball to temporary directory: TarHeader #19636

andrewrk opened this issue Apr 12, 2024 · 2 comments
Labels
downstream An issue with a third party project that uses Zig.

Comments

@andrewrk
Copy link
Member

Zig Version

0.12.0-dev.3644+05d975576

Steps to Reproduce and Observed Behavior

andy@bark> zig fetch https://www.openssl.org/source/openssl-3.3.0.tar.gz
error: unable to unpack tarball to temporary directory: TarHeader

Appears to be a problem with std lib http client, since it works fine when using wget to download the resource.

Expected Behavior

The same result that I get when fetching the package with wget instead of zig:

andy@bark ~/tmp> zig fetch openssl-3.3.0.tar.gz 
1220d9c400445c9c3ed46f71ebdbc364b7b349473231884c2f6e540817d7b68553ae
@andrewrk andrewrk added bug Observed behavior contradicts documented or intended behavior standard library This issue involves writing Zig code for the standard library. zig build system std.Build, the build runner, `zig build` subcommand, package management labels Apr 12, 2024
@andrewrk andrewrk added this to the 0.13.0 milestone Apr 12, 2024
@andrewrk
Copy link
Member Author

andrewrk commented Apr 12, 2024

Looks like the web server is using incorrect HTTP headers. The content-type should be instead application/gzip, application/x-gzip, or application/tar+gzip, or it should use transfer-compression: gzip.

Or they could just omit the content-type header, then the file extension would be used.

andy@bark ~> curl -I https://www.openssl.org/source/openssl-3.3.0.tar.gz
HTTP/2 200 
x-guploader-uploadid: ABPtcPrU7RWpmtP2LvsiHnlVY92nvTOlj8qGHcedRJGsr0pPXTv0zHaq3_BXOrBG0VjO8_s05S4
x-goog-generation: 1712666750724876
x-goog-metageneration: 1
x-goog-stored-content-encoding: identity
x-goog-stored-content-length: 18038030
x-goog-meta-goog-reserved-file-mtime: 1712665568
x-goog-hash: crc32c=1321TQ==
x-goog-hash: md5=yLBjr76oXYZ+Fh7LiBbPqQ==
x-goog-storage-class: STANDARD
accept-ranges: bytes
server: UploadServer
via: 1.1 google
date: Fri, 12 Apr 2024 22:04:51 GMT
age: 1440
last-modified: Tue, 09 Apr 2024 12:45:50 GMT
etag: "c8b063afbea85d867e161ecb8816cfa9"
content-type: application/x-tar
content-length: 18038030
cache-control: public,max-age=3600
strict-transport-security: max-age=31536000
alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000

So, Zig's behavior is correct here.

@andrewrk andrewrk closed this as not planned Won't fix, can't repro, duplicate, stale Apr 12, 2024
@andrewrk andrewrk removed bug Observed behavior contradicts documented or intended behavior standard library This issue involves writing Zig code for the standard library. zig build system std.Build, the build runner, `zig build` subcommand, package management labels Apr 12, 2024
@andrewrk andrewrk removed this from the 0.13.0 milestone Apr 12, 2024
@andrewrk andrewrk added the downstream An issue with a third party project that uses Zig. label Apr 12, 2024
@andrewrk
Copy link
Member Author

Fixed downstream.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
downstream An issue with a third party project that uses Zig.
Projects
None yet
Development

No branches or pull requests

1 participant