ERR_CONTENT_DECODING_FAILED

Configuring a reverse proxy is not an easy task. It involves some trial and error and dealing with unexpected errors. One of those errors is ERR_CONTENT_DECODING_FAILED. The web site won’t load in your browser will show this error message:

Error ERR_CONTENT_DECODING_FAILED may show up in your browser when a resource is configured on your reverse proxy, and the backend communication is working. That is: the backend is returning data, but not in a form the browser expects.

Example: browser expects a GZIP response, but receives plain text. Therefore the hint from your browser about content decoding failed. The content is received, but the browser is not able to decode / understand the data. If a plain text response is expected, but the received response from the backend is zipped, the browser cannot read the content.

To solve this error, reset the Accept-Encoding request header in your Reverse Proxy configuration.

Apache

Documentation

RequestHeader unset Accept-Encoding

Example

<Location /test>
    RequestHeader unset Accept-Encoding
    ProxyPass https://0.0.0.0:443
    ProxyPassReverse https://0.0.0.0:443/
    Order allow,deny
    Allow from all
</Location>

NGINX

Documentation

proxy_set_header Accept-Encoding "";

Solving reverse proxy error ERR_CONTENT_DECODING_FAILED

Configuring a reverse proxy is not an easy task. It involves some trial and error and dealing with unexpected errors. One of those errors is ERR_CONTENT_DECODING_FAILED. The web site won’t load in your browser and Chrome will show this error message:

Error ERR_CONTENT_DECODING_FAILED may show up in your browser when a resource is configured on your reverse proxy, and the backend communication is working. That is: the backend is returning data, but not in a form the browser expects. Like: browser expects a GZIP response, but receives plain text. Therefore the hint content decoding failed. Content received, but the browser is not able to decode / understand the data.

To solve this error, reset the Accept-Encoding request header in your Reverse Proxy configuration.

Apache

RequestHeader unset Accept-Encoding

http://httpd.apache.org/docs/current/mod/mod_headers.html 

Example Apache configuration section for a location named test.

<Location /test>
  RequestHeader unset Accept-Encoding
  ProxyPass https://0.0.0.0:443
  ProxyPassReverse https://0.0.0.0:443/
  Order allow,deny
  Allow from all
</Location>

NGINX

proxy_set_header Accept-Encoding "";

http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_set_header

Custom 503 error page for Apache

A 5xx error code is returned by a web server when something went wrong: The server was not able to process the request. For a reverse proxy, a common 5xx error message is 503, meaning that the backend server is not reachable.

In the technical architecture of my blog site, the WordPress site with my blogs is hosted on a Raspberry Pi in my living room, while external access is through a reverse proxy hosted on Amazon EC2. If now the reverse proxy on EC2 cannot reach my Raspberry Pi, a 503 error message is given.

The root cause can be that the Raspberry Pi is turned off, there is no Internet connection available for some reason (power outage, provider problem), or something else. In case this happens, EC2 reverse proxy will throw an error and try to show the Apache standard 503 error page. The web page used to display the 503 is the same for all Apache installations worldwide. Giving your users a more personalized message can be a nice touch. For instance, including a statement that you are aware of the issue, it won`t take long to get solved, or a better explanation of what happened.

For this to work, you need to have

  1. A custom 503.html file and
  2. Configure Apache to use this web page.

Create custom 503 file

This is up to you. Internet and Google are your friend.

Apache configuration

Apache has the ErrorDocument directive. For an HTTP error code you specify a HTML file to be shown. Make the 503 HTML file created by you in the above section available on the web server.

/var/www/html/error/503.html

Important: the document root of Apache is /var/www/html. For accessing the file, the browser will call the URL /error/503.html. Reference it in the Apache configuration.

sudo vim /etc/httpd/conf/httpd.conf

Insert

ErrorDocument 503 /error/503.html

You are done in the case of a normal web server setup. The configuration shown so fare won`t work for a reverse proxy. A reverse proxy will forward all requests to the backend server, including the request for the 503 document. To not forward /error/503.html to the backend, put /error/ in a exception list. With this, every request to /error/ won`t be forwarded by Apache, and instead be served from the local web server. To exclude /error/ from the ProxyPass rule, add:

ProxyPass /error/ !

This exclusion must be before the other ProxyPass directives. A somewhat more complete example of a Apache configuration:

<VirtualHost _default_:443>
  DocumentRoot "/var/www/html"
  ProxyPass /error/ ! 
  ErrorDocument 503 /error/503.html
  SSLProxyEngine On
  ProxyPass / https://backend/
  ProxyPassReverse / https://backend/
  SSLEngine on
</VirtualHost>

Restart Apache

sudo service httpd restart

The next time the backend server is not reachable, the reverse proxy will serve the custom 503 error page to the users.

Operate GateOne behind Apache reverse proxy

After installing GateOne on my Raspberry Pi 2 Debian system, I can log on to SSH via HTTP and browser. But only from my internal network, as the external accessible port is blocked by Apache. To add GateOne from outside, I either can disable Apache (no, won`t do it) or make GateOne accessible through Apache. I`ll use Apache as a reverse proxy for this.

Note: you`ll need Apache 2.4 for this, as GateOne uses Websocket for communication, and this is included only ootb with Apache 2.4.

