On Wed, 19 Apr 2006, David McCreedy wrote:

>> Doesn't the "Almost all" and "some" of the paragraph [below] make such a
>> calculation and assumption rather error-prone?
>
> Yes, it is error-prone. And I'd be happy with a more reliable method of
> handling this but I don't know that there is one since we're dependent on
> the FTP server giving us the right SIZE response.
>
> But it also implies that the current code has some of the same
> vulnerabilities with line end handling...

As far as I remember and the current code looks like, we just don't do any
size comparisons when doing ASCII transfers. I did it that way since I
couldn't come up with a reliable way to do that check.

> A real concern here is that Curl closes the connection if the (greater than
> zero) SIZE doesn't match the number of bytes FTPed. That would be almost all
> text/ascii transfers. Not a desirable outcome.

It doesn't. The outcome is instead that libcurl can't verify that the complete
and expected file size was transfered.

> We could make inbound and outbound line end translations optional,
> controlled by a new CURLOPTion for FTP.

That would be weird. Then users can use the existing crlf option or they could
do binary.

> Actually, I'd lean towards a new CURLOPTion just so line end handling is
> more flexible instead of saying Platform X always does line end translation
> on text/ascii transfers.

FTP ASCII transfers imply line end translations mandated by RFC959 AFAIK so I
don't consider it something we need to think much about.

Unless I'm mistaken.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html