On Fri, 10 Aug 2007, Robson Braga Araujo wrote:

Please don't top-post!

> This change broke curlftpfs too. I don't see your point of "loads of
> existing applications that use NOBODY today with the current meaning". Loads
> of FTP applications used the NOBODY option with the previous meaning too and
> you just broke them nonetheless. Why do you think that printing an
> Accept-ranges: bytes is ok for an FTP connection?

Okay, let's pick this apart.

1) I did this change on June 24th. Nobody objected at the time.

2) I didn't just change the behavior of ftp-NOBODY. I fixed a bug that was
reported to us. The changed behavior on ftp-NOBODY was an unintended
side-effect.

3) I did acknowledge that this changed behavior can cause trouble and I've
tried to bring up a discussion on what we can do about it. Nobody (including
you) has responded or commented on that. (And in general I drop subjects that
nobody seems to care about when they (the subjects) don't bother me much.)

4) That printing of accept-ranges is not new, it's been in there for ages just
as I explained and as you can see in the code/CVS for yourself. I actually
guess it does more harm than good in there so we should probably cut it out...

5) Feel free to provide a fix. libcurl is a community project!

> Also I get the following stack trace when using the NOBODY option in 7.16.4:
>
> #0 0xb7ee555c in Curl_client_write (conn=0x8065058,
> type=<value optimized out>, ptr=0xb7f05c10 "Accept-ranges: bytes\r\n",
> len=0) at sendf.c:180
> #1 0xb7ee8497 in ftp_statemach_act (conn=0x8065058) at ftp.c:2126
> #2 0xb7ee9428 in ftp_easy_statemach (conn=0x8065058) at ftp.c:2896
> #3 0xb7ee9f95 in Curl_ftp (conn=0x8065058, done=0xb7b931fa) at ftp.c:3458
> #4 0xb7eedf8a in Curl_do (connp=0xb7b931f4, done=0xb7b931fa) at url.c:4299
> #5 0xb7efa595 in Curl_perform (data=0x805c798) at transfer.c:2421
> #6 0xb7efafbe in curl_easy_perform (curl=0x805c798) at easy.c:492
>
> I suspect this is because you're passing a constant array there on
> ftp.c:2126 and trying to change it on sendf.c:180.

Indeed, convert_lineends()'s changing of the input buffer is bound to cause
trouble for all those cases were a constant buffer is passed in... It is
curious that we haven't seen this bug before! :-/

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