Rust - invalid gzip header

rel_0477

Previously, I reported a bug where publishing Rust packages wouldn't compress properly and thus wouldn't be able to be viewed online or pulled. Re: Rust Crates are uploaded with an incorrect compression method

I am experiencing a new error when attempting to pull a Rust package from ProGet.

Error:

Caused by:
  failed to iterate over archive

Caused by:
  invalid gzip header

I am able to view the package fine on the web interface, which is unique to the previous error.

atripp

Hi @rel_0477 ,

Sounds like this is a pretty specific edge case. Can you provide a reproduction case so we can take a look?

Thanks,
Alana

rel_0477

I reproduced it in the following:

cargo new reproduction --lib
cd reproduction
cargo publish --index sparse+<proget url> --token <token> --allow-dirty
cd ..
cargo new pull
cd pull
nano Config.toml

My Config.toml:

[package]
name = "pull"
version = "0.1.0"
edition = "2024"
publish = ["crates-io"]

[dependencies]
reproduction = {version = "0.1.0", registry = "crate"}

cargo build

Result:

cargo build
    Updating `crate` index
     Locking 1 package to latest Rust 1.87.0 compatible version                                                             
  Downloaded reproduction v0.1.0 (registry `crate`)                                                                                
error: failed to unpack package `reproduction v0.1.0 (registry `crate`)`                                                           

Caused by:
  failed to iterate over archive

Caused by:
  invalid gzip header

rhessinger

Hi @rel_0477,

Thanks for sending over the reproduction case. I was able to identify the issue, PG-2993, and have it ready to go in the next maintenance release of ProGet.

Thanks,
Rich

rel_0477

@rhessinger Thank you for the quick response! I am still experiencing this issue on the latest release of ProGet, are you able to verify that it is fixed on your end? Thank you again.

rhessinger

Hi @rel_0477,

I apologize for not responding sooner. Can you please navigate to Manage Feed -> Storage & Retention and run the re-index operation? That should fix any packages that were pushed with the invalid JSON header.

Thanks,
Rich

rel_0477

@rhessinger Are you kidding? You responded extremely fast! I wasn't being sarcastic, I truly appreciate the rapid support from the ProGet team, it's admirable.

I went ahead and ran the index job and deleted the package and republished it to no avail. I also went ahead and retried the reproduction case above, and it worked fine (I was able to publish & pull).

Cargo logs:

$ cargo build
    Updating `crate` index
     Locking 1 package to latest Rust 1.87.0 compatible version
  Downloaded reprod v0.1.0 (registry `crate`)
  Downloaded 1 crate (815B) in 0.17s
   Compiling reprod v0.1.0 (registry `crate`)
   Compiling pull v0.1.0 (C:\Users\relax\dev\rust\.test\pull)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 2.03s

$ cargo build
    Updating `crate` index
     Locking 3 packages to latest Rust 1.87.0 compatible versions
      Adding bridge-logger v1.0.0 (registry `crate`)
      Adding log v0.4.27 (registry `crate`)
      Adding once_cell v1.21.3 (registry `crate`)
error: failed to download `bridge-logger v1.0.0 (registry `crate`)`

Caused by:
  unable to get packages from source

Caused by:
  failed to unpack package `bridge-logger v1.0.0 (registry `crate`)`

Caused by:
  failed to iterate over archive

Caused by:
  invalid gzip header

Results from the reindex:

INFO : 2025-06-19 18:11:40Z - Performing reindex for Cargo feed 2: cargo
INFO : 2025-06-19 18:11:40Z - Deactivating feed.
DEBUG: 2025-06-19 18:11:40Z - Checking for crates that include a JSON header...
DEBUG: 2025-06-19 18:11:40Z - Found 0 crates with JSON headers.
DEBUG: 2025-06-19 18:11:40Z - Checking for orphaned FeedPackages...
DEBUG: 2025-06-19 18:11:40Z - No orphaned FeedPackages found.
DEBUG: 2025-06-19 18:11:40Z - Recalculating latest versions of packages...
DEBUG: 2025-06-19 18:11:40Z - Health check complete; recording results...
INFO : 2025-06-19 18:11:40Z - Re-activating feed.

I'm not sure what would be causing my original package to not even be able to be pulled, I suspect it might be cached improperly. I'll continue to investigate to ensure that it's my side only.

Thank you again, I truly appreciate all of the support.

rel_0477

@rel_0477 Yes, it was my side. Thank you!

rhessinger

Hi @rel_0477,

I just happen to check right when this came in. Glad to hear it is working again! Was it the local cache? Cargo has a pretty aggressive cache for both good and bad packages.

Thanks,
Rich