On 11 December 2011 09:55, Dan Fandrich <dan_at_coneharvesters.com> wrote:
[...]
> ** 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.

I'm not sure I like these workarounds all that much :) I quite like
the custom URL idea Steve originally proposed, although I understand
the objections and possible security issues mentioned by Daniel. Also
I will not be using libcurl for POP3 in the foreseeable future, so
these changes are unlikely to affect me.

> *** 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).

What about CURLOPT_NOBODY?

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

I think this is a worthy goal.

-- 
Michael Wood <esiotrot_at_gmail.com>
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html