Item12961: Firefox does not send an accept-encoding in a http-2.0 (aka spdy) connection
Current State: Closed
Released In: 2.0.0
Target Release: major
Applies To: Engine
The specs of
, the new and upcoming HTTP protocol, say that all content requires to be compressed. Web-Servers like Nginx (there's a mod_spdy for Apache as well afaik), will do so in case the upstream Foswiki backend doesn't provided a compressed content right away.
Foswiki is able to gzip html already, and even cache the gzipped content to prevent repetitive compressing efforts on the server.
It will then fetch the gzip blob from the cache and send it to the client using the web-server down the line. However it will currently only do so when the browser indicated that it is accepting compressed content using the
Chrome does fine: it sends an
in its request even though this would be redundant in a http-spdy connection that is requiring compression anyway.
Firefox causes problems: it does not
in a http-spdy connection, maybe to spare the extra bits in the request, who knows. In this case Foswiki will read the cache, find a compressed html blob, decompresses it as the browser did not specify
, sends it to the web-server, which then decides to compress it again talking http-spdy to the browser.
Foswiki is not alone wrt Firefox here. Other web platforms have got the same problem as far as I have researched.
The obvious solution would be for Foswiki to detect that this is a http-spdy connection ... which however it can't. There's no such flag in the http request header, at least no one that makes it thru down the web-server-(f)cgi lane.
Only solution I've found so far is to add a
header to the
of the upstream Foswiki server in case the web-server is in a spdy session with the browser.
Using Nginx this is done easiest by editing
and add the line
fastcgi_param SPDY $spdy;
This will set
to a boolean value depending on the connection type. In turn Foswiki can then decide not to decompress a cached html page even though
hasn't been specified.
- 10 Jul 2014