[PATCH] Make ngx_http_upstream provide a way to expose errors after sending out the response header

Maxim Dounin mdounin at mdounin.ru
Mon Apr 8 22:36:28 UTC 2013


Hello!

On Mon, Apr 08, 2013 at 12:05:31PM -0700, agentzh wrote:

> Hello!
> 
> On Sun, Apr 7, 2013 at 5:23 PM, Maxim Dounin wrote:
> >
> > This looks wrong.
> >
> > The u->length should be used/checked in case of non-buffered processing
> > only, u->pipe->length - in case of buffered.  The patch seems to
> > check both, and this is probably what causes your problems.
> >
> 
> Thanks for the quick comment!
> 
> But the problem is that for HTTP 1.0 responses without a
> Content-Length response header, the end of the body is indicated by
> closing the connection.
> 
> And for HTTP 1.0 responses without Content-Length in non-buffered
> mode, u->length is always -1. Also, for chunked HTTP 1.1 response in
> non-buffered mode, u->length is also always -1. Simply checking
> u->length == -1 for "good eof" for these two cases are not enough
> because for the latter, data truncation cannot be detected at all. And
> that's also why I check p->length == -1 at the same time.
> 
> Do you have any better way to do this?

I think the information that u->length == -1 isn't ok at eof 
should be explicitly exposed by protocol modules (or, rather, 
module - as of now, it's not ok only in case of HTTP/1.1 with 
chunked).

-- 
Maxim Dounin
http://nginx.org/en/donation.html



More information about the nginx-devel mailing list