HTTP Client FIN-ACK

[Maxim Dounin]

Hello!

On Sun, Sep 07, 2008 at 05:15:08PM -0400, Ray Racine wrote:

>NOT sure this is a nginx problem, but I thought I'd pass it along.
>
>I have a small custom Scheme HTTP library that uses its FFI to call Linux
>socket APIs.  In other words, its a home brew implementation.  I have used
>it to do various HTTP GETs/POSTs for RSS, JSON, etc with success.
>
>However, when I attempted to do a simple RSS fetch from a site which
>responds as  Server: nginx/0.6.25,  I observed an immediate, and unexpected,
>socket close (reset by peer) from nginx.    I suspect it might be nginx and
>how it handles TCP connections and not the 3rd server application (
>www.blippr.com).  Though it could be the application.
>
>Here is the sequence of events.
>
>1) Client connects fine.  TCP connect is standard 3-way handshake.  SYN,
>SYN-ACK, ACK
>2) My cliient sends a well-formed HTTP GET request for RSS content.
>3) My client library then closes my half of the duplex connection via
>"shutdown SHUT_WR".  This means at the TCP level a FIN/ACK is sent to nginx.
>(Semantically this means, the client will not be sending any more data.)
>4) nginx immediatly responds with a ACK, and then closes the socket without
>a response, by sending its own FIN/ACK, to which the client sends an ACK.
>In other words a standard 4-way TCP teardown. (Semantically nginx sending
>its own FIN/ACK means no more data will be sent.)
>
>>From what little I understand, it appears nginx is incorrectly interrupting
>the  SHUT_WR (sends a FIN/ACK) as an end TCP connection.  Not as "no more
>data will be sent on the write half (from the client) of the duplex TCP
>connection.
>
>However, I think the TCP correct behaviour for nginx should be to respond
>the HTTP request.  Even though the client intiated SHUT_WR  this only
>indicates no further data will be sent by the client, to which nginx should
>respond with an ACK, but _not_ close the connection until after sending the
>HTTP response and then sending its own FIN/ACK.
>
>The above 1-4 sequence works fine with all other  HTTP servers I've called
>to date.
>
>I do successfully recieve a response _if_ I do _not_ do a call "shutdown
>SHUT_WR" after sending the HTTP GET request, which is the workaround.
>
>Given my limited knowledge this what I think I'm seeking.  It IS very
>possible that nginx is not at fault here, but I thougt I'd pass it along.

There is no such thing as half-close in RFC 2616 (Hypertext 
Transfer Protocol -- HTTP/1.1).  The most relevant part I was able 
to find is from RFC 1945 (Hypertext Transfer Protocol -- HTTP/1.0, 
1.3 Overall Operation):

%    Except for experimental applications, current practice requires that
%    the connection be established by the client prior to each request and
%    closed by the server after sending the response. Both clients and
%    servers should be aware that either party may close the connection
%    prematurely, due to user action, automated time-out, or program
%    failure, and should handle such closing in a predictable fashion. In
%    any case, the closing of the connection by either or both parties
%    always terminates the current request, regardless of its status.

Please note: half-close isn't distinguishable from full close at 
the other end without sending data.  So in your situation server 
really have two options:

    1. Assume client closed connection ("due to user action, 
automated time-out, or program failure" - e.g. since user clicked 
'stop' button or clicked a link on a page) and try to minimize 
performance impact of doing unneeded work.

    2. Assume client does something strange with TCP like half-close 
for some unknown reason, and try to respond anyway.

By default nginx does 1 if request was proxied to backend and no 
reply from backend was got yet (and hence nginx has no chance to 
send data to client for unknown period of time on the one hand, 
and may save backend from unneded request on the other hand).  It 
may be instructed not to do so by proxy_ignore_client_abort 
configuration directive.

The strange thing in your story is that you see 'reset by peer', 
but I suspect it's just wording problem and you see normal FIN 
from nginx side, not RST.

Maxim Dounin

p.s. Just don't use shutdown(SHUT_WR) with http, it's wrong.