the gzip check goes by the URL ending and content type, so a sitemap.xml.gz?ts=123 with a generic type might slip through, and checking data.startswith(b"\x1f\x8b") would cover that. root.iter() can also pick up image loc entries, so findall with the unused NS map plus the current loop as a fallback could keep things clean.
for robots.txt, cutting anything after a hash and stripping the line first would handle trailing comments and indented Sitemap lines. might also be worth a size cap in fetch, since one big compressed sitemap gets fully decompressed into memory
Thanks, all four are fair and I've folded them into the script. It now sniffs the first two bytes (\x1f\x8b) instead of trusting the suffix or Content-Type, so sitemap.xml.gz?ts=123 served with a generic type works. It takes only the <loc> that is a direct child of each <url>/<sitemap>, so <image:loc> from the image extension no longer leaks in. robots.txt lines are stripped and cut at # before matching Sitemap:. And fetch caps both the download and the decompressed size at 50 MB, the protocol's per-file limit, so a small .gz can't balloon in memory. I've updated the snippet in the post.
OnlineProxy
the gzip check goes by the URL ending and content type, so a sitemap.xml.gz?ts=123 with a generic type might slip through, and checking data.startswith(b"\x1f\x8b") would cover that. root.iter() can also pick up image loc entries, so findall with the unused NS map plus the current loop as a fallback could keep things clean.
for robots.txt, cutting anything after a hash and stripping the line first would handle trailing comments and indented Sitemap lines. might also be worth a size cap in fetch, since one big compressed sitemap gets fully decompressed into memory