Change Details

It has been reported that at least one png image fails to load with ERR_CONTENT_DECODING_FAILED: https://upload.wikimedia.org/wikipedia/commons/thumb/4/49/Relief_map_of_Serbia.png/272px-Relief_map_of_Serbia.png in esams. All esams frontend are affected, the object is cached on cp3037's varnish-be. curl --compressed fails with the following message: ``` curl: (61) Error while processing content unencoding: invalid stored block lengths ``` Most likely, esams is the DC that happened to cache a bad copy, as opposed to esams-specific network stuff. It is not clear why we try to gzip pngs at all, even if the browser accepts gzip. Using curl --compressed against vanrnish-be works fine, so the issue is mostl likely on the frontend side.

It has been reported that at least one png image fails to load with ERR_CONTENT_DECODING_FAILED: https://upload.wikimedia.org/wikipedia/commons/thumb/4/49/Relief_map_of_Serbia.png/272px-Relief_map_of_Serbia.png in esams. All esams frontend are affected, the object is cached on cp3037's varnish-be. curl --compressed fails with the following message: ``` curl: (61) Error while processing content unencoding: invalid stored block lengths ``` Most likely, the problem is not related to esams-specific network conditions. esams is probably just the DC that happened to cache a bad copy. It is not clear why we try to gzip pngs at all, even if the browser accepts gzip. Using curl --compressed against vanrnish-be works fine, so the issue is on the varnish frontend side.

It has been reported that at least one png image fails to load with ERR_CONTENT_DECODING_FAILED: https://upload.wikimedia.org/wikipedia/commons/thumb/4/49/Relief_map_of_Serbia.png/272px-Relief_map_of_Serbia.png in esams. All esams frontend are affected, the object is cached on cp3037's varnish-be. curl --compressed fails with the following message: ``` curl: (61) Error while processing content unencoding: invalid stored block lengths ``` Most likely, the problem is not related to esams-specific network conditions. esams iss probably just the DC that happened to cache a bad copy, as opposed to esams-specific network stuff. It is not clear why we try to gzip pngs at all, even if the browser accepts gzip. Using curl --compressed against vanrnish-be works fine, so the issue is mostl likely on theon the varnish frontend side.