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

request that StaticRoute has the option to follow symlinks #1299

Closed
samuelcolvin opened this issue Oct 10, 2016 · 9 comments
Closed

request that StaticRoute has the option to follow symlinks #1299

samuelcolvin opened this issue Oct 10, 2016 · 9 comments
Labels

Comments

@samuelcolvin
Copy link
Member

samuelcolvin commented Oct 10, 2016

Currently .resolve(), relative_to() here causes ValueError to be raised if the path is a symlink to a file outsite the directory and 404 is returned.

Would be good if there was a a way to get StaticRoute follow symlinks, obviously default to false.

@asvetlov
Copy link
Member

You are asking for breaking security sandbox :)
But I'm ok with it unless the requested behavior is off by default.

@samuelcolvin
Copy link
Member Author

Yes, I think it would be ok if it's off by default. Same as apache and nginx.

@asvetlov
Copy link
Member

PR is welcome :)

@samuelcolvin
Copy link
Member Author

samuelcolvin commented Oct 11, 2016

will do.

A few of related extensions to StaticRoute which I would suggest:

  • /path/to/dir serves path/to/dir/index.html if it exists
  • /path/to/file serves path/to/file.html if it exists - this is slightly less standard.
  • /path/to/file serves /path/to/file as content-type: text/html if file starts with <!DOCTYPE - not a convertion but would be useful where there's no easy way to set file metadata like content type. Update: This is perhaps a less good idea as it would mean opening every file without an extension twice: once to check first line, once for sendfile. Also "clean urls" can be accomplished with the above options.

Example here of the first two.

I can do on the same PR, or a new PR or create a new issue to discuss?

@asvetlov
Copy link
Member

index.html should be optional -- now we display a directory index if show_index=True.
file->file.html convention looks harmless but should be optional too.
The third option is really strange.

Anyway, please add these extensions in separate PR.

@samuelcolvin
Copy link
Member Author

Will do, third option is available with S3 if you set the content-type metadata on the file which is why I suggested it.

Will do PRs when I have a chance.

@asvetlov
Copy link
Member

File system has no place for metadata.
Let's don't invite semi-working strategy for this.
<!DOCTYPE is available for html pages only, it's not hard to name a file like fname.html and file type will be detected by file extension.
For other resources (images, js/css files etc) content type should be autocalculated by mimetypes.guess_type anyway and FileSender does this call.

@asvetlov
Copy link
Member

Fixed by #1327

@lock
Copy link

lock bot commented Oct 29, 2019

This thread has been automatically locked since there has not been
any recent activity after it was closed. Please open a new issue for
related bugs.

If you feel like there's important points made in this discussion,
please include those exceprts into that new issue.

@lock lock bot added the outdated label Oct 29, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Oct 29, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants