I'm building a distributed system in which i do some http requests to comunicate. I want the requests to be fault tolerant. The requests has no timeout, should i retry the request after some period if i have no response or the http request is automatically retrying tcp connections? I used the library async http client in java. Thanks
... the http request is automatically retrying tcp connections?
The HTTP request is not a thing which can retry something by itself. A HTTP request is just data. It is up to the application to retry the request if something goes wrong. Some libraries used in applications might offer this, others not. Most don't since it is often not clear if the request should be retried in the first place since it might have unintended side effects if the web application receives the request twice (it might have received the first even though it gave no response).
Related
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.
What exactly is the difference between long polling and http Keep-Alive??
Doesnt http Keep-Alive solve the issue that long-polling solves??
No. They're almost completely unrelated.
HTTP keepalive allows the client to keep a connection open, but idle, to allow it to make future requests a little bit more efficiently. The server cannot send data to a client over a keepalive connection, as no request is active.
Long polling is a mechanism where the server keeps a request (and thus a connection) active, but not sending data, to allow the server to send data to the client when it becomes available -- for instance, when an event occurs.
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.
I have some very interesting behaviour from seemingly random clients on a website. What I see is that random POST-requests to the server result in a bad request to the backend. I've tracked down why the request is bad - but I still don't know WHY this occurs.
Client connects to webserver with HTTP.
Client sends the headers of an ordinary POST-request (not the body)
Five seconds pass. The cache server passes the request to its backend, because it took too long to complete the request.
The cache server replies to the client, with an error message - indicating that the request was bad.
The client sends the POST-body - a few seconds after the reply has been received.
I have no problem accepting that the cache server can be reconfigured to wait longer. My problem is; What can be the reason for clients to wait several seconds between the headers sent, and sending the POST-body? I don't know of any cases where this behavior makes sense.
This is a fairly ordinary Magento eCommerce website, with a setup of Haproxy -> Varnish -> Nginx -> php5-fpm. Varnish is the component that ships the request to Nginx when five seconds of idling has passed.
I have verified with tcpdump/wireshark that the server does not receive the POST-body from the client within the time (before Haproxy as well).
I have verified that this occurs across user agents, and across the kind of requests (Being ordinary login forms, to ajax callbacks)
Does anyone have any clever ideas?
NOTE: I wasn't sure if this was a question for Stack Overflow or Serverfault, but I consider this an HTTP question that requires developer-knowledge.
The server is buggy-- you shouldn't send partial requests from the front-end to the backend. It's possible that the client is waiting for a HTTP/100 Continue response for the server before transmitting the POST body. It's also possible that the client is generating the POST data and that's taken some time for some reason.
Me get a lot of Googlebot requests.
Googlebot requests up to 11 different files via 11 HTTP GET request, all in one single TCP/IP connection.
Are these GET request (all in the same TCP/IP connection) processed via the server in
parallel
or in sequence?
Or is it up the the server?
in this case, how does Nginx handle this?
are these GET request (all in the same
TCP/IP connection) processed via the
server in
parallel or in sequence?
It is processed in sequence. It is called pipelining. Pipelining is part of HTTP/1.1 and it means that the client need not wait for the current request to
complete before sending the next request over a persistent connection. It can send several requests over the same connection without waiting for responses for previous requests. The requests are processed in FIFO manner i.e. The client can send several requests in sequence, and the server is supposed to send a response to each request in the same order the request was received. So if the server you are using in HTTP/1.1 compliant, then it should be handled in sequence.
HTTP pipelining happens sequentially. There is no support for any kind of interleaving in HTTP.
However, with pipelining, a server may know about all of the requests before it's done servicing the last one. In theory, it could do the necessary I/O in parallel.
It doesn't look like nginx will do that, though.