Broken pipe while sending request to upstream

[Claudio]

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-100000@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?

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?

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?

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,242919,242937#msg-242937