This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author neologix
Recipients catalin.iacob, neologix, pitrou, theamk, thomaslee
Date 2012-10-10.07:12:06
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAH_1eM0CLYg+M1Ne+OJ-auA0sZRoPZ9amM1HrdBNxHP0TSTasA@mail.gmail.com>
In-reply-to <CAH_1eM2y+8k8TwoCBQB_FdcHr1WFPhfOA8zSUzkJ6K=Z91BvCg@mail.gmail.com>
Content
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.
History
Date User Action Args
2012-10-10 07:12:07neologixsetrecipients: + neologix, pitrou, thomaslee, catalin.iacob, theamk
2012-10-10 07:12:07neologixlinkissue15991 messages
2012-10-10 07:12:06neologixcreate