sanic-org / sanic

Accelerate your web app development | Build fast. Run fast.

Home Page:https://sanic.dev

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Optional file browser

ahopkins opened this issue · comments

Is there an existing issue for this?

  • I have searched the existing issues

Is your feature request related to a problem? Please describe.

No response

Describe the solution you'd like

An auto-generated file browser and index.html fallback.

  1. When enabled, if serving a static dir check for existence of index.html and serve that
  2. If it does not exist, and autoindex is also enabled, show a basic file browser

Additional context

See #893

With the current draft both features are separately opt-in, and sanic somedir --simple enables only the file browser. I see two main use cases:

  1. Webapps that serve their front as index.html i.e. app.static('/', './static/', index_name='index.html')
  2. Simple web server or otherwise browsing files, where file browser is enabled.

In the first case the file browser should still stay disabled by default (you don't want people on the Internet to browse the files of your webapp). In the latter case, I find myself entering folders such as coverage reports, where there is index.html, and would find it helpful to have it opened when possible rather than getting a directory listing first, so in this case both features should be enabled.

  1. I believe that already is the logic. I agree.
  2. That also should be the case. I'm pretty sure I updated the simple server to behave that way.

Or, are you saying that adding autoindex should itself also enable index.html? This was the orig pattern.

We'll have to consider how those arguments on static() are implemented (and their names) but sanic --simple should enable both.

I updated this to work OOTB to enable index.html if autoindex=True. We will document to say that you can explicitly disable this by passing index_name=None.

Note: The implementation changed substantially this week, prior to merging. Most of the discussion in this issue and PR pre-date those changes and are no longer correct nor very relevant.