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