patch: Separate error for 'unexpected socket close'
lou at montulli.org
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.
From: Joe Orton [mailto:joe at manyfish.co.uk]
Sent: Thursday, June 10, 2010 2:27 AM
To: Lou Montulli
Cc: 'John Muth'; neon at lists.manyfish.co.uk
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
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).
More information about the neon