SharedDataMiddleware fails with IsADirectory

[ThiefMaster]

Minimal example:

from flask import Flask
from werkzeug.middleware.shared_data import SharedDataMiddleware

app = Flask(__name__)
app.wsgi_app = SharedDataMiddleware(app.wsgi_app, {'/': ('flask', 'json')})

This only seems to happen when using / with the tuple syntax to reference a package. When using another mapping like /test/ it works fine.

Traceback (most recent call last):
  File "/home/adrian/dev/flask-react-example/.venv/lib/python3.7/site-packages/flask/app.py", line 2328, in __call__
    return self.wsgi_app(environ, start_response)
  File "/home/adrian/dev/flask-react-example/.venv/lib/python3.7/site-packages/werkzeug/middleware/shared_data.py", line 231, in __call__
    f, mtime, file_size = file_loader()
  File "/home/adrian/dev/flask-react-example/.venv/lib/python3.7/site-packages/werkzeug/middleware/shared_data.py", line 132, in <lambda>
    open(filename, "rb"),
IsADirectoryError: [Errno 21] Is a directory: '/home/adrian/dev/flask-react-example/.venv/lib/python3.7/site-packages/flask/json/'

[davidism]

Never mind, this was because I was using ("werkzeug", "debug") and 0.16.x still has the weird module hack.

---

I get a completely different error:

Traceback (most recent call last):
  File "/home/david/Projects/werkzeug/src/werkzeug/serving.py", line 304, in run_wsgi
    execute(self.server.app)
  File "/home/david/Projects/werkzeug/src/werkzeug/serving.py", line 292, in execute
    application_iter = app(environ, start_response)
  File "/home/david/Projects/werkzeug/src/werkzeug/middleware/shared_data.py", line 214, in __call__
    real_filename, file_loader = loader(path[len(search_path) :])
  File "/home/david/Projects/werkzeug/src/werkzeug/middleware/shared_data.py", line 155, in loader
    if not provider.has_resource(path):
  File "/home/david/.virtualenvs/werkzeug/lib/python3.7/site-packages/pkg_resources/__init__.py", line 1404, in has_resource
    return self._has(self._fn(self.module_path, resource_name))
  File "/home/david/.virtualenvs/werkzeug/lib/python3.7/site-packages/pkg_resources/__init__.py", line 1473, in _has
    "Can't perform this operation for unregistered loader type"
NotImplementedError: Can't perform this operation for unregistered loader type

[davidism]

This seems to be expected, and it happens even with a /test/ prefix. You need to point to a file to serve, not the directory itself. For example, for {"/test": ("werkzeug.debug", "shared")}, /test/ fails because it's the directory, not a file, but /test/console.png succeeds.

This should probably return a 404 though. Also, we should be depending on importlib_resources, not pkg_resources, for this.

[ThiefMaster]

That would mean that packages and normal filesystem paths have different locations - the latter do support pointing to a directory and I think it makes perfect sense that you point this middleware to a directory and not a file...

[davidism]

You do point at a directory, but it only serves files. If you go to the top level, you don't get a directory listing, you need to go to an actual file within the directory.

What do you expect to get when visiting /or /test/ in your example?

[ThiefMaster]

OK, after testing it again now I remember the exact issue:

Let's take this example:

from flask import Flask
from werkzeug.middleware.shared_data import SharedDataMiddleware

app = Flask(__name__)
app.wsgi_app = SharedDataMiddleware(app.wsgi_app, {
    '/': ('flask', 'json'),
    '/test/': ('flask', 'json'),
    '/fs/': '/var/empty/',
})

• http://localhost/: IsADirectoryError ❌
• http://localhost/test/: IsADirectoryError ❌
• http://localhost/fs/: 404 ✔️

IMO the first two options should 404 as well to be consistent and not cause an actual exception simply due to a client requesting that URL. 403 would probably be even more suitable for all cases since AFAIK that's what real webserver usually do when you attempt to access a directory that has no directory listing enabled.

[davidism]

Definitely agree they should raise 403/4 instead of 500, thanks for clarifying.

[davidism]

Due to the way the middleware works, we can't return 403 as unhandled paths are intended to pass through to the app, which is what's actually raising the 404. Would be too big a rewrite at this point to support 403.