<div dir="ltr">Valentin-<div><br></div><div>Thanks for the response. I had a couple of questions regarding your statements...</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">This should be implemented by adding support for variables in the directive.</span></blockquote><div> </div><div>I take it that you mean this to be implemented by something like:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><font face="monospace, monospace" size="1">set $autoindex_type "html"<br><br>if ($http_accept ~* json) {<br>    set $autoindex_type "json";<br>}<br><br>location ... {<br>    autoindex_format $autoindex_type;<br>    ...<br>}</font></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">Please check specification for the Accept header.  It provides much richer </span><span style="font-size:12.8px">semantics than what you test.</span></blockquote><div><br></div><div>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?</div><div><br></div><div>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?</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div><br></div>-Aaron</div></div>
<br><div class="gmail_quote">On Wed, Nov 30, 2016 at 4:23 AM, Valentin V. Bartenev <span dir="ltr"><<a href="mailto:vbart@nginx.com" target="_blank">vbart@nginx.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tuesday 29 November 2016 21:36:27 Aaron U'Ren wrote:<br>
> I recently came across the need to have multiple formats returned from the<br>
> autoindex module based on the client. When a human hits the index page I<br>
> needed it returned in HTML format. However, when an application fetched the<br>
> index page it was much simpler for it to digest and parse JSON or XML. With<br>
> the current autoindex module you could only specify a single format in the<br>
> configuration.<br>
><br>
> It occurred to me that it might sometimes be better to have an option to<br>
> allow the user agent to choose what format it wanted from the autoindex<br>
> module rather than it being defined statically by the server's<br>
> configuration. So I made a small patch that introduces a 5th "auto" option<br>
> in addition to html, json, jsonp, and xml.<br>
<br>
</span>This should be implemented by adding support for variables in the directive.<br>
<span class=""><br>
<br>
><br>
> With this option enabled the nginx server reads the "Accept" header from<br>
> the user agent's request and if it is able to satisfy the format it will<br>
> send the response in that format. Otherwise it will gracefully fall back to<br>
> serving the response in the default html format.<br>
><br>
> Fair warning, my C is pretty rusty and I'm not at all that familiar with<br>
> the nginx code base, but I was able to put together and successfully test<br>
> the following patch on my machine.<br>
><br>
> Let me know what you guys think.<br>
><br>
</span>[..]<br>
<br>
Please check specification for the Accept header.  It provides much richer<br>
semantics than what you test.<br>
<br>
  wbr, Valentin V. Bartenev<br>
<br>
______________________________<wbr>_________________<br>
nginx-devel mailing list<br>
<a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-devel" rel="noreferrer" target="_blank">http://mailman.nginx.org/<wbr>mailman/listinfo/nginx-devel</a><br>
</blockquote></div><br></div>