Page MenuHomePhabricator

HHVM enabled: Pages ending with .Z show garbage due to x-compress being sent
Closed, ResolvedPublic

Description

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

Details

Reference
bz73274

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 3:49 AM
bzimport set Reference to bz73274.

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 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.

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