On Wed, Dec 21, 2011 at 11:51:55AM +0000, Steve Holme wrote:
> I guess this could only be done if everything after the OK was sent through
> as body data but to be honest I don't think this is the right approach as a
> transfer would still be required for certain commands and not for others.

The same is true for FTP. If someone wants to send a 'RETR' as a quote
command, curl isn't going to stop him but he can't expect a sane result.
>
> I guess we can:
>
> 1) Implement each command using a unique URL as per my original email from
> the 1st.
>
> 2) Break the commands down into three categories as follows and use a URL
> for each category:
>
> Information type commands (LIST, UIDL, CAPA and STAT)
> Retrieve type commands (RETR and TOP)
> Instruction based commands (NOOP, DELE, RSET)
>
> 3) Try and keep the existing two formats:
>
> Message based commands (LIST, UIDL, RETR, TOP and DELE)
> Non Message based commands (LIST, UIDL, CAPA, STAT, NOOP and RSET)

I think you're missing my first preference:

4) Break the commands into two categories: those that return a "body" and
those that don't:

  Body-returning: LIST, UIDL, RETR, TOP, CAPA
  Non-body-returning: STAT, NOOP, DELE, RSET

> The problem we've seen with option 3 is it isn't possible write a generic
> handler that is command agnostic as different commands return different
> amounts of data that may or may not require a transfer to be instigated. For
> example OK or OK followed by information no not require a transfer but OK
> and a multiline response or OK followed by information and a multiline
> response do.

Exactly the same could be true for FTP. It's up to the user to specify a
sane set of -Q or -X options.

> Even with option 2, where RETR and TOP return OK followed by multiple lines
> of data and NOOP, DELE and RSET simply return OK, the problem is that LIST
> and UIDL will return OK followed by information when a message id is
> specified but will return OK followed by both information and multiline of
> data when a message id is not specified, yet CAPA returns multiple lines of
> data after the OK and STAT simply returns information.

I still like option 4), leaving it to the user to specify a sane set of
overrides. But, we'd still need a way to specify a URL that doesn't
expect a body. Maybe just change POP3 so that if CURLOPT_NOBODY is set, it
performs a STAT command and doesn't expect a body, and use that as the basis
for overriding with the other non-body-returning commands. Also, the
non-body-returning commands could be sent as quote commands.

> Obviously anything that is received after the OK can be sent to the client
> as HEADER data rather than as BODY.

That makes sense to me.

> > Regarding the "gotcha" about TOP (as an example) requiring more than
> > one argument. Is there a reason we can't just provide them in the
> > URL space-separated?
> >
> > Like "curl -X TOP pop3://example.com/FOO%20BAR" would send
> > "TOP FOO BAR" instead of RETR.
>
> I don't have any qualms about this - but does anyone else? To this degree,
> anything that is in the final part of the path can just be sent to the
> server as is (after being URL decoded of course!)

This one feels too much like a hack for my taste, but I can't think of
anything better right now.

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