On Thu, Mar 17, 2011 at 01:57:09PM -0700, bnoordhuis wrote:
> I tried to write a test case for this but gave up after two rather frustrating hours with the test framework.
>
> To reproduce, do a request to an empty mailbox:
>
> $ src/curl -v pop3://testuser:testuser_at_localhost/
> * About to connect() to localhost port 110 (#0)
> * Trying ::1... Connection refused
> * Trying 127.0.0.1... connected
> * Connected to localhost (127.0.0.1) port 110 (#0)
> * POP3 0x24bfbb8 state change from STOP to SERVERGREET
> < +OK Dovecot ready.
> > USER testuser
> * POP3 0x24bfbb8 state change from SERVERGREET to USER
> < +OK
> > PASS testuser
> * POP3 0x24bfbb8 state change from USER to PASS
> < +OK Logged in.
> * POP3 0x24bfbb8 state change from PASS to STOP
> * DO phase starts
> > LIST
> * POP3 0x24bfbb8 state change from STOP to LIST
> < +OK 0 messages:
> .
> * POP3 0x24bfbb8 state change from LIST to STOP
> * DO phase is complete
>
> That last line is where curl hangs. The reply from the server ends with `.\r\n` but the response parser expects to see `\r\n.\r\n`.

I've added test case 811 to test this scenario. Would you mind rebasing and
trying it again? I'm not sure the test for "+OK 0" in that patch is
valid. I don't see anything in the POP3 spec that says a server has to
list the number of messages in the +OK response line for a LIST command
that doesn't specify a message number, and test case 811 doesn't do so.

>>> Dan
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-03-18