Closed edwilde closed 11 months ago
I've downloaded a .brf
file from https://covid19.govt.nz/languages-and-resources/alternate-formats/braille/ and run it through some checkers to see what mime type they think it should be, and everything comes back text/plain
, so I agree that seems to be the appropriate mime type. No idea where datatypes.net are getting theirs from.
For context, when you say "adds support", this is adding support for the HTTPRequest::send_file()
method (which is about the only thing which uses HTTP::get_mime_type()
which is what consumes this config) and not much else.
Is this the place (and the only place) you are intending to add support?
Is this the place (and the only place) you are intending to add support?
Ahha...thanks for pointing that out, I will create another couple for File and MimeValidator, which should complete the trifecta 👍
Awesome. Can you please also create a new issue (probably against silverstripe/silverstripe-assets
as the main "file" repo) to track all the related PRs? I'd like to review them all together.
This adds support for the Braille ASCII file format.
This is increasingly requested by clients in the public sector.
Possible caveat: It seems, there is disagreement on what mime type
brf
files should be: datatypes.net says it should beapplication/octet-stream
(ref), but apache says it should be text/plain (ref). In custom configurations we typically add both.In this case I believe the apache decision pre-dates datetypes.net (I only see May 2022 in the wayback machine) and makes more sense given the type of content within the file.
Issue