Ruby Forum NGINX > Question about Connection: close and proxy_pass

Hi,

We're using nginx to proxy between a piece of software that doesn't
understand our SSL certificate. The diagram looks like this

client --> port:443 --> nginx --> port:8181 --> WANDisco

What we are seeing is nginx is forwarding the request to WANDisco on 
port
8181 with a Connection: close header (as expected). The response is 
coming
back from WANDisco with a Connection: close header also, see below for 
the
abridged version

nginx -> wandisco
GET /svn/private/ HTTP/1.0
Host: 127.0.0.1:8181
Connection: close
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.1)
Gecko/2008072820 Firefox/3.0.1

wandisco -> nginx
HTTP/1.1 200 OK
Date: Thu, 04 Sep 2008 02:14:05 GMT
Server: Apache/2.2.9 (Debian) DAV/2 SVN/1.4.2 mod_ssl/2.2.9 
OpenSSL/0.9.8g
mod_perl/2.0.4 Perl/v5.10.0
Last-Modified: Thu, 04 Sep 2008 01:46:09 GMT
ETag: W/"66230//"
Accept-Ranges: bytes
Content-Length: 439
Connection: close
Content-Type: text/html; charset=UTF-8

[body skipped]

So the response has a content length and Connection: close. However 
nginx
does not consider the response 'done', until wandisco has closed its 
side
of the socket.

My reading of RFC 2616 is unclear. Section 14.10
(http://tools.ietf.org/html/rfc2616#section-14.10) says

"HTTP/1.1 defines the "close" connection option for the sender to
   signal that the connection will be closed after completion of the
   response. For example"

Which appears to indicate that the sender will close the connection, but
does not use RFC 2119 grammer to indicate that it must.

My question is, is this a bug? Should nginx close its side of the
connection onces it has read Content-Length: bytes, or should WANDisco
close its side after sending the response.

Cheers

Dave

On Wed, Sep 03, 2008 at 10:58:25PM -0400, Dave Cheney wrote:

> nginx -> wandisco
> mod_perl/2.0.4 Perl/v5.10.0
> does not consider the response 'done', until wandisco has closed its side
> does not use RFC 2119 grammer to indicate that it must. 
> 
> My question is, is this a bug? Should nginx close its side of the
> connection onces it has read Content-Length: bytes, or should WANDisco
> close its side after sending the response. 

I think these are bugs on both side:
1) nginx should send response after it gets CL bytes,
2) while WANDisco should close a connection after it has sent whole 
response,
   if it has said that "Connection: close".

Hi,

WANdisco have owned up to the close issue from their end, the latest
version apparently has a fix, although I haven't managed to try it
yet.

Cheers,
Steve

Hi,

Unfortunately the WANdisco upgrade didn't help, I'm still seeing the
same behavior.  It would be nice to have a nginx fix; I'm now using
pound to front this system.

Cheers,
Steve

BTW, here's my comments on the WANdisco support ticket:

   Here's the sequence of events:

   * Client initiates a request to nginx
   * Nginx initiates a request to WANdisco with "Connection: close"
   * WANdisco passes this through to Apache/SVN
   * Apache returns data with "Connection: close" and closes the
     connection as originally requested
   * WANdisco returns the data but does not close the connection
   * Connection hangs as nginx is waiting for the close

   My take on this is that WANdisco should be closing the
   connection. Either WANdisco is acting as a true server, in which case
   it should honour the "Connection: close", or it is acting in a
   transparent manner, in which case it should pass on the change of
   state (i.e. close) from Apache to nginx.  However the HTTP1.0 spec is
   vague on this.

However as Igor pointed out both sides seem to be at fault; nginx
should probably be closing the connection if it can given it has
received a close header.

Cheers,
Steve