ALIDATE to CLOSE_FINISH.
That's exactly the right change. As the comment implies, the only
reason for using CLOSE_INVALIDATE is fear that a misbehaving CGI might
send more data, thus confusing the next request or even causing
deadlock while writing the request to the server.
When keep-alive
On Thursday, November 13, 2003 at 2:49:41 PM +0100, Hrvoje Niksic wrote:
> Maybe it's time to stop erring on the side of caution, and expect HEAD
> to work.
I experimented in gethttp() line 1474 of wget-1.9.1/src/http.c:
| /* Return if we have no intention of further downloading. */
| if
Alain Bench <[EMAIL PROTECTED]> writes:
> There is no such problem. Sorry: I made a stupid log interpretation
> mistake yesterday. The connection is always closed after a HEAD, OK,
> but is reused after a GET, whatever comes after.
>
> This makes a typical --timestamping session use connections fo
On Wednesday, November 12, 2003 at 2:28:04 PM +0100, Hrvoje Niksic wrote:
> Alain Bench <[EMAIL PROTECTED]> writes:
>> Wget also closes the connection between a GET (with body) and the
>> HEAD for the next file.
> I wasn't aware of this problem
There is no such problem. Sorry: I made a stupi
Alain Bench <[EMAIL PROTECTED]> writes:
> OK, wasn't aware of the spurious HEAD bodies problem. But Wget also
> closes the connection between a GET (with body) and the HEAD for the
> next file.
Could you post a URL for which this happens? I wasn't aware of this
problem and would like to fix it.
On Tuesday, November 11, 2003 at 2:41:31 PM +0100, Hrvoje Niksic wrote:
> Alain Bench <[EMAIL PROTECTED]> writes:
>> with --timestamping: Each HEAD and each possible GET uses a new
>> connection.
> I think the difference is that Wget closes the connection when it
> decides not to read the request
Herold Heiko <[EMAIL PROTECTED]> writes:
>> From: Hrvoje Niksic [mailto:[EMAIL PROTECTED]
>
>> With the HEAD method you never know when you'll stumble upon a CGI
>> that doesn't understand it and that will send the body anyway. But
>> maybe it would actually be a better idea to read (and discard)
> From: Hrvoje Niksic [mailto:[EMAIL PROTECTED]
> With the HEAD method you never know when you'll stumble upon a CGI
> that doesn't understand it and that will send the body anyway. But
> maybe it would actually be a better idea to read (and discard) the
> body than to close the connection and re
On Tue, 11 Nov 2003, Hrvoje Niksic wrote:
> I think the difference is that Wget closes the connection when it decides
> not to read the request body. For example, it closes on redirections
> because it (intentionally) ignores the body.
Another approach could be to read and just ignore the body o
Alain Bench <[EMAIL PROTECTED]> writes:
> Hello Hrvoje,
>
> On Friday, November 7, 2003 at 11:50:53 PM +0100, Hrvoje Niksic wrote:
>
>> Wget uses the `Keep-Alive' request header to request persistent
>> connections, and understands both the HTTP/1.0 `Keep-Alive' and the
>> HTTP/1.1 `Connection: k
Hello Hrvoje,
On Friday, November 7, 2003 at 11:50:53 PM +0100, Hrvoje Niksic wrote:
> Wget uses the `Keep-Alive' request header to request persistent
> connections, and understands both the HTTP/1.0 `Keep-Alive' and the
> HTTP/1.1 `Connection: keep-alive' response header.
This doesn't seem
Daniel Stenberg <[EMAIL PROTECTED]> writes:
> On Fri, 7 Nov 2003, Hrvoje Niksic wrote:
>
>> Persistent connections were available prior to HTTP/1.1, although they were
>> not universally implemented. Wget uses the `Keep-Alive' request header to
>> request persistent connections, and understands b
On Fri, 7 Nov 2003, Hrvoje Niksic wrote:
> Persistent connections were available prior to HTTP/1.1, although they were
> not universally implemented. Wget uses the `Keep-Alive' request header to
> request persistent connections, and understands both the HTTP/1.0
> `Keep-Alive' and the HTTP/1.1 `C
Laura Worthington <[EMAIL PROTECTED]> writes:
> When I have been testing with wget, wget requests a keep alive
> connection, but the responses it receives say "connection close".
>
> So, it does exactly this...it creates a socket, closes it, reopens
> it with the next URL
`Connection: close'
Laura Worthington <[EMAIL PROTECTED]> writes:
> I am confused as to how wget supports keep alive. I am using 1.8.2.
> Persistent connections are part of HTTP 1.1, but wget is using HTTP
> 1.0.
Persistent connections were available prior to HTTP/1.1, although they
were not universally implemented
I am confused as to how wget supports keep alive. I am using 1.8.2.
Persistent connections are part of HTTP 1.1, but wget is using HTTP 1.0.
16 matches
Mail list logo