Skip to content

_GzipDecoder.decompress() incompatible with urllib3 2.6.x (missing max_length parameter) #16043

Closed

Description

@Leolebleis

Summary

google-resumable-media defines a _GzipDecoder subclass of urllib3.response.GzipDecoder in google/resumable_media/requests/download.py (line 655). This subclass overrides decompress() with a signature that only accepts data:

class _GzipDecoder(urllib3.response.GzipDecoder):
    def decompress(self, data):
        self._checksum.update(data)
        return super().decompress(data)

urllib3 2.6.0 (CVE-2025-66471) added a max_length parameter to GzipDecoder.decompress() and BaseHTTPResponse._decode() now calls self._decoder.decompress(data, max_length=max_length).

Because _GzipDecoder.decompress() doesn't accept max_length, this raises:

TypeError: _GzipDecoder.decompress() got an unexpected keyword argument 'max_length'

Reproduction

Install google-resumable-media==2.8.0 with urllib3>=2.6.0 and download a gzip-encoded blob from GCS using google-cloud-storage.

Suggested fix

Update _GzipDecoder.decompress() (and _BrotliDecoder if applicable) to forward additional keyword arguments:

def decompress(self, data, **kwargs):
    self._checksum.update(data)
    return super().decompress(data, **kwargs)

Versions

  • google-resumable-media==2.8.0
  • urllib3>=2.6.0 (tested with 2.6.3)
  • google-cloud-storage==2.19.0
  • Python 3.12

Activity

  1. parthea commented on Mar 6, 2026

    @parthea
    Contributor

    Thanks for reporting this issue. I'm going to migrate this to google-cloud-python as we are in the process of migrating the code for google-resumable-media there.

  2. added
    type: bugError or flaw in code with unintended results or allowing sub-optimal usage patterns.
    priority: p1Important issue which blocks shipping the next release. Will be fixed prior to next release.
    on Mar 6, 2026
  3. Leolebleis commented on Mar 6, 2026

    @Leolebleis
    Author

    Thank you! I just noticed that the fix is already merged in both the old repo and the monorepo, but no release has been cut since v2.8.0. Any timeline for a new release?

  4. daniel-sanche commented on Mar 6, 2026

    @daniel-sanche
    Contributor

    The monorepo is released every Thursday. so now that it's moved over, you can expect the next release on the 12th

  5. daniel-sanche commented on Mar 6, 2026

    @daniel-sanche
    Contributor

    I think we can close this out if the code for the fix is merged, but feel free to re-open if you still see the issue

  6. christhegrand commented on Apr 1, 2026

    @christhegrand

    Was a fix for this released, and if so which version was it fixed in?

  7. christhegrand commented on Apr 1, 2026

    @christhegrand

    Thank you! We're unfortunately dealing with a production issue caused by this right now and are upgrading to the new version of the library.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

api: storageIssues related to the Cloud Storage API.priority: p1Important issue which blocks shipping the next release. Will be fixed prior to next release.type: bugError or flaw in code with unintended results or allowing sub-optimal usage patterns.

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions