Charles-François Natali added the comment:
According to http://tools.ietf.org/html/rfc2616#section-8.1,
persistent connections are default in HTTP 1.1.
However, here's what's said about the persistence negotiation:
"""
An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
maintain a persistent connection unless a Connection header including
the connection-token "close" was sent in the request. If the server
chooses to close the connection immediately after sending the
response, it SHOULD send a Connection header including the
connection-token close.
An HTTP/1.1 client MAY expect a connection to remain open, but would
decide to keep it open based on whether the response from a server
contains a Connection header with the connection-token close. In case
the client does not want to maintain a connection for more than that
request, it SHOULD send a Connection header including the
connection-token close.
If either the client or the server sends the close token in the
Connection header, that request becomes the last one for the
connection.
"""
And if you have a look at the strace output (or a tcpdump capture),
you see that httpserver indeeds sends a "Connection: close" header,
which wget ignores:
"""
select(6, [5], NULL, NULL, {900, 0}) = 1 (in [5], left {900, 0})
recvfrom(5, "Connection: close\r\n", 390, MSG_PEEK, NULL, NULL) = 19
read(5, "Connection: close\r\n", 19) = 19
select(6, [5], NULL, NULL, {900, 0}) = 1 (in [5], left {900, 0})
recvfrom(5, "\r\n", 371, MSG_PEEK, NULL, NULL) = 2
read(5, "\r\n", 2) = 2
select(6, [5], NULL, NULL, {0, 1}) = 0 (Timeout)
select(6, NULL, [5], NULL, {900, 0}) = 1 (out [5], left {900, 0})
write(5, "GET /FOUND-8154 HTTP/1.1\r\nUser-A"..., 124) = 124
select(6, [5], NULL, NULL, {900, 0}) = 1 (in [5], left {900, 0})
recvfrom(5, "<head>\n<title>Error response</ti"..., 511, MSG_PEEK,
NULL, NULL) = 190
stat("FOUND-8154", 0x7fffcc530d60) = -1 ENOENT (No such file or directory)
open("FOUND-8154", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 7
clock_gettime(CLOCK_MONOTONIC, {130079, 24215187}) = 0
select(6, [5], NULL, NULL, {900, 0}) = 1 (in [5], left {900, 0})
read(5, "<head>\n<title>Error response</ti"..., 8192) = 190
clock_gettime(CLOCK_MONOTONIC, {130079, 24258187}) = 0
fstat(7, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x2b0004bbc000
write(7, "<head>\n<title>Error response</ti"..., 190) = 190
write(4, "\n 0K "..., 777) = 777
select(6, [5], NULL, NULL, {900, 0}) = 1 (in [5], left {900, 0})
read(5, 0x1becc8f0, 8192) = -1 ECONNRESET (Connection
reset by peer)
close(5) = 0
"""
So it really looks like a wget bug.
I'd suggest closing as invalid, and reporting this to wget developers.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue15991>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
