Add auto Option to autoindex module

[Valentin V. Bartenev]

On Wednesday 30 November 2016 10:00:22 Aaron U'Ren wrote:
> Valentin-
> 
> Thanks for the response. I had a couple of questions regarding your
> statements...
> 
> This should be implemented by adding support for variables in the directive.
> 
> 
> I take it that you mean this to be implemented by something like:
> 
> > set $autoindex_type "html"
> >
> > if ($http_accept ~* json) {
> >     set $autoindex_type "json";
> > }
> >
> > location ... {
> >     autoindex_format $autoindex_type;
> >     ...
> > }
> 

It's better to use the "map" directive:

 map $http_accept $autoindex_type {
     default  html;
     ~json    json;
     ...
 }



> 
> Making autoindex_format accept a variable would be another way to
> accomplish the functionality that I need, but I would argue that it puts a
> stronger burden on the configuration to make the autoindex module comply
> with the user agent's "Accept" header than should be necessary. It seems to
> me, that the default operation of the autoindex module should be to supply
> the index listing in a format that the user's agent can accept, and then
> allow the server administrator to override that functionality through
> configuration if they have a need. To my understanding that is the way the
> Accept header usually works.

XML and JSON formats are mostly needed for internal (the xslt module
in nginx) or external (the xhr requests from browsers) processing.

In case of the xslt module, the output after translation can be
different from XML.


> 
> Please check specification for the Accept header.  It provides much
> richer semantics
> > than what you test.
> 
> 
> I see what you're saying in regards to my limited tests. I was coding for
> my use case instead of everything that the Accept header can contain. I can
> submit a patch that more fully parses the Accept header by breaking it
> apart on commas and matching whatever type the autoindex module can provide
> starting with first with the most specific and moving my way back. Also, I
> should return a 406 response in the event that I'm not able to match
> instead of falling through to HTML. Would that cover everything additional
> that you would want to see?

There are not only commas in the "Accept" header need to be processed.

There are also relative weights and type-ranges.  Proper processing of
the "Accept" header is quite complicated task, and you're the first in
my memory who ever asked about such functionality for many years.

Other users may have different idea about how to handle the "Accept"
header, or may want to check some other request parameters.

So accepting variables here look like a much better and more flexible
solution.


> 
> Also, I wanted to check with you, if I do the work to expand my testing of
> the Accept header would you be willing to accept the patch? Or would you be
> unwilling to merge a patch like this because the only functionality you're
> interested in adding is the support for variables in the autoindex_format
> directive?
> 

The patch won't be accented as it solves your specific use-case, and it will
introduce a lot of new complicated code for proper handling of the "Accept"
header.

  wbr, Valentin V. Bartenev