autoindex module error handling

[Joel Cunningham]

Maxim,

See responses in-line

Joel
 
On Dec 14, 2015, at 07:54 PM, Maxim Dounin <mdounin at mdounin.ru> wrote:

> 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.

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
 
> 
> 
>> 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.
> 

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
> http://nginx.org/
> 
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel