If HTTP persistent connection is kept alive and done on the same socket with out dropping a socket or creating a new one for next HTTP connection. Then how come that HTTP is stateless and each HTTP request is on its own when they share the same socket?
Please correct me if my assumptions are wrong.
Thanks.
HTTP is considered stateless because the browser sends all the information the server works (cookies, referrer, etc) with in the HTTP Request Headers.
While there might a database involved which does store state, HTTP is stateless, because it doesn't store anything. And even if the socket is kept open, as long as it doesn't store anything it is still considered stateless.
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.
Users can connect to a server via simple HTTP or Websocket.
What happens to the Websocket session when HTTP Session expires ?
What happens to the HTTP Session when a Websocket session is closed ?
How is it possible to handle user authentication on a server supporting both protocols ?
The RFC 6455 is the document that defines the WebSockets protocol and it does't prescribe any particular way to authenticate a client:
10.5. WebSocket Client Authentication
This protocol doesn't prescribe any particular way that servers can authenticate clients during the WebSocket handshake. The WebSocket server can use any client authentication mechanism available to a generic HTTP server, such as cookies, HTTP authentication, or TLS authentication.
While WebSockets and HTTP can benefit from the same infrastructure (proxies, filtering, authentication), bear in mind that HTTP and WebSockets are different channels of communication and it must be taken into account when designing an authentication mechanism: It is a common misconception that a user who is authenticated in the hosting web application is also authenticated in the socket stream.
It really depends on how your application handles it. As #Myst mentioned, there's usually only one session cookie - the HTTP session. Your server application can close websocket when that session is invalid, or remain it open till the next time a connection is made. Its just the matter of when you are checking sessions that are attached to the websocket: Only when connection is made? or when a message is received?
Generally speaking, there's usually only one session cookie - the HTTP session.
Since WebSocket connections start as HTTP, it is often that the connection authenticates during the HTTP phase and only upgrades to WebSocket once the authentication was successful...
... this depends on the application's design, but it's often the case.
If the session is invalidated after the WebSocket connection was established, the connection will (often) remain open and authenticated for as long as it lasts (since most applications won't repeat the authentication stage after the connection was established).
Let's say you have an HTTP/1.1 proxy sitting between a client and a server. If connections are persistent, there is the possibility that the server will close the connection, but the client will send a request before being notified of the closure. What is the proxy's correct response to this? Does it send an HTTP error to the client or does it try to reconnect to the server?
The proxy should mimic the behaviour of the server, and close the connection - irrespective of whether there is a request in flight.
Automatically reconnecting can create unwanted side effects. The client would assume that it still has the same persistent connection and can, for example, skip authentication headers, cookies etc.
The other alternative - returning a 5xx error would also be wrong, since the client can also make incorrect assumptions about server state.
Mimicking server's behaviour is the safest and consistent option.
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.
I just went through the specification of http 1.1 at http://www.w3.org/Protocols/rfc2616/rfc2616.html and came across a section about connections http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8 that says
" A significant difference between HTTP/1.1 and earlier versions of HTTP is that persistent connections are the default behavior of any HTTP connection. That is, unless otherwise indicated, the client SHOULD assume that the server will maintain a persistent connection, even after error responses from the server.
Persistent connections provide a mechanism by which a client and a server can signal the close of a TCP connection. This signaling takes place using the Connection header field (section 14.10). Once a close has been signaled, the client MUST NOT send any more requests on that connection. "
Then I also went through a section on http state management at https://www.rfc-editor.org/rfc/rfc2965 that says in its section 2 that
"Currently, HTTP servers respond to each client request without relating that request to previous or subsequent requests;"
A section about the need to have persistent connections in the RFC 2616 also said that prior to persistent connections every time a client wished to fetch a url it had to establish a new TCP connection for each and every new request.
Now my question is, if we have persistent connections in http/1.1 then as mentioned above a client does not need to make a new connection for every new request. It can send multiple requests over the same connection. So if the server knows that every subsequent request is coming over the same connection, would it not be obvious that the request is from the same client? And hence would this just not suffice to maintain the state and would this just nit be enough for the server to understand that the request was from the same client ? In this case then why is a separate state management mechanism required at all ?
Basically, yes, it would make sense, but HTTP persistent connections are used to eliminate administrative TCP/IP overhead of connection handling (e.g. connect/disconnect/reconnect, etc.). It is not meant to say anything about the state of the data moving across the connection, which is what you're talking about.
No. For instance, there might an intermediate (such as a proxy or a reverse proxy) in the request path that aggregates requests from multiple TCP connections.
See http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-21.html#intermediaries.