Browser showing headers and Gziped code inside body

Server NGINX
1

I’m currently using nginx/1.4.7 and for some reason a client is
complaining
that the page is showing with errors in both his browsers (Firefox and
IE).

The error in question is the following:

Does anyone have any suggestion or idea of why this is happening?

Regards.

$ nginx -V
nginx version: nginx/1.4.7
built by gcc 4.7.2 (Debian 4.7.2-5)
TLS SNI support enabled
configure arguments: --with-cc-opt=‘-g -O2 -fstack-protector
–param=ssp-buffer-size=4 -Wformat -Werror=format-security
-D_FORTIFY_SOURCE=2’ --with-ld-opt=-Wl,-z,relro
–prefix=/usr/share/nginx
–conf-path=/etc/nginx/nginx.conf
–http-log-path=/var/log/nginx/access.log
–error-log-path=/var/log/nginx/error.log
–lock-path=/var/lock/nginx.lock
–pid-path=/run/nginx.pid
–http-client-body-temp-path=/var/lib/nginx/body
–http-fastcgi-temp-path=/var/lib/nginx/fastcgi
–http-proxy-temp-path=/var/lib/nginx/proxy
–http-scgi-temp-path=/var/lib/nginx/scgi
–http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit
–with-ipv6 --with-http_ssl_module --with-http_stub_status_module
–with-http_realip_module --with-file-aio --with-http_spdy_module
–with-http_addition_module --with-http_dav_module
–with-http_flv_module
–with-http_geoip_module --with-http_gzip_static_module
–with-http_gunzip_module --with-http_image_filter_module
–with-http_mp4_module --with-http_perl_module
–with-http_random_index_module --with-http_secure_link_module
–with-http_spdy_module --with-http_sub_module --with-http_xslt_module
–with-mail --with-mail_ssl_module
–add-module=/usr/src/nginx/source/nginx-1.4.7/debian/modules/headers-more-nginx-module
–add-module=/usr/src/nginx/source/nginx-1.4.7/debian/modules/nginx-auth-ldap
–add-module=/usr/src/nginx/source/nginx-1.4.7/debian/modules/nginx-auth-pam
–add-module=/usr/src/nginx/source/nginx-1.4.7/debian/modules/nginx-cache-purge
–add-module=/usr/src/nginx/source/nginx-1.4.7/debian/modules/nginx-dav-ext-module
–add-module=/usr/src/nginx/source/nginx-1.4.7/debian/modules/nginx-development-kit
–add-module=/usr/src/nginx/source/nginx-1.4.7/debian/modules/nginx-echo
–add-module=/usr/src/nginx/source/nginx-1.4.7/debian/modules/ngx-fancyindex
–add-module=/usr/src/nginx/source/nginx-1.4.7/debian/modules/nginx-push-stream-module
–add-module=/usr/src/nginx/source/nginx-1.4.7/debian/modules/nginx-lua
–add-module=/usr/src/nginx/source/nginx-1.4.7/debian/modules/nginx-upload-progress
–add-module=/usr/src/nginx/source/nginx-1.4.7/debian/modules/nginx-upstream-fair
–add-module=/usr/src/nginx/source/nginx-1.4.7/debian/modules/nginx-syslog
–add-module=/usr/src/nginx/source/nginx-1.4.7/debian/modules/ngx_http_pinba_module
–add-module=/usr/src/nginx/source/nginx-1.4.7/debian/modules/ngx_http_substitutions_filter_module
–add-module=/usr/src/nginx/source/nginx-1.4.7/debian/modules/ngx_pagespeed
–add-module=/usr/src/nginx/source/nginx-1.4.7/debian/modules/nginx-x-rid-header
–with-ld-opt=-lossp-uuid

Posted at Nginx Forum:

2

What you provided clearly shows that nginx has been compiled with
3rd-party
modules.

Standard debugging procedures suggest:
1°) Removal all 3rd-party modules to address issues in core nginx only
2°) If not enough, check your logs to see if anything appears in them
regarding that client connection(s)
3°) If not enough, read official nginx docs for instructions on how to
activate debug log http://nginx.org/en/docs/debugging_log.html

If 2°) or 3°) are relevant (ie problem with core nginx still appears to
your client), please provide the collected logs/errors messages here.

B. R.

3

On 2 June 2014 19:09, Satake [email protected] wrote:

I’m currently using nginx/1.4.7 and for some reason a client is complaining
that the page is showing with errors in both his browsers (Firefox and IE).

The error in question is the following:

Dropbox - Error - Simplify your life

Does anyone have any suggestion or idea of why this is happening?

I /was/ about to suggest you post the output of a “curl -v -o
/dev/null” of that page as I thought you probably have the
Content-Type header set to something incorrect.

But then I noticed that your screenshot actually shows a sub-request
getting inserted halfway through the page, after the header. I suggest
that whatever entity is combining the page header and the sub-request
body is causing your problem, by not dealing with its input correctly.