Http 1.1 uses persistent connections as it has advantage of sending multiple http request using same connection. My concern is with the below guideline:
You must call the Close method to close the stream and release the connection. Failure to do so may cause your application to run out of connections.
Why should I close the stream or connection after receiving response, if same connection is used for multiple httprequest? I am triggering multiple httprequests for same internet resource so why should I close connection/stream/response each time I receive a response?
Related
I know that a http request first makes a 3 way handshake to establish connection. Followed by the request and response.
If a handshake is required for future requests then it is called non persistent connection.
The server can choose to keep the connection alive so that a handshake is not required untill a timeout value (persistent). This is called persistent connection. It saves time required by not requiring the 3 way handshake for each request.
My colleague mentions that http supports both persistent and non persistent. My understanding is that - tcp makes the connection. So persistence is controlled by tcp layer. Am I right?
May be not right. HTTP is higher layer than TCP and HTTP 1.0 will send close() when they finish tranportint some data streams. But in HTTP 1.1, the controller will not send close(), instead, it'll send keepalive/hearbeat to the other side for live. It is controlled by the application layer, in other words, by the HTTP itself.
One way HTTP can support a persistent connection is called Server-Sent-Events.
An alternative to HTTP for persistant connections is WebSocket. WebSocket is a computer communications protocol, providing full-duplex communication channels over a single TCP connection. WebSocket enables streams of messages on top of TCP. WebSocket is distinct from HTTP.
I've been playing around with an http server I'm creating using boost::asio (hence the c++ tag).
With HTTP/1.1 the default is to keep the clients connection open for more than 1 request/response.
My question is:
How long should I keep a client connection open? Should I use a deadline_timer which closes the connection after some arbitrary amount of time?
Or, should I just wait for the underlying socket receive timeout to expire? At which point my receive handler will be invoked with an EOF error prompting me to remove the client connection from my list of connections.
Furthermore, if this is specified in an RFC document, which one?
https://developer.mozilla.org/en-US/docs/Web/API/EventSource
The EventSource interface is web content's interface to server-sent events. An EventSource instance opens a persistent connection to an HTTP server, which sends events in text/event-stream format. The connection remains open until closed by calling EventSource.close().
From what I understand server-sent events require persistent HTTP connection (Connection: keep-alive) so similarly to keeping the connection alive like in case of web sockets.
If the connection is persistent, why server-sent events are unidirectional? Web socket connections are persistent as well.
In this case, what happens if I send a request to my HTTP service and I have persistent connection opened due to EventSource. Will it re-use HTTP connection opened by EventSource or open a new connection?
If it re-uses the connection opened by EventSource how is it considered unidirectional?
Might be trivial, but I had to ask because it is not clear. Because nothing mentions what happens to subsequent HTTP requests when there's existing connection opened by EventSource.
For example, it seems possible to me to implement centralized chat app using SSE:
User 1 sends message to User 2(by sending it to HTTP server). Server sends event to user 2 with a new message, user 2 sends another request to HTTP server with message for User 1, server sends event to user 1.
How is that not considered bi-directional?
Related:
What's the behavioral difference between HTTP Stay-Alive and Websockets?
SSE is unidirectional because when you open a SSE connection, only the server can send data to the client (browser, etc.). The client cannot send any data. SSE is a bit older than WebSockets, hence may be the difference between the unidirectional and bi-directional support between these two technos.
In your use-case, if you open a SSE connection (which is an HTTP connection), only the server will be able to send data. If you wish to send a request to your HTTP service, you will need to open a new "classical" HTTP connection. You will see your browser opening two HTTP connections: 1 for the SSE connection and 1 for the classical HTTP request (short live).
You can implement a chat with SSE. You can have a SSE connection (hence HTTP) to let the user receives the messages from the server. And you can use POST HTTP requests to enable the user to send his/her messages.
Note that most of the browsers can open around 6 HTTP/1.x connections to the same host. So, if you use 1 SSE connection, it will remain potentially 5 HTTP/1.x connections. This is only true with HTTP/1.x. With HTTP 2.x, the connections to the same host are multiplexed: so, in theory, you can send as many HTTP requests at the same time as you wish or you can open as many SSE connections as you wish and thus, by passing the limitation of the 6 connections.
You can have a look at this article (https://streamdata.io/blog/push-sse-vs-websockets/) and this video (https://www.youtube.com/watch?v=NDDp7BiSad4) to get an insight about this technology and whether it could fit your needs. They summarize pros & cons of both SSE and WebSockets.
I need to operate with a SOAP service from Erlang. SOAP implementation is not a subject, I have a problem with HTTP requests at a client side.
I use IBrowse as a HTTP client. This SOAP service uses a specific authorization mechanism, which relates an opened session to a client connection (socket). So, the client should use only one persistent connection to server (socket), and if it try to send a request via another socket (e.g., connection from pool) - authorization will fail.
I use IBrowse in this way:
Spawn connection process to server (ibrowse:spawn_worker_process/1)
Send request to server via spawned process with {max_sessions, 1} and {max_pipeline_size, 0}.
If I understand the docs right, this should use one socket for server connection with disabled pipelining, also, I use Connection: Keep-Alive header and HTTP version explicitly set to 1.0. But my connection is always closed after the response is received.
How can I use IBrowse (or another http-client) the way I described above?
I think you could that with hackney by reusing a connection.
Also gun is quite nice http client, easy to use, keeping connection, but with little less connection control.
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.