Question about Connection: close and proxy_pass

Server NGINX
#1

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

#2

On Wed, Sep 03, 2008 at 10:58:25PM -0400, Dave C. 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”.
#3

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

#4

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

#5

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