patch: Separate error for 'unexpected socket close'

Lou Montulli lou at
Mon Jul 26 20:18:40 EDT 2010

Here is a bit of a late reply.   I was getting around to fixing some retry behavior in my code and came across a subtle problem.

In ne_207.c there is a function "ne_simple_request" that is used by many of the "ne_basic.c" commands.     I would really like to use this function in my code but it has a small issue.    It currently calls "ne_request_detroy()" at the end, and since I really care about the response code in the request, this makes it unsuitable.    I would like to request that "ne_simple_request" not call "ne_request_destroy" and that the destroy call be made near the allocators.   This seems like a cleaner solution anyways since it is nice to keep the allocators and destructors at the same scope.



-----Original Message-----
From: Joe Orton [mailto:joe at] 
Sent: Thursday, June 10, 2010 2:27 AM
To: Lou Montulli
Cc: 'John Muth'; neon at
Subject: Re: patch: Separate error for 'unexpected socket close'

On Tue, Jun 08, 2010 at 10:54:22AM -0700, Lou Montulli wrote:
> This is an interesting problem.  LibNeon error codes are currently 
> pretty basic and do create a problem for some cases.
> In my case I want to distinquish a network error from a server error.  

The distinction between an HTTP error response and a failure to receive 
an HTTP response is already exposed by the ne_request_* API.  I do 
expect people to use ne_request_* in favour of e.g. any ne_basic.h API 
if you need that kind of fine-grained error handling.

I am not averse to adding new error codes which cover failure modes with 
specific semantics.  A failure in body_fd_send() would seem like 
reasonable case.

But there are no specific semantics in HTTP for a "premature socket 
closure".  That means nothing.  neon is very careful to retry requests 
in the face of persistent connection failures only when it is safe.  

Inferring server state for a premature EOF, like John says he "assumes 
the server is busy", is really just trying to bend HTTP into an RPC 
protocol; I have no desire to extend the neon API for such cases.  
ne_request_* will allow you to interpret both a 503 response (NE_OK + 
status 503) and a TCP connection being refused (NE_CONNECT).

Regards, Joe

More information about the neon mailing list