Skip to content

Enabling compression would be cheaper for website operators and users #287

@cbiffle

Description

@cbiffle

Hello! I have a blog that appears to be followed by at least one person using rss-parser to fetch the rss feed.

rss-parser is on a short list of programs that always fetch feeds without HTTP compression enabled. The RSS format compresses very well, and fetching my feed without compression costs both me and the user 12.6x more bandwidth than enabling brotli (a relatively recent addition to HTTP), or 9.6x more than enabling gzip (which has been standard since 1996). Uncompressed RSS fetches have represented over half of my outgoing bandwidth for the past 10 months, for a relatively small number of users with misbehaving clients. So, I've been trying to file bug reports explaining the issue, and now here I am!

It would be fantastic if rss-parser could generate requests permitting standard compression encodings by default. (This is slightly different than what was requested in #280, which was to send identity by default. I think that'd be a misfeature, since compression is good for basically everyone.)

After hitting my ISP's bandwidth cap earlier in August, I've recently deployed a proxy that denies large uncompressed requests across the board -- meaning my feed has recently become unavailable to anyone using rss-parser (and about three other uncommon RSS reader backends) because compression is not enabled. I'm working with some other small websites on defenses like this, and this sort of thing might become more common soon. So, I wanted to give you a heads up.

Thanks in advance!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions