As noted in a previous e-mail (Jan 31, "State of POP3 in curl?"), I'm working on a prototype POP3 download program utilizing libcurl. I've got my part of that prototype pretty much completed, but have noticed a couple of anomalies:
1. Libcurl is returning message data line-by-line, with two callbacks per line - one for the line data and the other for the CRLF. This seems like strange behavior. I'd coded as if I were getting the data off a TCP connection - might get one byte, might get the whole message in one shot, might get anything between. So I'm curious as to what the intent is here. If it's going to return line at a time, it would be nice to get the line with the CRLF in one callback. If, as a function of the dot de-stuffing, libcurl returns whole chunks of message data on CRLF boundaries, that would be fine too. I can deal with full, unaligned chunks of data too. For the moment, I'm not going to consider any sort of alignment entitlement. 2. Libcurl is dropping the final CRLF from the data. Although it can be coped with, this seems wrong. E-mail messages are always CRLF terminated lines. Not getting the final CRLF leaves a hanging, incomplete, line. I think this might be a mis-interpretation of RFC 1939, section 3 - Basic Operation: Responses to certain commands are multi-line. In these cases, which are clearly indicated below, after sending the first line of the response and a CRLF, any additional lines are sent, each terminated by a CRLF pair. When all lines of the response have been sent, a final line is sent, consisting of a termination octet (decimal code 046, ".") and a CRLF pair. If any line of the multi-line response begins with the termination octet, the line is "byte-stuffed" by pre-pending the termination octet to that line of the response. Hence a multi-line response is terminated with the five octets "CRLF.CRLF". When examining a multi-line response, the client checks to see if the line begins with the termination octet. If so and if octets other than CRLF follow, the first octet of the line (the termination octet) is stripped away. If so and if CRLF immediately follows the termination character, then the response from the POP server is ended and the line containing ".CRLF" is not considered part of the multi-line response. I think the libcurl implementation has keyed off the "CRLF.CRLF" sentence in the middle of this paragraph, whereas the final sentence clearly states that the final ".CRLF" is not part of the data. By implication, the immediately preceding CRLF of the last line is part of the data. Or, it's just a bug! ;P Using this write callback routine for a LIST command, size_t pop_list_data(char *ptr, size_t size, size_t nmemb, void *userdata) { int bytes = (int)(size * nmemb); int *num_msgs = userdata; int n; printf("list >%.*s<\n", bytes, ptr); if (*ptr >= '0' && *ptr <= '9') if ((n = atoi(ptr)) > 0) *num_msgs = n; return bytes; } with two messages in the mailbox, I get: > LIST < +OK 2 messages (31754 octets) list >1 16050< list > < list >2 15704< * Connection #0 to host XXXXXX left intact which shows both issues 1 & 2. (Yes, I did shamelessly take advantage of the line-by-line data return for the prototype. ;) This will be redone in a final version anyway, using STAT or UIDL.) Cheers! Rich ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html