You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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: thesetests 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.
The text was updated successfully, but these errors were encountered:
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 targeturl_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 byAsset.resolve_url_path
.There is an xfailing test in
test_assets.py
that exercises this: these tests demonstrate thatTEST.TXT
gets installed toTEST.txt
. This xfailing test shows thatresolve_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
andtext.TXT
. Currently, Lektor will install both to the same place, with one overwriting the other. Which one wins is, I think, indeterminate.The text was updated successfully, but these errors were encountered: