On Jan 29, 2007, at 6:34 AM, Daniel Stenberg wrote:

> On Mon, 29 Jan 2007, Corey Jewett wrote:
>
>> I spent a while googling around and it looks like this is probably
>> a problem with my provider, but it also seemed possible that it's
>> an untested edge case.
>>
>> I'm trying to pipe stdin to a WebDAV server, but once the 100
>> Continue comes back nothing happens. Curl reports 0 for
>> everything. After 5 minutes the server kicks me back a 413,
>> content too large.
>>
>> $ dd if=/dev/zero bs=1024 count=10 |curl -k --digest --user
>> demo@bingodisk.com:bingo -vvv -T - https://demo.bingodisk.com/
>> bingo/zeros > out
>
> This operation takes 5 minutes? I take it uploading 10K should be
> fairly fast?

Yes, should be quite snappy. After 5 minutes, curl receives a 413
from the server and exits. curl's progress output indicates zero
bytes transfered for the entire duration.

> Using "--trace-ascii <file> --trace-time" might bring some more
> clues than just -v (and -vvv is the same as plain -v).
>
>> If I write the dd to disk and then use -T <file> it works like a
>> champ.
>
> The only difference between -T - and -T <file> is that the former
> makes use of "transfer-encoding: chunked". To me it sounds as if
> your receiving server has problems to receive a PUT using chunked
> encoding.

I too am suspecting the provider, but I thought I'd check to see if
it was a known issue.

> You could use the --trace options on both transfers and compare the
> differences to see if you detect anything noteworthy.

Nothing notable. When I dd to a temp file and use -T on the temp file
it succeeds in about half a second.

Thanks,
Corey
Received on 2007-01-29