HTTP Client FIN-ACK

[Ray Racine]

Hi ya!,

Thanks for the response.

I did some additional research.  It appears the debate on what to do with
half-close clients with regards to HTTP goes back quite a ways.  I disagree
that it is "strange" to do a TCP half-close, its part and parcel to the
protocol itself and situationally, for a client it does make sense to do
so.   On the other hand, I also agree with you, given the additional
background reading I've done, its probably just better to avoid it given the
ambiguity around doing a half-close in the context of HTTP and varous
alludes found in the HTTP RFC(s).

It may or then again it may not be of interest that nginx is somewhat unique
in its behavior on how it deals with a half-close compared to other HTTP
systems I've observed so far.  These other systems Apache, IIS, Varnish,
lighthttpd, ... first complete the response and then finish the close
handshake.  nginx is the only system I've observed so far which responds
with an immediate close (FIN/ACK).

Thanks,

Ray


On Sun, Sep 7, 2008 at 9:57 PM, Maxim Dounin <mdounin at mdounin.ru> wrote:

> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20080908/5acf71f6/attachment.html>