cURL / Mailing Lists / curl-library / Single Mail


Re: [PATCH] POP3: Expanded the supported commands

From: Dan Fandrich <>
Date: Sat, 10 Dec 2011 23:55:27 -0800

On Sat, Dec 10, 2011 at 01:59:09PM +0000, Steve Holme wrote:
> The first 5 patches are related to modifying pop3.c and pop3.h to include
> support for the following POP3 commands in addition to LIST and RETR:
> NOOP No Operation (Keep Alive)
> STAT Get Mailbox Statistics
> TOP Get TOP number of rows for specified message
> DELE Delete specified message
> RSET Reset (Undo any deletes)
> I have implemented support for the above commands using curl's -X and
> libcurls CURLOPT_CUSTOMREQUEST options rather than as URLs as I had
> previously suggested.

Hmmm, this seems like a valid way to implement these, but not quite in the
same spirit as other uses of -X. For the other protocols (HTTP and FTP) -X
is used to replace the "main" command used in the transfer with ANY other
command, without otherwise changing the behaviour of the original command.
So, performing an HTTP GET but using -X POST won't make curl do a real
POST, it will make it do a normal GET but just say POST in the request.
That lets the user do nonsensical things (like changing a PUT into a GET,
or changing a GET into an FROB), but it also doesn't limit the user
when it comes to doing things that do make sense (like turning a GET
into a DELETE).

It sounds from the description above that this patch uses -X not to replace
one command with another as sent over the wire, but to actually change
curl's behaviour by changing the type of transfer performed. It might turn
out that this approach is the right one for POP-3, but I think that needs
to be debated some more. Such an approach could make it impossible to use -X
(in the same way as FTP and HTTP) as a future-proof way to extend the
behaviour of POP-3 in the face of arbitrary future extensions of the
protocol (since only those five commands above are supported and no more).

It turns out that all those five new commands (and probably most others)
follow one of two patterns: the command returns with only a response
code, or it returns with a response code and a multiline response.
That regularity tells me that it should be possible to use -X in the
same way for POP-3 as FTP and HTTP, that is, to send arbitrary commands
by replacing only the command and not the behaviour without having to
change the POP-3 state machine.

Since a normal message retrieval (RETR) returns a response code (*) and a
multiline response, any other POP-3 command that returns something similar
should be able to be replaced and work correctly. So, implementing TOP
(and all other similar POP-3 commands, like UIDL) should work by using a
normal message URL (which normally sends an RETR) and -X TOP to send TOP
instead (** there's an important gotcha discussed later). Instead of
returning the full message body, TOP would return just the top few
bytes of the message in place of the body from the application's point
of view.

Likewise, implementing NOOP, STAT, DELE and RSET (and all other similar
POP-3 commands) could be done by using -X STAT (or whatever) instead of
a normal command that returns just a response code and not a multiline
response (*** of which there is unfortunately currently none supported
in curl; see below).

So, the regular pattern of POP3 messages & responses should allow similar
flexible handling of -X in curl instead of special-casing only the few
commands above.

* The first issue is that some commands return valuable information in the
response code line. I'm not sure if curl implements it or not yet (looks like
not yet), but this could be simply returned in CURLOPT_ERRORBUFFER (I
think that's the one) for use by the application.

** Another issue is that some custom commands require more or more flexible
arguments than the ones currently supported in POP-3. For example, TOP
takes two arguments instead of the one used by RETR or LIST. This could
be worked around in a couple of ways, such as supressing the original
arguments altogether if a space is found in the custom request.

*** Also, the idea of substituting custom commands which don't return a
multiline response for another one that does is an elegant way to handle
such commands, except for the giant problem that curl doesn't currently
send any such commands as action to a specific kind of URL. That means
there's no way to use -X DELE to send DELE instead of...there is nothing!
This could be solved by adding a way for curl to send such a command in
order that it could be replaced later by a custom command. For example,
use -I/--head to send a STAT command if a URL doesn't specify a message.
Or, the rule could be that any custom command that does not return a
multiline response must be sent as a quote command (with -Q) instead of
as a custom command (-X).

I haven't really looked at the patch details; when I saw the command-
specific changes to the state machine, I just got the feeling that there
must be a more generic way to support these commands.

>>> Dan
List admin:
Received on 2011-12-11