With this mysterious glitch you will encounter only with a combination of several conditions at once.

Your site is served by
Apache Server . (This condition is not difficult to fulfill: now Apache is one of the most popular web servers.)
Your site is also equipped with a
nginx caching server. (When purchasing a
shared hosting for a small site, you may not be aware of anything until the last minute that the hosting provider, taking care of saving resources, has hung nginx.
If, of course, you don’t read the
HTTP response headers
.)')
You put any
engine running on PHP. (For example, CMS Drupal.
Or, for example, the MediaWiki wiki.)
After that you want to see how the
error pages
â„–404 , created by the engine, look like. You feed the address of a non-existent article to the wiki, or feed the address of a non-existent page to Drupal.
And then they come.
Four hexadecimal digits. They appear in the code of the page with the description of the 404 error (as well as 403), they stand in
front of the “ <! DOCTYPE ” in this code, and therefore many browsers (for example, Firefox) tend to display them above the rest of the text of the page - which means that break down the design conceived by the creators of the CMS or wiki:
3340 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" dir="ltr"> <head> <title> … … …
What's the matter?
Drupal, it turns out, calls the function
“ drupal_set_header ('HTTP / 1.1 404 Not Found') in case of error 404. Yes, there is a similar error in MediaWiki (even in the most recent
version 1.18 - I checked). Instead of carefully checking the status of the superglobal variable
$ _SERVER ['SERVER_PROTOCOL'] , the engines naively assume that using
HTTP version 1.1 is safe.
However, this is far from the case: nginx relies on
HTTP version 1.0 protocol when communicating with the backend. In turn, Apache Server, seeing the
HTTP 1.1 protocol in the PHP response (and, moreover, with the missing
Content-Length header
), goes
to HTTP 1.1 and sends the answer in
chunks and provides the title
“Transfer-Encoding: chunked”, but nginx no way will help.
How to solve a problem?
Very simple. It is enough to put two directives in the Apache Server configuration (for example,
in the .htaccess file inside the directory with the wiki or CMS engine) that force Apache to use
HTTP version 1.0 without alternative
: SetEnv force-response-1.0 1 SetEnv downgrade-1.0 1
This allows you to immediately achieve the desired.
Well, the above-described problem cannot be called a new one - and yet an adequate recipe for solving it lies on Habrahabr only in the comments
for the 2009
subzam , and therefore does not gobble up at all. Personally, it was easier for me to find it
on WebFaction .
I correct a state of affairs, having laid out on Habrahabr own statement of a problem and retelling of the effective recipe of its decision.