homepage

When recv() return 0 we may still have data to send. Add a handler for this case, which may happen with some protocols, notably http1.0 ver.
Also, do not call recv with a buffer size of zero to avoid ambiguous return value (see recv man page).

Assigning this to me but am not sure 1) when I'll be able to look at this 2) whether it's worth it as asyncore is deprecated in favor of asyncio.

Hi!
> Assigning this to me but am not sure 1) when I'll be able to look at this 2) whether it's worth it as asyncore is deprecated in favor of asyncio.
Yes, asyncore is deprecated since 3.6.

Fair enough. I'll sign the CLA meanwhile you consider it.
In my opinion it may still be useful in addressing issues in existing projects written using asyncore (and maybe for python2 as well).
Thanks!

My personal opinion is: we should accept bug fixes for asyncore but stop adding new features to the module.
asyncio supersedes asyncore in all aspects.

> When recv() return 0 we may still have data to send.
It seems recv() returning b"" is an alias for "connection lost". E.g. in Twisted:
https://github.com/twisted/twisted/blob/06c891502be9f6389451fcc959cad5485f55d653/src/twisted/internet/tcp.py#L227-L248 

> It seems recv() returning b"" is an alias for "connection lost". E.g. in Twisted:
To my understanding, technically the connection is not fully closed, it is just shut-down for reading but we can still perform write operations on it (that is, the client may be still waiting for the response). I can reproduce it with an http-1.0 client, I'll try to put up a test to demonstrate it more clearly.
From recv() man page:
When a stream socket peer has performed an orderly shutdown, the return value will be 0 (the traditional "end-of-file" return).

Technically the change seems correct, we have the same logic for asyncio half-closed streams.
But I want to raise the flag again: why we are adding new functionality to the *deprecated* module? It violates our on deprecation policy, isn't it?

I agree. The problem I have with this is that it introduces a new method (handle_eof), which ends up in the "new functionality" bucket (even though it's not backward incompatible per-se, as it defaults on calling handle_close() anyway, but still it is technically a new API). Point with asyncore/chat is that every time you try to fix them you end up messing with the public API one way or another.
I know from experience (pyftpdlib) that all asyncore/chat users already subclass/overwrite the base classes quite massively, so if they really want to rely on this new functionality they probably already have implemented it themselves.

> But I want to raise the flag again: why we are adding new functionality to the *deprecated* module? It violates our on deprecation policy, isn't it?
I'm biased but I see this as more of a small and subtle fix for the current logic that incorrectly treats this as a closed connection, rather than a new feature.
In addition, it could serve a documentation hint for people troubleshooting edge cases in their code (especially people who are not familiar with these semantics).
> Point with asyncore/chat is that every time you try to fix them you end up messing with the public API one way or another.
I'd agree about the first commit (avoid calling recv with size zero), which may change the behavior for a poorly written application that tries to read a chunk of zero bytes, but the second commit is straight forward and I can't see how it could break anything.

The change adds a new public method.
The method should be added to documentation also.
Documentation requires `.. versionadded:: 3.8` tag.
It doesn't look like *just a bugfix* but a feature.

if not data:
 # a closed connection is indicated by signaling
 # a read condition, and having recv() return 0.
 self.handle_close()
 return b''
This above is the current code. Do you agree that it makes a wrong assumption and therefore behave incorrectly? If so, how do you suggest fixing it without adding a new method?
Otherwise; maybe we can at least amend the comment in the code, and perhaps add a word or two to the doc.