📜 ⬆️ ⬇️

Four sinister hexadecimal digits on error pages - and how to overcome them

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.

Source: https://habr.com/ru/post/135662/


All Articles