autoindex module error handling

[Maxim Dounin]

Hello!

On Mon, Dec 14, 2015 at 11:23:26PM +0000, Joel Cunningham wrote:

Just a side note: sending html email with an empty text/plain
alternative isn't a best way to ensure the message will be
seen.

>    Hi,
> 
>    I'm seeing an issue with the autoindex module (version 1.9.5) where
>    when an error is encountered while generating the index, NGINX does not
>    send any response back to the client.
> 
>    I ran through the debugging and what I found is that the header is
>    sent, but doesn't actually make it to the socket buffer because in
>    ngx_http_write_filter returns early because size <
>    clcf->postpone_output.  This seemed normal to me.
> 
>    Then during generation of the index, an error is encountered and
>    ngx_http_autoindex_error() is called.  Since r->header_sent is 1,
>    NGX_ERROR is returned and the socket is closed without sending the
>    header or any additional error response
> 
>    Chrome and Firefox end up displaying error pages about "no response" or
>    "the connection was reset" when TCP connection was closed without a
>    response.
> 
>    Should NGINX be doing something better?  Since the response is chunk
>    encoded, I understand the header is already sent, but is there a better
>    way to report errors while generating a chunked response? (although
>    autoindex doesn't seem to actually generate multiple chunks).

As long as the header is sent, it's already too late to do 
anything with the response or otherwise indicate an error to the 
client.  So we have two basic options to handle errors which 
happen after the header is send:

1) generate the response, ignoring/handling errors somehow;

2) terminate the connection.

Depending on a particular error approach (1) may or may not be 
possible.  E.g., SSI module handles cases when subrequests to 
other resources fail.  But if memory allocation fails, likely it 
won't be possible to "handle" it somehow.  The default behaviour 
is (2), as it's always possible.  And that's what happens in this 
particular case.  If you think that (1) is possible for the 
particular error you've seen, and it worth the effort - feel free 
to provide patches.

-- 
Maxim Dounin
http://nginx.org/