CODEWITHSUNDEEP
httphttpwebrequestbrowserhttp-post
Kvisle
Kvisle

Reputation: 708

Browsers idling before they send the POST-body

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.

  1. Client connects to webserver with HTTP.
  2. Client sends the headers of an ordinary POST-request (not the body)
  3. Five seconds pass. The cache server passes the request to its backend, because it took too long to complete the request.
  4. The cache server replies to the client, with an error message - indicating that the request was bad.
  5. 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.

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.

Upvotes: 1

Views: 125

Answers (1)

EricLaw
EricLaw

Reputation: 57075

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.

Upvotes: 2

Related Questions