This LilyPond output shows UTF-8 characters incorrectly in Firefox 57.0.4 because there’s no encoding specified in the content-type HTML header (it says just text/plain—LilyPond files have no own MIME type?).
Description
Description
Details
Details
Related Changes in Gerrit:
Customize query in gerrit
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | TheDJ | T184871 Fix mime type and text encoding in Content-Type HTTP header of LilyPond .ly file output | |||
| Resolved | Reedy | T293756 Run maintenance/UpdateLYFileHeaders.php |
Event Timeline
Comment Actions
No, LilyPond files don't have an official MIME type. On their discussion forums, text/x-lilypond has been brought up. I'm testing on Vagrant, and now it doesn't work on Chrome! (Safari unaffected). In progress.
Comment Actions
Content-Type: text/plain; charset=utf-8 would also be better than now, so that the browser wouldn’t use some one-byte encoding instead of UTF-8. If LilyPond once gets an official MIME type, it can be changed then.
Comment Actions
I'd just use Content-Type: text/x-lilypond; charset=utf-8. A convention good enough for KDE, seems good enough to follow for us.
Comment Actions
While you are at it, you could also use Content-Disposition header to make browser download it, and to name the downloaded file.
Comment Actions
Change 434355 had a related patch set uploaded (by Ebe123; owner: Ebe123):
[mediawiki/extensions/Score@master] Make LilyPond source automatically download
Comment Actions
Would there be a preferable name? There is not necessarily any descriptive naming information in the source or the <score tag. At least with the hash the related files can be easily paired.
Comment Actions
I don’t think we can easily find a more descriptive file name than the current one. Maybe a new attribute can be introduced for the <score> tag, but that, of course, won’t be available for the currently existing scores.
Comment Actions
Change 434355 merged by jenkins-bot:
[mediawiki/extensions/Score@master] Make LilyPond source automatically download
Comment Actions
This is odd; the download attribute does not seem to have an effect (in either Chrome or Safari).
On another note, I do not think it is possible to set the MIME type or any headers through the link.
Comment Actions
A solution would be to encode all the data in the tag, but that would not be preferable as it would cause huge tags.
Comment Actions
Fixing cors or just adding the right mime type, probably requires some work with the SRE-swift-storage ppl / someone with some swift file backend experience.
@brion might you be able to point @Ebe123 in the right direction ?
Comment Actions
@Ebe123: Hi! This task has been assigned to you a while ago. Could you maybe share an update? Do you still plan to work on this task?
If this task is not resolved and only if you do not plan to work on this task anymore: Please consider removing yourself as assignee (via Add Action... → Assign / Claim in the dropdown menu): That would allow others to work on this (in theory), as others won't think that someone is already working on this. Thanks!
Comment Actions
MediaWiki-extensions-Score seems correct to me, the content-type should be set when mw writes the file to swift
Comment Actions
I guess this is a FileBackend detail..
I see a streamMimeFunc here: https://github.com/wikimedia/mediawiki-extensions-Score/blob/master/includes/Score.php#L243
We can likely intercept that in Score, hardcode a value for .ly, before doing the contentTypeFromPath interpretation....
but..note to self. I'd need to find the swift backend class... mime and content-encoding are NOT the same, so not sure if the mime passthrough allows for the character set to be listed, but that's not part of the mime...
Also we'd probably have to clean up the old entries in Swift.
Comment Actions
Change 715281 had a related patch set uploaded (by TheDJ; author: TheDJ):
[mediawiki/extensions/Score@master] Add content-type header to .ly files in swift
Comment Actions
Thank you for the patch! I don't know the codebase well enough to judge but intuitively that seems correct to me
Comment Actions
Change 715281 merged by jenkins-bot:
[mediawiki/extensions/Score@master] Add content-type header to .ly files in swift
Comment Actions
Change 733910 had a related patch set uploaded (by Reedy; author: TheDJ):
[mediawiki/extensions/Score@REL1_37] Add content-type header to .ly files in swift
Comment Actions
Change 733911 had a related patch set uploaded (by Reedy; author: TheDJ):
[mediawiki/extensions/Score@REL1_36] Add content-type header to .ly files in swift
Comment Actions
Change 733912 had a related patch set uploaded (by Reedy; author: TheDJ):
[mediawiki/extensions/Score@REL1_35] Add content-type header to .ly files in swift
Comment Actions
Change 733910 merged by jenkins-bot:
[mediawiki/extensions/Score@REL1_37] Add content-type header to .ly files in swift
Comment Actions
Change 733911 merged by jenkins-bot:
[mediawiki/extensions/Score@REL1_36] Add content-type header to .ly files in swift
Comment Actions
Change 733912 merged by jenkins-bot:
[mediawiki/extensions/Score@REL1_35] Add content-type header to .ly files in swift