classification
Title: HTTPServer can't close http client completely
Type: behavior Stage: resolved
Components: Versions: Python 3.8
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: gregory.p.smith, jaswdr, terry.reedy, ueJone
Priority: normal Keywords:

Created on 2021-05-11 10:07 by ueJone, last changed 2021-06-16 13:12 by gregory.p.smith. This issue is now closed.

Files
File name Uploaded Description Edit
Dingtalk_20210511174335.jpg ueJone, 2021-05-11 10:07
tcpPort_20245.pcapng ueJone, 2021-06-16 12:59
Messages (6)
msg393451 - (view) Author: (ueJone) Date: 2021-05-11 10:07
# HTTP Server
from http.server import HTTPServer, SimpleHTTPRequestHandler  
 
port = 80  

httpd = HTTPServer(('', port), SimpleHTTPRequestHandler)
print("Starting simple_httpd on port: " + str(httpd.server_port))  
httpd.serve_forever()

#########################################
HTTP client(192.168.1.8) close the socket when http request is done.But the http server(192.168.1.168) does't send 'TCP_FIN' message.
msg393472 - (view) Author: Jonathan Schweder (jaswdr) * Date: 2021-05-11 20:43
@ueJone according to the (RFC)[https://datatracker.ietf.org/doc/html/rfc6455#section-1.4] the FIN/ACK is not normative, in other words is recommended but not required, I've checked the syscalls of the server, see it below:

```
...
1561 15143 write(2, "127.0.0.1 - - [11/May/2021 20:08"..., 60) = 60$
1562 15143 sendto(4, "HTTP/1.0 200 OK\r\nServer: SimpleH"..., 154, 0, NULL, 0) = 154$
1563 15143 sendto(4, "<!DOCTYPE HTML PUBLIC \"-//W3C//D"..., 728, 0, NULL, 0) = 728$
1564 15143 shutdown(4, SHUT_WR)              = 0$
1565 15143 close(4)                          = 0$
...
```

As you can see, Python is not the one sending or not sending the ACK/FIN codes, this is coming from the underlining OS implementation of the `close()`.

My questions is, which OS are you using/testing this example?
msg393482 - (view) Author: (ueJone) Date: 2021-05-12 01:38
The HTTPServers run on win10 20H2. The HTTP client is a embed device.


The client often fails to connect to the HTTP server when reboot after close socket. Test as follows:

1. The client close socket when HTTP_GET request is done.(Now you can see that HTTPServer not send 'FIN', it means the server not close socket completely)
2. The client reboot and send HTTP_GET request again, but it can't connect to the HTTPServer as shown in the attachment.

In addition, every request is successful if the client not reboot.

I think the problem may be caused by the HTTPServer not closing the previous connection completely.
msg393700 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2021-05-14 22:55
3.8 only gets security fixes.  Please verify issue on a current release.
msg393793 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2021-05-17 08:13
Python is calling close() after the HTTP/1.0 request.  This isn't a bug on the CPython side.
msg395919 - (view) Author: (ueJone) Date: 2021-06-16 12:59
Sorry, I've been busy with other things recently.

I think that the problem is't caused by OS, because the other TCP servers were disconnected normally and TCP client can access to these servers.

My question is how to make the client connect to the server normally every time, instead of why the abnormal disconnect.

The attachment:
   Capture packets of wireshark(HTTPServer listen on port 20245)
History
Date User Action Args
2021-06-16 13:12:34gregory.p.smithsetstatus: open -> closed
resolution: later -> not a bug
2021-06-16 12:59:46ueJonesetstatus: closed -> open
files: + tcpPort_20245.pcapng
resolution: not a bug -> later
messages: + msg395919
2021-05-17 08:13:34gregory.p.smithsetstatus: open -> closed

nosy: + gregory.p.smith
messages: + msg393793

resolution: remind -> not a bug
stage: resolved
2021-05-14 22:55:43terry.reedysetnosy: + terry.reedy
messages: + msg393700
2021-05-12 01:38:35ueJonesetresolution: remind
messages: + msg393482
2021-05-11 20:43:27jaswdrsetnosy: + jaswdr
messages: + msg393472
2021-05-11 10:07:39ueJonecreate