Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

net/http: FileServer directory listings are unsorted #11879

Closed
mdempsky opened this issue Jul 27, 2015 · 7 comments

Comments

Projects
None yet
6 participants
@mdempsky
Copy link
Member

commented Jul 27, 2015

FileServer lists files in a directory in the same order returned by os.(*File).Readdir. It would be nice if they were instead sorted alphabetically.

/cc @bradfitz

@bradfitz

This comment has been minimized.

Copy link
Member

commented Jul 27, 2015

I guess the question is how much we buffer by default before resorting to unsorted and streaming the results out. Function of machine's RAM? Arbitrary number, like 64 MB? Unbounded (probably bad)?

@nightlyone

This comment has been minimized.

Copy link
Contributor

commented Jul 28, 2015

Unsorted per default is fine. Sorting "sometimes, when the directory is small enough" sounds strange to me. Having a wrapper or set of wrappers around http.FileServer, that sorts is indeed useful.

@bradfitz

This comment has been minimized.

Copy link
Member

commented Jul 28, 2015

Unsorted per default is fine.

I disagree. I find it incredibly annoying and distracting.

Having a wrapper or set of wrappers around http.FileServer, that sorts is indeed useful.

I'd rather not bloat the API. I'd rather just make it better by default.

@nightlyone

This comment has been minimized.

Copy link
Contributor

commented Jul 29, 2015

The reason I would not do it is that the sorting might by wrong for the user. e.g. I would prefer it to be sorted by mtime for a download.

See https://github.com/mholt/caddy/blob/master/middleware/browse/browse.go how people workaround it right now.

Getting buffering and sorting just to have it sorted wrongly for your use-case sounds like baggage we will regret to me.

Another use case is disabling directory browsing (e.g. for pure asset serving).

So honestly having a more flexible Readdir seems what is needed here as it will benefit all those cases.

@adg

This comment has been minimized.

Copy link
Contributor

commented Jul 30, 2015

"Useful" is not the baseline criterion for inclusion in the standard
library.
(Any feature that anyone would bother suggesting is at least useful.)

There's no way we can build a directory list builder that will satisfy
everyone,
yet such things are trivial to write from scratch
(the current implementation is <20 lines).

I don't see the 'browse' package you link to as a work-around.
That's a new implementation of the directory list handler.
IOW, it's the correct solution to the problem.

On 29 July 2015 at 17:40, Ingo Oeser notifications@github.com wrote:

The reason I would not do it is that the sorting might by wrong for the
user. e.g. I would prefer it to be sorted by mtime for a download.

See https://github.com/mholt/caddy/blob/master/middleware/browse/browse.go
how people workaround it right now.

Getting buffering and sorting just to have it sorted wrongly for your
use-case sounds like baggage we will regret to me.

Another use case is disabling directory browsing (e.g. for pure asset
serving).

So honestly having a more flexible Readdir seems what is needed here as it
will benefit all those cases.


Reply to this email directly or view it on GitHub
#11879 (comment).

@rsc

This comment has been minimized.

Copy link
Contributor

commented Aug 6, 2015

I think it would be fine to use Readdir(-1). Nearly all directories are small, and more importantly the file system content is under the control of the owner of the server. If they don't want the sorting, they can use their own fork of the directory lister. If they have very very large directories, they probably have other issues.

@rsc rsc added this to the Go1.6Early milestone Aug 6, 2015

@gopherbot

This comment has been minimized.

Copy link

commented Sep 1, 2015

CL https://golang.org/cl/14161 mentions this issue.

@bradfitz bradfitz closed this in 25b0017 Sep 1, 2015

@golang golang locked and limited conversation to collaborators Sep 4, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.