Skip to content

fix(spiders): gunzip template bodies by magic bytes only, not when Content-Type says gzip - #565

Open
yetval wants to merge 1 commit into
D4Vinci:devfrom
yetval:fix/gzip-magic-bytes-only
Open

yetval wants to merge 1 commit into
D4Vinci:devfrom
yetval:fix/gzip-magic-bytes-only

Conversation

@yetval

@yetval yetval commented Nov 5, 2026

Copy link
Copy Markdown
Contributor

Summary

This PR fixes an issue where SitemapSpider, XMLFeedSpider, and CSVFeedSpider incorrectly attempt to decompress responses that are already plain XML or CSV.

Problem

Currently, _decompress relies on the Content-Type header to determine whether a response is gzipped. If the server incorrectly labels plain content as gzip, this causes a decompression error and prevents URLs from being extracted.

For example, Dell's sitemap returned 0 out of 3,030 URLs because its plain XML was labeled as application/x-gzip.

Fix

Updated _decompress to check for the actual gzip magic bytes (1f 8b) instead of relying on the Content-Type header. Existing gzip-bomb protection and invalid gzip handling remain unchanged.

Testing

  • Added regression tests for incorrectly labeled gzip responses.
  • All 69 relevant tests passed.
  • Live Dell test improved from 0 to 3,030 URLs dispatched.
  • Ruff lint and formatting checks passed.

@yetval
yetval force-pushed the fix/gzip-magic-bytes-only branch from 9f050b8 to e7c7bfd Compare November 9, 2026 17:37

This branch has not been deployed

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant