Thanks Steve. Due to the old version used in the report and the many fixes than later I'm closing this issue. If there's any issue similar to this existing in the latest version or in git, then please submit a new report since it will certainly be much different. Also note that there's no need to file anything for the known issues Steve mentions here. There's a new release pending release next week that should have our best POP3 support so far.

Thanks Andy for the report!

---
** [bugs:#1211] curl_easy_perform() hangs when receiving an empty list**
**Status:** closed-out-of-date
**Created:** Tue Apr 02, 2013 09:08 PM UTC by Andy Wright
**Last Updated:** Wed Apr 03, 2013 05:07 PM UTC
**Owner:** Steve Holme
Date: 2 April 2013
Version: curl 7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
Server: pop3s://<myusername>@pop.gmail.com:995
Task: Downloading list of unread messages from Pop3 server using libcurl.
Curl commands and options:
  curl = curl_easy_init();
  curl_easy_setopt(curl, CURLOPT_URL, host.c_str());
  curl_easy_setopt(curl, CURLOPT_USERNAME, user.c_str());
  curl_easy_setopt(curl, CURLOPT_PASSWORD, pwd.c_str());
  curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION , DownloadHandler::execute);
  curl_easy_setopt(curl, CURLOPT_WRITEDATA, &data);
  res = curl_easy_perform(curl);
Handler: Standard format handler, declared as static.
size_t DownloadHandler::execute( void *source , size_t size , size_t nitems , void *userData )
{  
	stringstream* msgout = static_cast<stringstream*>(userData) ;
	char *msgin = static_cast<char*>(source) ;
	const int bufferSize = size * nitems ;
	msgout->write(msgin, bufferSize);
	return bufferSize;
}
Output:
When the Pop3 server has messages, they are successfully downloaded via the handler and control is passed back 
to calling program. However, when there are no messages, the handler receives the following 3 characters - '.' 
'\n' and '\t' and then waits as if expecting more data.
Observations:
I have not inspected the curl source-code. However another developer, Graeme Gill, stated in July 2011 (see 
http://www.mail-archive.com/curl-library@cool.haxx.se/msg09597.html):
>Curl_pop3_write()function [is] not detecting the end of body marker properly.
>
>In curl 7.21.7 it's defined as "\r\n.\r\n", but this assumes
>that there is at least one line of reply in the body to supply
>the first "\r\n". For the LIST command when there are no
>messages, this is not the case, and curl_easy_perform() hangs.
Graeme goes on to state:
>A side effect of this bug is that the final line looses its
>"\r\n" ending.
>
>Another problem is that the byte-stuffed sequence "\r\n.."
>(ie. escaped EOB) is not being un-stuffed.
I must say, I don't quite understand the significance of these last points. From my POV, the first is not an 
issue, as my program never gets access to the content prior to the final line anyway because the curl function 
hangs. I have no idea what byte-stuffing is, but include it for completeness.
The first issue Graeme identifies appears to be the same problem I am experiencing. The only difference is 
that the orphan sequence in my case is .\n\t and not .\r\n as described by Graeme. I am unfamiliar with the 
range of output from mail servers and presume that this is one of the possible variations. In any case, both 
sequences correspond to the standard "dot on a line by its own" control sequence.
I'm guessing that my need for curl to download the list is common to all users of the curl Pop3 routines. I 
use the number of messages in the list to control a loop running calls with the "\1" URL to download messages 
one at a time. If the curl function hangs when the list is empty, it is unusable, and waiting for an 
individual read to fail is too messy to contemplate.
I have temporarily dealt with the issue by having my handler throw an error by returning the wrong number when 
it detects the 3 byte sequence when not preceded by other data. The calling program then treats the error as 
indicating no more messages. This is enough for my purposes at this stage of my project but would obviously not 
be suitable for eventual roll-out.
Naturally, it would be much better if I didn't have to perpetrate this atrocity! If anyone can help Daniel 
with this issue, here is one user who would be extremely grateful!
Andy Wright
---
Sent from sourceforge.net because you indicated interest in <https://sourceforge.net/p/curl/bugs/1211/>
To unsubscribe from further messages, please visit <https://sourceforge.net/auth/subscriptions/>