Hrvoje Niksic wrote:
> That would work for short streaming, but would be pretty bad in the
> mkisofs example. One would expect Wget to be able to stream the data
> to the server, and that's just not possible if the size needs to be
> known in advance, which HTTP/1.0 requires.
One might expect it
"Tony Lewis" <[EMAIL PROTECTED]> writes:
> Hrvoje Niksic wrote:
>
>> I don't understand what you're proposing. Reading the whole file in
>> memory is too memory-intensive for large files (one could presumably
>> POST really huge files, CD images or whatever).
>
> I was proposing that you read the
Hrvoje Niksic wrote:
> I don't understand what you're proposing. Reading the whole file in
> memory is too memory-intensive for large files (one could presumably
> POST really huge files, CD images or whatever).
I was proposing that you read the file to determine the length, but that was
on the
Am Dienstag, 07.10.03, um 17:02 Uhr (Europe/Berlin) schrieb Hrvoje
Niksic:
That's probably true. But have you tried sending without
Content-Length and Connection: close and closing the output side of
the socket before starting to read the reply from the server?
That might work, but it sounds too d
Stefan Eissing <[EMAIL PROTECTED]> writes:
> Am Dienstag, 07.10.03, um 16:36 Uhr (Europe/Berlin) schrieb Hrvoje
> Niksic:
>> What the current code does is: determine the file size, send
>> Content-Length, read the file in chunks (up to the promised size) and
>> send those chunks to the server. Bu
Am Dienstag, 07.10.03, um 16:36 Uhr (Europe/Berlin) schrieb Hrvoje
Niksic:
What the current code does is: determine the file size, send
Content-Length, read the file in chunks (up to the promised size) and
send those chunks to the server. But that works only with regular
files. It would be reall
"Tony Lewis" <[EMAIL PROTECTED]> writes:
> Hrvoje Niksic wrote:
>
>> Please be aware that Wget needs to know the size of the POST
>> data in advance. Therefore the argument to @code{--post-file}
>> must be a regular file; specifying a FIFO or something like
>> @file{/dev/stdin} wo
Hrvoje Niksic wrote:
> Please be aware that Wget needs to know the size of the POST data
> in advance. Therefore the argument to @code{--post-file} must be
> a regular file; specifying a FIFO or something like
> @file{/dev/stdin} won't work.
There's nothing that says you have to
On Tue, 7 Oct 2003, Hrvoje Niksic wrote:
> My first impulse was to bemoan Wget's antiquated HTTP code which doesn't
> understand "chunked" transfer. But, coming to think of it, even if Wget
> used HTTP/1.1, I don't see how a client can send chunked requests and
> interoperate with HTTP/1.0 server
Theoretically, a HTTP/1.0 server should accept an unknown content-length
if the connection is closed after the request.
Unfortunately, the response 411 Length Required, is only defined in
HTTP/1.1.
//Stefan
Am Dienstag, 07.10.03, um 01:12 Uhr (Europe/Berlin) schrieb Hrvoje
Niksic:
As I was wri
As I was writing the manual for `--post', I decided that I wasn't
happy with this part:
Please be aware that Wget needs to know the size of the POST data
in advance. Therefore the argument to @code{--post-file} must be
a regular file; specifying a FIFO or something like
@file{/dev
11 matches
Mail list logo
