Hello!

On Sat, May 12, 2012 at 11:10:09PM +0800, agentzh wrote:

> Hello!
>
> On Sat, May 12, 2012 at 8:47 PM, Maxim Dounin <mdounin@mdounin.ru> wrote:
> >
> > I assume you use error_page to redirect 412, right?  You may want
> > to show config (and more complete debug log) to simplify reading.
> >
>
> Nope. There is no error_page directive in my nginx.conf. Here is the
> configure file I'm using:
>
> https://gist.github.com/2667007
>
> The request I'm using is this:
>
> GET / HTTP/1.1
> Host: localhost
> Connection: Close
> If-Unmodified-Since: Thu, 10 May 2012 07:50:47 GMT
>
> The debug log is here (only the first part is given, because the whole
> is too huge):
>
> https://gist.github.com/2666809
>
> >>       2 2012/05/12 20:14:01 [debug] 2770#0: *1 http finalize request:
> >> -4, "/index.html?" a:1, c:2
> >
> > How this happens to be -4 (NGX_DONE)?
>
> In short, the ngx_http_finalize_request(r, NGX_DONE) call was caused
> by recursive calling of ngx_http_core_content_phase due to the
> standard ngx_index module.

Ok, I see this now from full debug log. Thanks for details.

I'll take a closer look at the patch later to make sure it doesn't
break various image filter use cases (likely no, but as I already
said filter finalization is at best fragile) and to see if it's
also possible to avoid response truncation in case of error_page
used after filter finalization.

Maxim Dounin

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel