Add auto Option to autoindex module

Aaron U'Ren aauren at gmail.com
Wed Nov 30 16:00:22 UTC 2016


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


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.

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?

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?


-Aaron

On Wed, Nov 30, 2016 at 4:23 AM, Valentin V. Bartenev <vbart at nginx.com>
wrote:

> On Tuesday 29 November 2016 21:36:27 Aaron U'Ren wrote:
> > I recently came across the need to have multiple formats returned from
> the
> > autoindex module based on the client. When a human hits the index page I
> > needed it returned in HTML format. However, when an application fetched
> the
> > index page it was much simpler for it to digest and parse JSON or XML.
> With
> > the current autoindex module you could only specify a single format in
> the
> > configuration.
> >
> > It occurred to me that it might sometimes be better to have an option to
> > allow the user agent to choose what format it wanted from the autoindex
> > module rather than it being defined statically by the server's
> > configuration. So I made a small patch that introduces a 5th "auto"
> option
> > in addition to html, json, jsonp, and xml.
>
> This should be implemented by adding support for variables in the
> directive.
>
>
> >
> > With this option enabled the nginx server reads the "Accept" header from
> > the user agent's request and if it is able to satisfy the format it will
> > send the response in that format. Otherwise it will gracefully fall back
> to
> > serving the response in the default html format.
> >
> > Fair warning, my C is pretty rusty and I'm not at all that familiar with
> > the nginx code base, but I was able to put together and successfully test
> > the following patch on my machine.
> >
> > Let me know what you guys think.
> >
> [..]
>
> Please check specification for the Accept header.  It provides much richer
> semantics than what you test.
>
>   wbr, Valentin V. Bartenev
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20161130/87d933a9/attachment.html>


More information about the nginx-devel mailing list