Hello! On Wed, Sep 18, 2013 at 02:52:39AM -0400, Claudio wrote:
> Hi Maxim. > > Maxim Dounin Wrote: > ------------------------------------------------------- > > As long as a connection is closed before nginx is able to get a > > response - it looks like a problem in your backend. Normally such > > connections need lingering close to make sure a client has a chance > > to read a response. > > Thanks for your prompt response! > > I read an illustrative description about the lingering close here > (https://mail-archives.apache.org/mod_mbox/httpd-dev/199701.mbox/%3cpine.bsf.3.95.970121215226.12598n-100...@alive.ampr.ab.ca%3E) > and now better understand the problem per se. > > What I'm not getting straight is why nginx does not see the response > (assuming it really was sent off by the server). Does nginx try to read data > from the connection while sending or when an error occurs during send? > (Sorry for those dumb questions, but obviously I don't have the slightest > idea how nginx works...) > > According to jetty's documentation, "Jetty attempts to gently close all > TCP/IP connections with proper half close semantics, so a linger timeout > should not be required and thus the default is -1." Would this actually > enable nginx to see the response from the server? Or is it really necessary > to fully read the body before sending a response, as indicated by this > (http://kudzia.eu/b/2012/01/switching-from-apache2-to-nginx-as-reverse-proxy/) > post I found? While sending a request nginx monitors a connection to see if there are any data available from an upstream (using an event method configured), and if they are - it reads the data (and handles as a normal http response). It doesn't try to read anything if it got a write error though, and an error will be reported if a backend closes the connection before nginx was able to see there are data available for reading. Playing with settings like sendfile, sendfile_max_chunk, as well as tcp buffers configured in your OS might be helpful if your backend closes connection to early. The idea is to make sure nginx won't be blocked for a long time in sendfile or so, and will be able to detect data available for reading before an error occurs during writing. > I don't know for sure about the client, but nginx is talking via HTTP/1.1 to > the web app. Is it possible to enable the Expect: 100-continue method for > this connection so that nginx sees the early response? No, "Expect: 100-continue" isn't something nginx is able to use while talking to backends. > Alternatively, is it possible to work around this problem? Could I define > some rules to the extent that say, if it is a POST request to that specific > location _without_ an "Authorization" header present, strip the request > body, set the content-length to 0 and then forward this request? You can, but I would rather recommend digging deeper in what goes on and fixing the root cause. -- Maxim Dounin http://nginx.org/en/donation.html _______________________________________________ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
