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.
Related
I'm implementing HTTP over TLS proxy server (sni-proxy) that make two socket connection:
Client to ProxyServer
ProxyServer to TargetServer
and transfer data between Client and TargetServer(TargetServer detected using server_name extension in ClientHello)
The problem is that the client doesn't close the connection after the response has been received and the proxy server waits for data to transfer and uses resources when the request has been done.
What is the best practice for implementing this project?
The client behavior is perfectly normal - HTTP keep alive inside the TLS connection or maybe even a Websocket connection. Given that the proxy does transparent forwarding of the encrypted traffic it is not possible to look at the HTTP traffic in order to determine exactly when the connection can be closed. A good approach is therefore to keep the connection open as long as the resources allow this and on resource shortage close the connections which were idle (no traffic) the longest time.
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.
When a server sent a keep-alive header to a client
Does it mean that every requests of this client ip will be benefited?
Does it mean that every requests of this client ip plus session will be benefited?
Put it into a situation.
After I browse a website and the server sent keep-alive to me. I open another browser and go to the same website. Will my second request connect without handshake?
I read the documentation but I could not find out the target. Please help me.
In HTTP 1.0, if both the client and server support keep alive then the connection will be persisted and multiple requests can use the same connection without handshaking each time, benefitting the session by slightly reducing request/response time.
In HTTP 1.1, connections are keep alive by default so this is the expected behaviour.
This happens within the session - another browser window would constitute another session, so there would be no connection sharing and therefore no benefit.
I've observed a HTTP 1.1 Server implementation, which terminates a client connection as soon as it detects a client-side connection shutdown of its outgoing channel (or rather, either before or after sending a proper http response). Is this a conforming HTTP 1.1 implementation?
RFC 2616 Section 8.1.4 seems to suggest this is to be the proper behaviour:
When a client or server wishes to time-out it SHOULD issue a graceful
close on the transport connection. Clients and servers SHOULD both
constantly watch for the other side of the transport close, and
respond to it as appropriate.
...
Servers SHOULD NOT close a connection in the middle of transmitting a response, unless a network or client failure is suspected.
Am I interpreting it right? Is there a more explicit reference about half-closed connection handling in the context of HTTP 1.1?
As far as i know, thats is all we need to know about Half-closed connections.
The server will only close the connection if it detects that the client closed it (it can ben when the server is about to write to the socket) or at the end of the request, if it does not support connection: keep-alive.
The client can disconnect any time, but it should tell the server why is it disconnecting (time_out, request cancel). But it is not very used by those who write sockets components. They just close the socket when they need to force a time_out.
But the client implementation is not the problem. You should worry about server implementation since suffer a lot with those unexpected disconnects.
EDIT
Maybe those links can help you.
Transmission Control Protocol - Functional Specification
TRANSMISSION CONTROL PROTOCOL
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.