autoindex module error handling
joel.cunningham at me.com
Tue Dec 15 15:11:19 UTC 2015
See responses in-line
On Dec 14, 2015, at 07:54 PM, Maxim Dounin <mdounin at mdounin.ru> wrote:
> 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 checked the archive and see what you mean, are HTML formatted emails not supported or preferred for this mailing list? I simply just sent an email from the iCloud mail client
>> 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.
This makes sense, thanks for explaining the error handling. I’m still fairly new to the NGINX source and this is helpful to know! The only other thought I had was that we could send an empty chunked body when an error is encountered since the auto index module only sends a single chunk. I think the value of this is questionable though since the client learns of the error anyways though the connection closing without a response.
> Maxim Dounin
> nginx-devel mailing list
> nginx-devel at nginx.org
More information about the nginx-devel