I have a HTTP client that sets the Connection header to the following value when I make a request:
Connection: close
However when the server sends a response, it is setting the header to Keep-Alive:
Connection: Keep-Alive
This seems intuitively wrong to me, and I am wondering how the client should handle such a response from the server? Also why would a server respond with Keep-Alive, when the client has asked for the connection to be closed, is this valid?
According to the HTTP RFC:
"HTTP/1.1 defines the "close" connection option for the sender to signal that the connection will be closed after completion of the response. For example,
Connection: close
in either the request or the response header fields indicates that the connection SHOULD NOT be considered `persistent' (section 8.1) after the current request/response is complete."
That's fine. You are telling the server you don't support persistent connections and it's telling you it does. Either party is completely valid in closing the connection - it's more of a message about what both supports rather then a YOU MUST CLOSE THIS CONNECTION command.
The client says I will close the connection when the current request/response is finished,or in other words , said you don't support persisten connections. That is, it doesn't tell the server to close the connection. The server replies that it supports persistent connections(keep-alive).
As you've told the server that you don't support persistent connection, you should close the connection when you've read the response.
Related
I have two questions on HTTP Connection close:
If a client sends a HTTP request with Connection: close to HTTP Server, Is it the HTTP Server or client responsibility to send TCP FIN after response is received by client?
If a client sends a bad formatted HTTP request, and server sends a 400 BAD REQUEST, is it best practice to close the connection by server (even though the HTTP request has connection: keep-alive) or is it good practice to keep the connection still active?
Thanks in advance for answering my queries?
When the server receives a 400 Bad Request, it is going to send the response with the keep-alive header because if the client feels like sending another request, then they can use a pre-existing connection (this connection is shut down within a certain amount of time, it has an expiration date). The Keep-Alive Header is more about not saturating the network with TCP connection demands. You basically say "I am going to talk to you, for 2 minutes, whatever you send me, I'll answer you though this connection"
The server is only an object that receives commands from an user. You ask him, he does or not. The TCP FIN is something you send to the server to shut down the connection, but you choose when you don't want to communicate with him anymore. The client transmits the first FIN, and receives an ACK to ensure that the server got it. Then the server launches its own FIN, and waits for the ACK. If everything is okay, you and your server are no longer friends.
I noted that fiddler sends "connection:close" header when the client sends a CONNECT request to initiate secure connection along with the "200 connection established" message.
CONNECT request to a forward HTTP proxy over an SSL connection?
As explained in above question, the connection should be kept-alive between the client and the proxy so that the client can subsequently sent the actual request.
Why does fiddler sends the close header? wouldn't the client close the connection because of the header instead?.
Any Connection header in the successful response to the CONNECT request does not make any sense and gets ignored. CONNECT will establish a tunnel, which only ends with the end of the TCP connection. But a Connection header would make sense with an unsuccessful CONNECT, because with close the client would need to start a new TCP connection and with keep-alive (implicit with HTTP/1.1 response) it can reuse it with another request.
Connection: Close means that the connection will be closed after the request completes. Since the request in this scenario only completes when the HTTPS connection is closed, this is exactly the behavior you want for this sort of request.
Arguably, using Connection: keep-alive on a CONNECT request is invalid, since there's no legal way for the connection to be kept-alive after the tunnel is closed.
Background: I am trying to get ApacheBench working on my custom server. I tried issuing ab -n 1 -c 1 http://localhost:1337/index.html and I sniffing the connection (with wireshark) I see wayyy more than one request is sent.
Example Request:
GET /index.html HTTP/1.0
Host: localhost:1337
User-Agent: ApacheBench/2.3
Accept: */*
(repeats more times than I care to count)
I assumed as RFC 1945 says "Except for experimental applications, current practice requires that the connection be established by the client prior to each request and closed by the server after sending the response." This works with ApacheBench when I request one page. However, if I up the number of requests to 10, I get "Connection reset by peer." This makes sense considering that I closed the connection.
I tried the same procedure with Google, however, and it works fine there for both cases. So, how am I supposed to know when to close the connection for HTTP 1.0?
In HTTP 0.9, the server always closes the connection after sending the response. The client must close its end of the connection after receiving the response.
In HTTP 1.0, the server always closes the connection after sending the response UNLESS the client sent a Connection: keep-alive request header and the server sent a Connection: keep-alive response header. If no such response header exists, the client must close its end of the connection after receiving the response.
In HTTP 1.1, the server does not close the connection after sending the response UNLESS the client sent a Connection: close request header, or the server sent a Connection: close response header. If such a response header exists, the client must close its end of the connection after receiving the response.
By default Connection Header is set to Keep-Alive in browers, to make it possible to keep connection open for further requests from browser.
When I make Connection header to close, what may be the difference ?
Will that affect any performance issue ?
(one addition: I am setting header from xmlhttprequest)
When you make requests with "Connection: keep-alive" the subsequent request to the server will use the same TCP connection. This is called HTTP persistent connection. This helps in reducing CPU load on the server side and improves latency/response time.
If a request is made with "Connection: close" this indicates that once the request has been made the server needs to close the connection. And so for each request a new TCP connection will be established.
By default HTTP 1.1 client/server uses keep-alive whereas HTTP 1.0 client/server doesn't support keep-alive by default.
It affects performance, because most expensive resources create a socket between two machines. So the client needs to establish a new connection in every request.
this article has graphically demonstrated what would happen in such a when the connection header is set to closed and also keep-alive.
It helped me understand it and I hope it helps you too.
The Benefits of Connection Keep Alive
In http transaction for request and response which scenario is occurred ?
client (web browser) open connection and send it's request and connection open (keep alive) until server accept and answer then close connection ?
client (web browser) open connection and send it's request then connection is closed and server accept and answer and reconnect and send response ?
in http1.0 and http1.1 this scenario is different ?
A server can't directly reconnect to a client. Hence, your scenario #2 is unlikely.
In other words, in the WEB world, "transactions" between a Client Browser and a WEB Server is always "Client Browser Initiated".
Of course, if we are talking about server-to-server communication over HTTP, it is a different story: you can make up your own rules here, provided you control at least one server ;-)
As for the difference between HTTP 1.0 and HTTTP 1.1, I don't know enough.
In both 1.0 and 1,1 connection is kept open until response is sent. Keep alive refers to what happens afterwards.
In HTTP 1.0 server closes the connection after sending the response. Unless client sends and server understands keep-alive header (which was not a part of HTTP 1.0 standard)
In HTTP 1.1 connection is kept open after the response unless client sends Connection: close header.
Details
The scenario is:
The client (browser) opens a connection to the web server and sends HTTP request
The server receives the request and sends back the response to the client (browser)
If keep alive is enabled, the connection will not be closed until the keep alive timeout expires. The idea of keep alive is to use the same TCP connect to send/receive multiple requests/responses.
Persistent connection / Keep alive was officially introduced in the HTTP 1.1 specification. keep-alive was not officially documented in the specification of HTTP 1.0, however, some implementation of HTTP 1.0 supported keep alive connections.
regarding scenario 2: The server never initiate connections with browsers, the browser initiate connections with the server and the server uses the same connection to send back responses.