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

[Maxim Dounin]

Hello!

On Mon, Sep 10, 2012 at 11:22:46AM -0700, agentzh wrote:

[...]

> > Note: you can't be sure that eof with u->headers_in.content_length_n ==
> > -1 is ok.  E.g. with chunked encoding used it's certainly not
> > unless u->length == 0 as well.
> >
> 
> Yes, I was ware of this hole. Just could not think of a solution for
> this. Any suggestion?
> 
> > While content_length_n check is already used in cache and store
> > cases in ngx_http_upstream_process_request(), we might want to get
> > rid of it instead of reintroducing it in various other places.
> >
> 
> Can I ask how will you get rid of this? Any plans in your head?

As of now, probably correct way to handle it is to use u->length 
== -1 to test if eof is ok (and p->length for a buffered case).  
Not sure if we want some separate flag for this.

[...]

> > Additionally, I think major problem here isn't
> > subrequest-in-memory special case, but sending buf with "last"
> > set, which in some situations may result in truncated response
> > being considered full by a downstream.
> >
> 
> But unfortunately, in the context of subrequests, the "last_buf" flag
> is already never set anyway. So we cannot use this flag as an
> indicator for data truncation errors anyway.

For subrequests in general there is last_in_chain flag.

Maxim Dounin