[PATCH] Make ngx_http_upstream provide a way to expose errors after sending out the response header
mdounin at mdounin.ru
Tue Sep 11 00:23:36 UTC 2012
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.
More information about the nginx-devel