>> i do not really see what is the idea?
>
> Imagine a person coming here asking for SIZE not being sent to the server.
> We then would need a way to do that. Another day someone else comes asking
> for some other command to be inhibited.
yes ;-) i understand.

>> could it be something like having an curl_slist of lines such as:
>
>> Size: verb=SIZE %file% to specify another verb?
>> or
>> Size: no to disable it?
>
> I think I'd prefer something simpler. Perhaps like:
>
> "SIZE:" to disable or
>
> "SIZE:MYONWSIZECOMMAND" to replace it
why not.

> But of course, supporting disabling or replacing _any_ command in the FTP
> code might require more code than this is worth...
hum, supporting replacing, as long as the command semantic/behaviour wrt
return data/code is identical/similar seems fair. supporting disabling is
indeed another job.
we could start with replacement and disable would be only permitted as the
time goes on, with the actual needs (starting with SIZE).
I presume that disabling will be less requested because libcurl issue
rarely/small amounts of "additional commands", from which the SIZE command,
and this is an issue only because it issues it systematically before each
request, this is the only command having this problem.

while I write that, I think a bit of how to implement this. we'd need a
ftp_is_command_enabled(FTP *ftp, char *original_command , char
**replacement_command), an option CURLOPT_FTP_COMMANDS taking an slist?

Armel
Received on 2006-08-13