I am using Nginx as a reverse proxy. When sending it an infinite amount of garbage, and the back-end application already responded to the request (for example with some error), Nginx will patiently wait for the client to finish talking before replying.

I'm not sure why Nginx delays the response at all (it's a bidirectional/full duplex connection and it has the response fully buffered), probably some HTTP protocol reason, but what I'm mainly wondering is why the timeout it so high? Why wait 30 seconds for the client to stop blabbering before giving it the response? In what (legitimate) scenario does this happen? I can only think of slowloris or other DoS attacks.

I can imagine the client is still sending headers when the back-end (or Nginx itself) already discovered the IP is not allowed, so you have to let it finish sending headers, but that would be at most a few kilobytes if you have some weirdly large cookie. Even on GPRS, that's about 1-2 seconds. Why set the default to 30 and allow someone to keep a connection open and active for that long, when it knows it's only wasting CPU?

  • Who said anything about waiting for a response? In this scenario the client has already gotten the response! – Michael Hampton Apr 12 at 19:07
  • @MichaelHampton Oh! Even weirder, why would it bother waiting to close the connection? Does the client (such as curl) error typically out if it did not finish sending the request, even if it already has the response? – Luc Apr 12 at 19:22
  • A few very broken clients might do. This scenario generally happens only when you have already sent the response but haven't received all of the data from the client. – Michael Hampton Apr 13 at 0:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.