Paramiko throws EOFError rather than returning a 0 length file or ENOENT

[Robert Collins]

On Wed, 2006-09-27 at 10:58 +0200, Vincent Ladeuil wrote:
> >>>>> "Robert" == Robert Collins <robertc at robertcollins.net> writes:
> ... if we let callers handle the file-like object tied to
> the socket, what guaranty do we have that they will read all the
> needed data before issuing a new request ? I know, I know, it
> works so far so they do their duty, but the doubt remains :).

The way we handle this in the smart server is to explicitly tie the
current request to the object its coming from, so that if someone does
not do their duty, it can error. (Or it could even cause the
statemachine to complete its download and unlink itself).


> 
> So far, what I have implemented in the bzr.urllib.keepalive
> branch is effective but a bit "brutal" :
> 
> - if an error is encountered, close the connection and retry one
>   time only (for one given request).

Thats reasonable. Note that there is a specific race condition to be
aware of - and a test would not go astray - but I'm not sure how to test
it ;). The race condition is:
1. send a request on a currently idle persistent socket
2. server closes the socket due to a activity timeout or other reason
3. we initiate read() to read the response.
3. FIN arrives, giving use a zero-length read with no error status.

This may be hidden by urllib, but we should be sure we handle it, and it
should not count as much towards the error count for a request, unless
we never have more than one persistent connection at a time, because
this can cascade across a whole set of idle connections.

> - consider all errors as ConnectionError.
> 
> That should provide a good user experience for any transient
> errors while still giving up with a little delay for persistent
> errors.
> 
> But I think I'm a bit overusing ConnectionError as meaning 'any
> error related to a live connection' instead of 'we couldn't
> connect to that server'. I intend to work on it these days but
> get delayed by more work arriving on my plate.
> 
>     Robert> The basic crux of the issue is wide variety of
>     Robert> implementations out there.
> 
> That's why I intend to work on the http test suite to ensure the
> robustness of the http transports by implementing 'bogus' test
> servers* allowing us to precisely test various parts of the
> protocol (early closed connections, bogus or partial status line,
> responses bodies when none are expected, no body when one is
> expected, etc). May be I'm over-engineering here...
> 
> But on the other hand, I think more and more about re-using the
> test suite to create a 'test_server' command that will determine
> (sp?) if a server is sufficiently compliant to be used with
> bzr.

That might be interesting. I think though, that having a robust http
implementation is important, and we should probably be trying to feed
this work, including the test harness for protocol oddities, into python
core - so we can eventually just have a regular urllib client and test
http server and not be worried about the details.

> The intent is to assist us debugging unknown servers, help users
> configuring their servers**, etc.
> 
>     Vincent
> 
> * I'm not currently happy with the first test I wrote, I had to
>   define *4* classes to implement 2 tests. What I think I need is
>   a way to communicate between the test and the server to set
>   options (close connection, send bogus status lines, etc). Any
>   help on the design will be greatly appreciated (again see
>   bzr.urllib.keepalive branch).

Martin is reviewing that at the moment. In terms of communication, I
think having the server be a pseudo server might be a good bet: rather
than using TCP and a real server, have an opener that returns a fake
socket that will just respond to write and read calls appropriately - no
need for threads or any other overhead, and its trivial to write
scenarios for.

-Rob


-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20061016/eef2b225/attachment.pgp