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

Buglet with lowercasing of asset file extensions #1111

Closed
dairiki opened this issue Mar 1, 2023 · 0 comments · Fixed by #1147
Closed

Buglet with lowercasing of asset file extensions #1111

dairiki opened this issue Mar 1, 2023 · 0 comments · Fixed by #1147
Labels

Comments

@dairiki
Copy link
Contributor

dairiki commented Mar 1, 2023

This is not a real important bug, but I'm writing this down for posterity. There's an xfail-marked test in the test suite for this, and I keep forgetting the details about it, then spending time sussing it out. Here are the details:

As things currently stand, when Lektor installs assets (by copying) to the output directory, if (and only if) the filename extension of the asset matches one of the known extensions in config["ATTACHMENT_TYPES"], the extension is lowercased when generating the output filename (i.e. the target url_path.)

However, Asset.resolve_url when looking up an asset by its URL, does not account for this (possible) mangling of the file extension. I.e. an asset that gets installed to /Asset.txt may have come from a source file named any of /Asset.txt, /Asset.TXT, /Asset.tXt, ... — currently only the first of those will be found by Asset.resolve_url_path.

There is an xfailing test in test_assets.py that exercises this: these tests demonstrate that TEST.TXT gets installed to TEST.txt. This xfailing test shows that resolve_url_path doesn't find it.

Questions

Why is Lektor mucking with the asset extensions at all?

I understand that many web servers may be set up to send a Content-Type base of the file extension and that those web servers may possibly be confused by, e.g., an upper-cased extension. But that's not really our bailiwick. If the user wants an attachment with a specifically cased extension, let him create one.

For the sake of matching attachments against our config["ATTACHMENT_TYPES"], we can do that in a case-insensitive manner.

If we do really want to lowercase some file extensions (why not all of them?), then what do we do about the name conflicts that can arise?

E.g. suppose there are two assets named text.txt and text.TXT. Currently, Lektor will install both to the same place, with one overwriting the other. Which one wins is, I think, indeterminate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant