Content-Length header missing after proxying

Server NGINX
1

I have nginx configured to proxy to an upstream using the following
in nginx.conf:

http {
upstream app {
server localhost:8080;
}

 server {
     listen       80;

     location / {
proxy_pass http://app;
# proxy_pass_header Content-Length;

}
}
}

The upstream returns some data with the HTTP Content-Length header
set. Using wget to connect directly I see:

Connecting to localhost|127.0.0.1|:8080… connected.
HTTP request sent, awaiting response…
HTTP/1.0 200 OK
Content-Type: application/x-javascript
Connection: keep-alive
Content-Length: 44552
Length: 44552 (44K) [application/x-javascript]

When I make a request via nginx however, the Content-Length header is
no longer present (again using wget):

Connecting to localhost|127.0.0.1|:80… connected.
HTTP request sent, awaiting response…
HTTP/1.1 200 OK
Server: nginx/1.0.5
Date: Tue, 23 Aug 2011 18:40:30 GMT
Content-Type: application/x-javascript
Connection: close
Length: unspecified [application/x-javascript]

Is there any obvious reason this should be happening, or something I’m
doing wrong? The proxy_pass_header directive in the configuration file
seems to make no difference to the outcome when I uncomment it.

Thanks,
James

2

please help give out the info " nginx -V" , then we can give your help.

thanks
george

3

Hello!

On Tue, Aug 23, 2011 at 07:44:20PM +0100, James Fidell wrote:

Connecting to localhost|127.0.0.1|:8080… connected.

Is there any obvious reason this should be happening, or something I’m
doing wrong? The proxy_pass_header directive in the configuration file
seems to make no difference to the outcome when I uncomment it.

I suspect that you aren’t using the config you provided above, but
instead additionally have something like ssi enabled, i.e.
something like

ssi on;
ssi_types application/x-javascript;

also present in your config.

Maxim D.

4

On 24/08/11 06:27, Geoge.Q wrote:

please help give out the info " nginx -V" , then we can give your help.

$ /usr/local/nginx/sbin/nginx -V
nginx: nginx version: nginx/1.0.5
nginx: built by gcc 4.1.2 20080704 (Red Hat 4.1.2-50)
nginx: TLS SNI support disabled
nginx: configure arguments: --with-http_ssl_module --user=nginx
–group=nginx

James

5

On 24/08/11 07:14, Maxim D. wrote:

I suspect that you aren’t using the config you provided above, but
instead additionally have something like ssi enabled, i.e.
something like

 ssi on;
 ssi_types application/x-javascript;

also present in your config.

Unfortunately not :frowning:

It isn’t the config that I’ll be using in production, but with the
exception of a couple of lines I’m hoping are not relevant to the
problem, it is the config that I’m using to try to track down what’s
going wrong. For completeness though, here’s what I have:

cat nginx.conf

worker_processes 1;

events {
worker_connections 1024;
}

http {
upstream app {
server localhost:8080;
}

server {
    listen       80;

    location / {
            proxy_pass http://app;
            # proxy_pass_header Content-Length;
    }
}

}

nginx running with that configuration produced exactly the output from
wget that I showed in my original email.

James

6

On Wed, Aug 24, 2011 at 08:53:45AM +0100, James Fidell wrote:

events {

    location / {
            proxy_pass http://app;
            # proxy_pass_header Content-Length;
    }
}

}

nginx running with that configuration produced exactly the output from
wget that I showed in my original email.

Then only debug log may help:
http://nginx.org/en/docs/debugging_log.html

–
Igor S.

7

On 24/08/11 11:37, Igor S. wrote:

Then only debug log may help:
A debugging log

And it did. Thank you.

When I connect to the application with wget it uses HTTP/1.1, which gets
a content-length header in the response. nginx is connecting using
HTTP/1.0, which doesn’t.

I’m guessing there’s not a whole lot I can do about that?

James

8

On Wed, Aug 24, 2011 at 12:20:49PM +0100, James Fidell wrote:

I’m guessing there’s not a whole lot I can do about that?

It’s strange that the application sends Content-Length for HTTP/1.1.
It’s valid header in HTTP/1.0. HTTP/1.1 allows to send chunked response
without length.

–
Igor S.

9

Hello outside there,

I’m working on a corresponding issue
To get [email protected] through an ssl-offload proxy I’ve set the
following nginx configuration:

upstream nodejs3001 {
server 127.0.0.1:3001;
}

server {
listen 127.0.0.1:84;
server_name portal.domain.tld;
access_log /var/log/nginx/customlogfile.log;

location / {
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_set_header X-NginX-Proxy true;
    proxy_pass http://nodejs3001;
    proxy_redirect off;
}

}

this is the last log-entry:
192.168.1.123 - admin [06/Sep/2011:15:28:37 +0200] “GET
/socket.io/1/xhr-polling/1502126590706860217?t1315315712123 HTTP/1.1”
200 0 “http://127.0.0.1:84/” “Mozilla/5.0 (Macintosh; Intel Mac OS X
10_7_1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220
Safari/535.1”

and this is the content of the header regarding to get this last step:
Request
URL:http://127.0.01:84/socket.io/1/xhr-polling/1603386210380646057?t1315315788760
Request Headersview source
Referer:http://127.0.0.1:84/
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_1)
AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.220 Safari/535.1
Query String Parametersview URL encoded

I think we’ll have the most success here:
https://github.com/ajaxorg/cloud9/issues/267

Tell me… Are you trying to do the same?
µatthias