autoindex module error handling

Maxim Dounin mdounin at mdounin.ru
Tue Dec 15 15:48:43 UTC 2015


Hello!

On Tue, Dec 15, 2015 at 09:11:19AM -0600, Joel Cunningham wrote:

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

HTML emails aren't welcomed in technical mailing lists in general, 
and in this one in particular.  The message you've sent was HTML 
and it also contained an empty text/plain version of the 
message, thus preventing any client which is set to prefer 
text/plain from showing anything.  No idea if iCloud mail client 
can be tuned to behave better.

[...]

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

Sending an empty body is a bad idea, as the client won't know that 
there was an error.

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



More information about the nginx-devel mailing list