mark_c wrote:I was saying that some connections:
1) after the connection has been made,
2) after correctly sending the command "GET / HTTP/1.1\r\nHost: " + myadr + "\r\nConnection: close\r\n\r\n";
they always remain active.
Not with the example above, it won't. The "Connection: close" request header explicitly instructs the server to CLOSE THE CONNECTION after it sends the response. The client is then REQUIRED to close its socket after receiving the response.
mark_c wrote:I thought it was a behavior of the HTTP /1.1 protocol
What you are referring to is know as an HTTP Keep-Alive, and yes, leaving the connection active is the DEFAULT behavior in HTTP 1.1, but the "Connection: close" header overrides that default. If you want the default behavior, simply omit the "Connection" header altogether:
Code: Select all
"GET / HTTP/1.1\r\nHost: " + myadr + "\r\n\r\n"
Or else set it to "keep-alive" instead (which is required in order to use keep-alives in HTTP 1.0, in case you are communicating with an old server that doesn't understand HTTP 1.1):
Code: Select all
"GET / HTTP/1.1\r\nHost: " + myadr + "\r\nConnection: keep-alive\r\n\r\n"
Either way, the response will tell you what to do next.
If the response is HTTP 1.1+ and a "Connection: close" header is NOT present, or if the response is HTTP 1.0 and a "Connection: keep-alive" header IS present, then the connection is persistent, the server is leaving its end of the connection active indicating that client may do the same if it chooses to. Otherwise, the connection is not persistent and the client MUST close its socket.
Read
RFC 2616 Section 8: Connections and
RFC 7230 Section 6: Connection Management for more details.
mark_c wrote:however, this does not happen with all connections but only with some and I don't understand why.
Because you are explicitly asking the server to NOT utilize HTTP keep-alives.
mark_c wrote:So since I open connections using many threads, some never end and always remain active.
Then you are not managing them correctly. You MUST pay attention to the response's "Connection" header and act accordingly.
mark_c wrote:If you try to connect with your browser to the address I have given you and check the status of the connection with the netstat command, you will see that the connection always remains ESTABLISHED, even when you close the tab (thread).
Web browsers always use HTTP keep-alives by default, and most HTTP servers honor keep-alive requests. And web browsers are likely to cache and pool keep-alive connections in case they will be reused in the near future. This makes sense in a web browser scenario, since web pages almost always have multiple resources attached to them (images, multimedia, CSS, etc) that need to be requested individually in order to display the whole page, so keep-alives are useful and desirable for that situation. That is primarily why HTTP keep-alives were invented in the first place.
When I use a web browser (FireFox) to access 1.1.107.47, I see the following requests:
GET / HTTP/1.1
Host: 1.1.107.47
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:74.0) Gecko/20100101 Firefox/74.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Pragma: no-cache
Cache-Control: no-cache
HTTP/1.1 200 OK
Date: Wed, 18 Mar 2020 17:17:43 GMT
Content-Type: text/plain; charset=UTF-8
Content-Length: 69
Connection: Keep-Alive
Keep-Alive: timeout=1800, max=0
GET /favicon.ico HTTP/1.1
Host: 1.1.107.47
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:74.0) Gecko/20100101 Firefox/74.0
Accept: image/webp,*/*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
HTTP/1.1 400 Bad Request
Content-Type: text/plain; charset=UTF-8
Content-Length: 13
Connection: close
The 1st request establishes a persistent keep-alive connection, which gets reused for the 2nd request, which is no longer persistent and gets closed.
mark_c wrote:So, to close the connection, I am forced to end the whole process.
It is not your job to manage a web browser connections. But in your own app, it certainly is.
