[issue15991] BaseHTTPServer with ThreadingMixIn serving wrong data sometimes

Wed Oct 10 09:12:07 CEST 2012

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 <report at bugs.python.org>
<http://bugs.python.org/issue15991>
_______________________________________