On Thu, 18 Sep 2008, hippocat_at_verizon.net wrote:

I'm cc'ing my reply to the curl-library list which really is more suitable for
this topic! Please take follow-ups on that list.

Your mail did confuse me. Here's a bunch of questions and comments...

> And finally:
>
> bytesfromsocket = MIN((long)sizerequested, conn->data->set.buffer_size ?
> conn->data->set.buffer_size : BUFSIZE);
>
> if(conn->protocol & PROT_SFTP)
> nread = Curl_sftp_recv(conn, num, buffertofill, bytesfromsocket);
>
> Ok, curl requesting buffer with magic number 16384 + ?head data?

Can you explain to me how it can ask for more than 16384 bytes with this code?

As I read it, the code asks for up to 16384 bytes. Possibly less - but never
more.

> and it is always generating error LIBSSH2_ERROR_CHANNEL_PACKET_EXCEEDED for
> that specific server (looks like it sends extra data which is ?Spec says we
> MAY ignore bytes sent beyond? ? just legal, but not for curl).

If libssh2 returns an error libcurl will consider that to be an error. If the
case is fine by a protocol spec libssh2 should not return an error in the
first place.

> Then data truncated and makes data out of sync with data len

How is that? libssh2 returns an error then isn't libcurl just bailing out?

And if not, how is it getting out of sync?

> curl getting crazy and connection dropped by sftp server.

How is "curl getting crazy" because of this?

> Simple fix is to reduce CURL_MAX_WRITE_SIZE and it works.

How come 16K is such a magic limit for the SSH2 code, do you know?

I disagree it being a fix though, it's just a work-around!

> How many bytes ? I believe it depends on server, but something like 16000
> will work.

Hm, does this mean we can force the bug to happen if we instead bump the
buffer size to something like 32K or so? I mean as a help to fix this
"properly" in the libssh2 end?

I can consider adding the work-around for the SFTP case just to make libcurl
play better with existing libssh2 but I would prefer to make a real fix (as
well).

> Or just disable data truncation in libssh2 which is also works.

But that will make libssh2 send more data than its windows allow, doesn't it?
Or did I misunderstand that check?

> I beleive there is better patch but I dont have time to dig cURL, so
> probably developers could take care about this special case ?

I'll try!

-- 
  / daniel.haxx.se