A guide may be distributed as plain XML or as a gzip-compressed file. Compression reduces download size, but the reader must know how to decompress the response. A filename ending in .gz is a useful clue rather than proof that every player will accept it directly.
Match the reader’s supported input
Some readers accept compressed guide URLs directly; others expect plain XML or a supported response encoding. Follow the reader’s documentation. Renaming a compressed file to .xml does not decompress its contents.
Avoid confusing two compression layers
A server can compress an HTTP response while the underlying resource is also a compressed archive. Those layers are handled differently. If maintaining a guide endpoint, serve accurate response headers and test the actual client rather than assuming a browser download proves compatibility.
Keep decompressed copies private
Guide URLs can carry account tokens even when programme data itself is not secret. If you save a decompressed diagnostic copy, avoid carrying credentials into filenames or shared folders. Retain only what is useful for the investigation.
A practical sequence
- Check whether the reader supports .xml.gz input.
- Use a local decompression tool if a plain XML copy is required.
- Keep the original URL and private tokens out of public reports.
An example
Changing guide.xml.gz to guide.xml leaves compressed bytes unchanged. A reader expecting XML text will still be unable to parse those bytes.
Questions about this topic
Does .gz mean a different schedule format?
No. It normally indicates compression around the data.
Should I upload the guide to an online decompressor?
Use a local tool when the file or URL contains private account information.
