cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: AW: problem with large file upload using ssl

From: Daniel Stenberg <daniel_at_haxx.se>
Date: Tue, 27 Jan 2009 11:39:06 +0100 (CET)

On Tue, 27 Jan 2009, Marco Vujevic [Steinberger IT] wrote:

>> Note that you've just given your password away in the logs you just sent.
>
> Doesn't matter, its not connected to the internet and only a test-machine
> anyway. But out of curiosity, where in the log is the password, so I can
> remove it next time. I thought I had 'xxx'ed anything important :)

The "Authorization: Basic" line has the username+password base64-encoded.

> For How long should i keep curl running to see some kind of timeout error? I
> allready tried several minutes.

It of course depends what component that would time out. I'm not sure waiting
for a timeout longer than several minutes will help out a lot here...

> Yes, the log ends there. If I use the libcurl (from c# via DLLimport, as the
> very outdated libcurl.net didn't work for us) the readfunction stops to get
> called after a few calls, and I don't get any more debugfunction calls
> either, but strange enough the progress function is still called.

I don't think that's very weird. First, you would probably get the progress
meter with curl as well if you just redirect the output somehere (using -o, -O
or >). It simply means that libcurl doesn't hang, it is just waiting for the
socket to become "readable" so that it can continue sending away the next
piece of the buffer.

To me this is a clear hint that the server somehow doesn't like the situation
and thus isn't accepting more data at this point. Have you checked the TCP
packet situation at the time libcurl stops sending? (Like with wireshark or
similar.)

Did you try to do the same operation against the same server but with plain
HTTP? Perhaps it would help to avoid an extra layer of complexity while
debugging this. It will certainly skip an extra layer of packeting and padding
of packets over the wire.

What does the server logs say for the error case?

Is this problem triggered exactly when the file size goes from 2147483647 to
2147483648 bytes? (I.e when 31 bits can't hold the number anymore?) Could it
be that the server somehow only reads a certain amount of bytes from the
client that wrap at 31 bits? So that for example a 2147583648 bytes upload
stops after 100000 bytes since it is 31bits + 100000 ?

> The only difference between -0 and the other log is that its using standard
> HTTP/1.0 instead of 1.1,

Ok, then we know the Expect: header was not the reason for this problem.

-- 
  / daniel.haxx.se
Received on 2009-01-27