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@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
