It's https://fr.wikipedia.org/wiki/K.A.Z .
Only an endless sequence of symbols and characters (like �\x08\x03�}]�\x1cG���ίH�L��MwW�� ) appears.
Version: unspecified
Severity: normal
It's https://fr.wikipedia.org/wiki/K.A.Z .
Only an endless sequence of symbols and characters (like �\x08\x03�}]�\x1cG���ίH�L��MwW�� ) appears.
Version: unspecified
Severity: normal
The reason for this is the HHVM version of the page responds with
Content-encoding: x-compress (!?!)
while the Zend page reports
Content-encoding: gzip
which is correct.
https://fr.wikipedia.org/wiki/K.A.Z when requested on the HHVM appservers has a Content-encoding: x-compress header set on the backend, while any other frwiki page has not.
I still haven't determined if this is generated by the apache server itself, by mediawiki or by HHVM.
Another step in the right direction: this is not an HHVM bug, rather a problem with our apache config;
HHVM gives the following headers when interrogated with furl:
X-Content-Type-Options: nosniff
Content-language: fr
Content-type: text/html; charset=UTF-8
X-UA-Compatible: IE=Edge
Vary: Accept-Encoding, Cookie
X-Powered-By: HHVM/3.3.1
Cache-control: s-maxage=2678400, must-revalidate, max-age=0
Last-Modified: Tue, 11 Nov 2014 17:10:57 GMT
so the problem is most probably with the url ending in ".Z" and apache doing "the stupid thing" and attaching an useless Content-encoding: x-compress that shouldn't be there.
(In reply to Giuseppe Lavagetto from comment #3)
Another step in the right direction: this is not an HHVM bug, rather a
problem with our apache config;HHVM gives the following headers when interrogated with furl:
X-Content-Type-Options: nosniff
Content-language: fr
Content-type: text/html; charset=UTF-8
X-UA-Compatible: IE=Edge
Vary: Accept-Encoding, Cookie
X-Powered-By: HHVM/3.3.1
Cache-control: s-maxage=2678400, must-revalidate, max-age=0
Last-Modified: Tue, 11 Nov 2014 17:10:57 GMTso the problem is most probably with the url ending in ".Z" and apache doing
"the stupid thing" and attaching an useless Content-encoding: x-compress
that shouldn't be there.
It's not doing it for responses from Zend, though.
HTTP/1.1 200 OK
Server: nginx/1.1.19
Date: Tue, 11 Nov 2014 17:20:21 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 10205
Connection: keep-alive
X-Content-Type-Options: nosniff
Content-language: fr
Content-Encoding: x-compress
Expires: Thu, 01 Jan 1970 00:00:00 GMT
X-UA-Compatible: IE=Edge
X-Powered-By: HHVM/3.3.1
Last-Modified: Tue, 11 Nov 2014 17:20:21 GMT
Vary: Accept-Encoding,Cookie,X-Use-HHVM
X-Varnish: 2122721143, 628312231, 973907266
Via: 1.1 varnish, 1.1 varnish, 1.1 varnish
Accept-Ranges: bytes
Age: 0
X-Cache: cp1054 miss (0), amssq60 miss (0), amssq38 frontend miss (0)
Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
X-Analytics: php=hhvm
HTTP/1.1 200 OK
Server: nginx/1.1.19
Date: Tue, 11 Nov 2014 17:21:51 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 10211
Connection: keep-alive
X-Content-Type-Options: nosniff
Content-language: fr
X-UA-Compatible: IE=Edge
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Last-Modified: Tue, 11 Nov 2014 17:21:53 GMT
Content-Encoding: gzip
Vary: Accept-Encoding,Cookie,X-Use-HHVM
X-Varnish: 394331984, 607480533, 1553788423
Via: 1.1 varnish, 1.1 varnish, 1.1 varnish
Accept-Ranges: bytes
Age: 0
X-Cache: cp1052 miss (0), amssq58 miss (0), amssq44 frontend miss (0)
Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
X-Analytics: php=zend
So the problem is in this directive we have in our mod_mime config:
AddEncoding x-compress Z
What does AddEncoding do?
Under apache 2.2:
The AddEncoding directive maps the given filename extensions to the specified encoding type. MIME-enc is the MIME encoding to use for documents containing the extension. This mapping is added to any already in force, overriding any mappings that already exist for the same extension.
Under Apache 2.4:
The AddEncoding directive maps the given filename extensions to the specified HTTP content-encoding. encoding is the HTTP content coding to append to the value of the Content-Encoding header field for documents named with the extension. This mapping is added to any already in force, overriding any mappings that already exist for the same extension.
so, while apache 2.4 seems to do the right thing in general, it breaks all pages ending in .Z for us.
I think we may safely discard that directive from our config.
https://gerrit.wikimedia.org/r/172578 should solve this; however I'd like to dig a little bit more to find out if any side effect is to be expected