Inline ...
Hi Joakim,
You have not answered my question:
> Given the choice between two equally valid MIME types, which should be preferred?
The one that doesn't break existing installations.
You also have not presented a counterargument to my answer. Why not?
We don't want to break existing installations.
On Wed, Aug 14, 2024 at 1:34 PM Joakim Erdfelt <joakim.erdfelt@xxxxxxxxx> wrote:
> We don't have parity with apache httpd, never had.
I never claimed you did or should. I only presented the httpd example
to support my answer (to which you have not presented a
counterargument).
We don't want to break existing installations.
> And even small changes made to our mime.properties for existing entries has historically been met with surprise from folks that rely on the existing mappings. (and yes, we have people relying on otf belonging to open document)
I do not doubt there are people relying on the existing mapping. The
question is not whether or not there are people relying on the
existing mapping. The question is which use case is more prevalent on
the Web platform in 2024.
Existing installations again, we don't want to break them.
> A better solution, instead of changing an existing mapping, is to allow configuring the `org.eclipse.jetty.http.MimeTypes` object using the apache httpd's `mime.types` file (which has a very liberal license to encourage reuse), for those folks (like yourself) that want apache httpd parity.
I suggest you stop making assumptions about what I want. I do not
specifically want httpd parity. I do want Jetty to support (by
default) the most prevalent use cases of the Web platform in 2024.
This suggestion is a solution that will fit with not breaking people, and allowing folks like yourself to have a behavior that you seem to want (apache httpd parity).
The real world for the web has all kinds of odd cases that people feel are normal and justified.
When we dropped `;charset=utf-8` from the `Content-Type: application/json` we had broken thousands of installations and got an earful. (we were just following the json spec, RFC8259 and RFC7159)
That change was made for exactly the same reasoning you are providing ... "the most prevalent use cases of the Web platform in 2024", yet we broke people.
Hence, we don't want to break them again.
> Historical note: The otf extension was added as part of a series of commits to Jetty 6.1.8 to add all of the OpenDocument formats, due to issue JETTY-491 around Jan 3, 2008.
In 2008, OpenType font embedding on web pages was uncommon, so this
decision makes sense historically. But in 2024, when the font
embedding use case for the Web platform is common enough to be
documented at https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face
and other sources (while the OpenDocument use case is not documented
at https://developer.mozilla.org), wouldn't it make more sense to
prefer the font embedding use case?
This extension is very much still in use in todays real world.
Personally, I think that anyone relying on mimetype defaults from a server is just asking for problems in the future. (we've seen this countless times)
If you have a requirement, define that requirement in your own installation and configuration.
- Joakim
