Page MenuHomePhabricator

Fix mime type and text encoding in Content-Type HTTP header of LilyPond .ly file output
Closed, ResolvedPublic

Description

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?).

Event Timeline

Ebe123 moved this task from Backlog to In Progress on the MediaWiki-extensions-Score board.
Ebe123 added a subscriber: Ebe123.

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.

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.

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.

While you are at it, you could also use Content-Disposition header to make browser download it, and to name the downloaded file.

Change 434355 had a related patch set uploaded (by Ebe123; owner: Ebe123):
[mediawiki/extensions/Score@master] Make LilyPond source automatically download

https://gerrit.wikimedia.org/r/434355

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.

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.

Change 434355 merged by jenkins-bot:
[mediawiki/extensions/Score@master] Make LilyPond source automatically download

https://gerrit.wikimedia.org/r/434355

Ebe123 triaged this task as Medium priority.May 31 2018, 7:16 PM
Ebe123 added a project: I18n.

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.

Might be a CORS issue, as its a crossdomain link...

Explains why it works on Vagrant. Is there a way to test/fix?

A solution would be to encode all the data in the tag, but that would not be preferable as it would cause huge tags.

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 ?

@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!

Might come back to it at some point; thought it was a trivial change...

Can SRE-swift-storage assist with this or point to the correct project tag ?

TheDJ renamed this task from Add encoding HTML header to LilyPond output to Add Content-Encoding HTTP header to LilyPond file output.Aug 25 2021, 8:32 AM
TheDJ renamed this task from Add Content-Encoding HTTP header to LilyPond file output to Fix mime type and text encoding in Content-Type HTTP header of LilyPond .ly file output.Aug 25 2021, 8:53 AM

MediaWiki-extensions-Score seems correct to me, the content-type should be set when mw writes the file to swift

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.

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

https://gerrit.wikimedia.org/r/715281

@fgiunchedi you know if that patch makes sense ?

@fgiunchedi you know if that patch makes sense ?

Thank you for the patch! I don't know the codebase well enough to judge but intuitively that seems correct to me

Change 715281 merged by jenkins-bot:

[mediawiki/extensions/Score@master] Add content-type header to .ly files in swift

https://gerrit.wikimedia.org/r/715281

TheDJ claimed this task.

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

https://gerrit.wikimedia.org/r/733910

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

https://gerrit.wikimedia.org/r/733911

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

https://gerrit.wikimedia.org/r/733912

Change 733910 merged by jenkins-bot:

[mediawiki/extensions/Score@REL1_37] Add content-type header to .ly files in swift

https://gerrit.wikimedia.org/r/733910

Change 733911 merged by jenkins-bot:

[mediawiki/extensions/Score@REL1_36] Add content-type header to .ly files in swift

https://gerrit.wikimedia.org/r/733911

Change 733912 merged by jenkins-bot:

[mediawiki/extensions/Score@REL1_35] Add content-type header to .ly files in swift

https://gerrit.wikimedia.org/r/733912