Re: End of Line Handling (affects ALL platforms)
Date: Thu, 20 Apr 2006 01:30:09 +0200 (CEST)
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
> 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.htmlReceived on 2006-04-20