Configuration

GateOne

I won`t use a subdomain for this example, so no new Apache virtual host will be use. This means that I have to use a URL prefix to access GateOne. The prefix is: /ssh. This must be configured in the GateOne configuration file:

sudo vim /opt/gateone/server.conf

Change the parameter url_prefix and restart GateOne

url_prefix = "/ssh"

To be able to access GateOne from external, the URL of the external server must be added to origin. In my case, this means that www.itsfullofstars.de is added.

origins = "https://www.itsfullofstars.de:8081;http://127.0.0.1;http://localhost

Apache

To make use of Apache as a reverse proxy, first the modules must be enabled. You can do this with a2enmod. Add also the web socket module

sudo a2enmod proxy_wstunnel
sudo a2enmod proxy_http 

Edit the apache configuration to add a reverse proxy for /ssh. Do this for HTTP and WS. In case GateOne listens on TLS, do this for HTTPS and WSS.

ProxyPass /ssh ws://127.0.0.1:9080/ssh
ProxyPassReverse /ssh ws://127.0.0.1:9080/ssh
ProxyPass /ssh http://127.0.0.1:9080/ssh
ProxyPassReverse /ssh http://127.0.0.1:9080/ssh 

Restart Apache.

sudo service apache2 restart

Now its possible to access GateOne through /ssh from external.

SAP Web Dispatcher as reverse proxy for SMP3

As of SMP3 SP07 you can use SAP Web Dispatcher as a reverse proxy for SMP3. Depending on your landscape, this simplifies A LOT your architecture. And you can reuse your WD knowledge and gain support from SAP. Installing the WD is done as usual, with one caveat: you have to inform the commonlib which TLS to use:

ssl/ciphersuites = 896:HIGH

ssl/client_ciphersuites =896:HIGH

With this, WD can connect to SMP3 using TLS. While this may look strange, it actually is necessary as SMP3 uses some high TLS security.

To understand better what these two parameters do, take a look at the Commonlib + WD SAP Note: 510007


A complete sample profile from a WD running on Windows

SAPSYSTEMNAME = WDP

SAPSYSTEM = 00

DIR_INSTANCE = C:\<dir>\SAPWDSMP3

DIR_EXECUTABLE = $(DIR_INSTANCE)

DIR_PROFILE = $(DIR_INSTANCE)

DIR_HOME = $(DIR_INSTANCE)

Autostart = 1

Restart_Program_00 = local $(DIR_EXECUTABLE)/sapwebdisp$(FT_EXE) pf=$(DIR_PROFILE)/sapwebdisp.pfl

wdisp/ssl_auth=0

wdisp/system_0 = SID=SMP, SSL_ENCRYPT=0, EXTSRV=http://smp3.tobias.de:8080, SRCSRV=*:9080, SRCURL=/, STICKY=true

wdisp/system_1 = SID=SEC, SSL_ENCRYPT=1, EXTSRV=https://smp3.tobias.de:8081, SRCSRV=*:9081, SRCURL=/, STICKY=true

wdisp/system_1 = SID=SEC, SSL_ENCRYPT=1, EXTSRV=http://smp3.tobias.de:8082, SRCSRV=*:9082, SRCURL=/, STICKY=true

icm/server_port_0 = PROT=HTTP,PORT=9080

icm/server_port_1 = PROT=HTTPS,PORT=9081

icm/server_port_2 = PROT=HTTPS,PORT=9082,VCLIENT=2

ssl/ciphersuites = 896:HIGH

ssl/client_ciphersuites =896:HIGH

icm/max_conn = 2000

icm/max_sockets = ($(icm/max_conn) * 2)

icm/req_queue_len = 6000

icm/min_threads = 10

icm/max_threads = 500

mpi/total_size_MB = (min(0.06 * $(icm/max_conn) + 50, 2000))

mpi/max_pipes = ($(icm/max_conn))

wdisp/HTTP/max_pooled_con = ($(icm/max_conn))

wdisp/HTTPS/max_pooled_con = ($(icm/max_conn))

icm/server_port_3 = PROT=HTTPS,PORT=4300

icm/HTTP/admin_0 = PREFIX=/sap/wdisp/admin,PORT=4300,DOCROOT=./admin,AUTHFILE=icmauth.txt