autoindex module error handling
mdounin at mdounin.ru
Tue Dec 15 01:53:57 UTC 2015
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
> 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
> 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.
More information about the nginx-devel