helm: gzip: invalid header

I’m getting “gzip: invalid header” from helm/tiller when trying to install a chart from a helm repository hosted through bitbucket.io. I’ve also tried an Azure CDN and get the same error.

These are the basic build steps for installing helm and packaging the chart. At the end I simply add the .tgz and updated index to a repository and commit it.

It seems like when the file is fetched/downloaded using helm the gzip compression is stripped off and we are left with a tar file, however if I just use a browser to download the file the gzip compression is left intact and we can install that file local from disk just fine.

What am I doing wrong/How do I fix this?

# install helm
- wget "https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get" -O /usr/local/bin/helm-install.bash
- chmod +x /usr/local/bin/helm-install.bash
- helm-install.bash -v v2.5.1
- helm init --client-only
- export HELM_PACKAGE_VERSION=0.$BITBUCKET_BUILD_NUMBER.0
- helm package chart/design-service --version=$HELM_PACKAGE_VERSION
- helm repo index --url https://buildasign.bitbucket.io/helm --merge siterepo/helm/index.yaml siterepo/helm
...  other steps to check in to repo

helm repo add buildasign https://buildasign.bitbucket.io/helm/ helm repo update helm upgrade -i qa-design-service buildasign/design-service Release “qa-design-service” does not exist. Installing it now. Error: gzip: invalid header

About this issue

Original URL
State: closed
Created 7 years ago
Reactions: 3
Comments: 40 (10 by maintainers)

Most upvoted comments

FWIW I got this inappropriate error as well when I pointed to a yaml file instead or a chart directory.

+76

Elexy on Oct 31, 2018

Still the same issue, even when file stored locally

helm version Client: &version.Version{SemVer:“v2.11.0”, GitCommit:“2e55dbe1fdb5fdb96b75ff144a339489417b146b”, GitTreeState:“clean”} Server: &version.Version{SemVer:“v2.11.0”, GitCommit:“2e55dbe1fdb5fdb96b75ff144a339489417b146b”, GitTreeState:“clean”}

Deploy should be to azure aks cluster. helm install work well. Issue also reproducible from azure devops (vsts) using ubuntu16.04 hosted agent.

Work around: copy helm files to the same directory with helm. In this case - it will work. In Azure DevOps(VSTS) - you may use “Copy” task.

SychevIgor on Mar 4, 2019

I hit similar issue with Helm (3.0.3) and Bitbucket, but the problem is this one:

Error: file '<cache>/helm/repository/passwordstore-0.7.2.tgz' does not appear to be a gzipped archive; got 'application/octet-stream'
helm.go:75: [debug] file '<cache>/helm/repository/passwordstore-0.7.2.tgz' does not appear to be a gzipped archive; got 'application/octet-stream'

The gzip is a legit one, but when helm check the content type got application/octet-stream and not x-gzip. I think the problem is in this check in the file chart/loader/archive.go:

if contentType := http.DetectContentType(buffer); contentType != "application/x-gzip"

That should accept octect/stream too

sciack on Feb 12, 2020

D’ouch… I thought I was pretty clear on that case, but it seems not… So I will try to reiterate:

Bitbucket wrongly sets:

Content-Type: application/x-tar
Content-Encoding: gzip

Most probably it happens on their webserver because of ignored MIME table or something like that. In that specific case, for full-featured browsers in order to DOWNLOAD tar.gz file it should be set to something like:

Content-Type: application/x-gzip
Content-Encoding: application/octet-stream

So this is honestly Bitbucket’s problem (or any other misconfigured webserver). However it’s only related to a WWW with full featured browsers which have to differentiate rich content, use different behavior for similar data streams in different cases. This manged by all these special headers returned from server.

With helm we have very specific case - we just need to download binary file (and we know it’s binary) from server, then untar it with uncompress option and that’s it. We should ignore any transformations in the middle. And in our case that transformation in the middle done by HTTP client library used by helm. It tries to behave like full-featured browser, respects headers returned by server and tried to adapt received data for a user, but there is no user behind that - there is a code that tries to uncompress already uncomressed data again.

LMK if I have to provide more details.

dene14 on Apr 20, 2018

Locally I’m able to untar it with tar xvf using the z option gives the error

gzip: stdin: not in gzip format

jonathan-kosgei on Mar 26, 2018

I am facing the same issue. But this is only appearing when one automation is running multiple helm charts together. This is the error that we are getting:

Error: file "/root/.cache/helm/repository/chartA-0.1.0.tgz" does not appear to be a gzipped archive; got "application/octet-stream"

    at ChildProcess.exithandler (child_process.js:281:12)
    at emitTwo (events.js:126:13)
    at ChildProcess.emit (events.js:214:7)
    at maybeClose (internal/child_process.js:915:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:209:5)```

Ygshvr on Apr 1, 2020