As I've posted here: https://bugzilla.gnome.org/show_bug.cgi?id=659291 There's no support for the Webp image format? At least it does not work in Nautilus for me. Can this be fixed/added?
See http://cgit.freedesktop.org/xdg/shared-mime-info/tree/HACKING#n31 for how to make requests about adding new formats.
*** Bug 55337 has been marked as a duplicate of this bug. ***
Created attachment 67700 [details] Sample WebP file from webp tools source tree
Comment 1 is still relevant.
WebP is not IANA-registered yet and still under development, so maybe it's better to hold this off for a while.
Using image/x-webp is fine in the meanwhile. But you'll need to include a patch, including a test case, if you want this reviewed. It's not going to move otherwise.
Created attachment 77271 [details] [review] Add image/webp mime-type
'image/webp' is not yet registered by IANA, but it's the mime-type that is already used by apache, python and opera. For more information refer to https://groups.google.com/a/webmproject.org/forum/?fromgroups=#!topic/webp-discuss/Ds94Fxpmdck
This needs to go in. I highly recommend against changing the mime type to image/x-webp as that one is not used anywhere. Patch looks good to me, whats holding it back?
Indeed, it makes no sense to add a MIME type that no one is actually using (i.e. 'image/x-webp'). The MIME type 'image/webp' is the only sensible choice here, especially given that it's the one implemented by others (Chrome, Python, Apache); but Google really should get its act together wrt to registering it with IANA. I do have a comment about the patch, though: The section byte pattern (at offset 8) should only be "WEBP", not "WEBPVP8", according to the latest version of the spec[1]. The VP8 bitstream format is an independent format that is defined in a separate spec[2], and it is conceivable that the WebP format may use a different bitstream format which would needlessly obsolete the patch as currently written. As for why no action has been taken on this bug yet, it may have been because this bug was filed in the wrong component. But this is pure speculation on my part, just because I've previously moved the bug to the correct component. [1]: https://developers.google.com/speed/webp/docs/riff_container [2]: http://tools.ietf.org/html/rfc6386
Another possibility is that no one flipped the NEEDINFO status after the patch was posted.
Created attachment 93495 [details] [review] Add image/webp mime-type (v2)
Comment on attachment 93495 [details] [review] Add image/webp mime-type (v2) Review of attachment 93495 [details] [review]: ----------------------------------------------------------------- ::: freedesktop.org.xml.in @@ +4331,4 @@ > <match type="string" value="\x45\x50\x2A\x00" offset="0"/> > </magic> > </mime-type> > + <mime-type type="image/webp"> Use image/x-webp as the mime-type, and add the "image/webp" mime-type as an alias. We try to have the main mime-type be a registered mime-type, and as image/webp isn't registered, image/x-webp will have to do as the main mime-type. ::: tests/list @@ +47,4 @@ > # Uncompressed TGA > test2.tga image/x-tga > test.tif image/tiff > +test.webp image/webp Ditto.
(In reply to comment #13) > Comment on attachment 93495 [details] [review] [review] > Add image/webp mime-type (v2) > > Review of attachment 93495 [details] [review] [review]: > ----------------------------------------------------------------- > > ::: freedesktop.org.xml.in > @@ +4331,4 @@ > > <match type="string" value="\x45\x50\x2A\x00" offset="0"/> > > </magic> > > </mime-type> > > + <mime-type type="image/webp"> > > Use image/x-webp as the mime-type, and add the "image/webp" mime-type as an > alias. > We try to have the main mime-type be a registered mime-type, and as > image/webp isn't registered, image/x-webp will have to do as the main > mime-type. > > ::: tests/list > @@ +47,4 @@ > > # Uncompressed TGA > > test2.tga image/x-tga > > test.tif image/tiff > > +test.webp image/webp > > Ditto. I extremely, extremely strongly disagree. The fdo mime type database is used as the base for several libs to get a specific mime type (for an extension or file type) and getting a completely meaningless (image/x-webp) mime type is counterproductive and will lead to libs being forced to work around that one specific mime type or not being able to rely on the database for image types. Having image/webp as the base type is necessary to communicate with other apps that *will* expect image/webp, instead of image/x-webp, as the latter is completely unused.
(In reply to comment #14) Note: I obviously meant image/webp in comment #9. image/x-webp is not present anywhere outside of this bug report and it's a disservice to everyone to claim it's a valid type.
(In reply to comment #14) > I extremely, extremely strongly disagree. The fdo mime type database is used > as the base for several libs to get a specific mime type (for an extension > or file type) and getting a completely meaningless (image/x-webp) mime type > is counterproductive and will lead to libs being forced to work around that > one specific mime type or not being able to rely on the database for image > types. That's ridiculous. You already need to look up aliases to match mime-types, this is no different. > Having image/webp as the base type is necessary to communicate with other > apps that *will* expect image/webp, instead of image/x-webp, as the latter > is completely unused. It's an alias. The main mime-type is the registered one (or an "x-" mimetype), the alias is everything else. As per the HACKING file: > * Mime-types used should be IANA registered mime-types when possible > * When old mime-types become registered, the new definition should > include an alias for the old mime-type I'll gladly make this clearer is it isn't already.
(In reply to comment #16) > (In reply to comment #14) > > I extremely, extremely strongly disagree. The fdo mime type database is used > > as the base for several libs to get a specific mime type (for an extension > > or file type) and getting a completely meaningless (image/x-webp) mime type > > is counterproductive and will lead to libs being forced to work around that > > one specific mime type or not being able to rely on the database for image > > types. > > That's ridiculous. You already need to look up aliases to match mime-types, > this is no different. Let me explain the situation. The base mime type is what a library will give you when you ask, "what is the mime type for this file?". If the library gives you image/x-webp, and the app using this library then downstreams this claim (for example, into a web server which will then go into a web browser), the endpoint receives the *wrong* mime type and does not understand it. The bit of the spec you quoted is very clear on the SHOULD - not MUST. This is an acceptable exception on the guideline. By using image/x-webp, you are *creating* a mime type, not disambiguating. Please don't do that.
(In reply to comment #17) > (In reply to comment #16) > > (In reply to comment #14) > > > I extremely, extremely strongly disagree. The fdo mime type database is used > > > as the base for several libs to get a specific mime type (for an extension > > > or file type) and getting a completely meaningless (image/x-webp) mime type > > > is counterproductive and will lead to libs being forced to work around that > > > one specific mime type or not being able to rely on the database for image > > > types. > > > > That's ridiculous. You already need to look up aliases to match mime-types, > > this is no different. > > Let me explain the situation. You can stop with the patronising already. I've been contributing and maintaining this repository for around 10 years, we're not going to change the way we handle mime-types just because you don't like it. > The base mime type is what a library will give you when you ask, "what is > the mime type for this file?". If the library gives you image/x-webp, and > the app using this library then downstreams this claim (for example, into a > web server which will then go into a web browser), the endpoint receives the > *wrong* mime type and does not understand it. The end point being? Something that can't do lookups with the fd.o database? The client should be less dumb in that case, not the web server. And until the mime-type is registered, I don't see why we should be returning a mime-type that doesn't follow specifications. For the client, it's a one-line lookup. > The bit of the spec you quoted is very clear on the SHOULD - not MUST. I wrote that bit of spec. So consider it a MUST. > This > is an acceptable exception on the guideline. By using image/x-webp, you are > *creating* a mime type, not disambiguating. Please don't do that. This is how we've always done things, and it avoids the detected mime-types from being unregistered mime-types. This isn't going to change.
(In reply to comment #18) > (In reply to comment #17) > > (In reply to comment #16) > > > (In reply to comment #14) > > > > I extremely, extremely strongly disagree. The fdo mime type database is used > > > > as the base for several libs to get a specific mime type (for an extension > > > > or file type) and getting a completely meaningless (image/x-webp) mime type > > > > is counterproductive and will lead to libs being forced to work around that > > > > one specific mime type or not being able to rely on the database for image > > > > types. > > > > > > That's ridiculous. You already need to look up aliases to match mime-types, > > > this is no different. > > > > Let me explain the situation. > > You can stop with the patronising already. I've been contributing and > maintaining this repository for around 10 years, we're not going to change > the way we handle mime-types just because you don't like it. You are creating a problem in search of a solution. If this can't go in as image/webp, it's much better it doesn't go in at all. No amount of "patronising" is going to help it. > > > The base mime type is what a library will give you when you ask, "what is > > the mime type for this file?". If the library gives you image/x-webp, and > > the app using this library then downstreams this claim (for example, into a > > web server which will then go into a web browser), the endpoint receives the > > *wrong* mime type and does not understand it. > > The end point being? Something that can't do lookups with the fd.o database? > The client should be less dumb in that case, not the web server. And until > the mime-type is registered, I don't see why we should be returning a > mime-type that doesn't follow specifications. For the client, it's a > one-line lookup. I thought it was pretty obvious. If it's not, I'm not wasting my breath/fingers re-explaining this...
commit 7612a110f9a42db4730a8c6d1fff6d78c899d53d Author: Igor Murzov <e-mail@date.by> Date: Sun Mar 31 02:54:27 2013 +0400 Add image/x-webp mime-type Magic information from: https://developers.google.com/speed/webp/docs/riff_container#webp-file-header https://bugs.freedesktop.org/show_bug.cgi?id=41155
(In reply to comment #20) > commit 7612a110f9a42db4730a8c6d1fff6d78c899d53d > Author: Igor Murzov <e-mail@date.by> > Date: Sun Mar 31 02:54:27 2013 +0400 > > Add image/x-webp mime-type > > Magic information from: > > https://developers.google.com/speed/webp/docs/riff_container#webp-file-header > > https://bugs.freedesktop.org/show_bug.cgi?id=41155 I don't know whether to call this passive aggressive or straight up hostile. You're creating a problem that will then waste people's time. I've hit issues like these before and they show up in all kinds of apps. Thanks for that.
(In reply to comment #21) > I don't know whether to call this passive aggressive or straight up hostile. No, I just think that it's faster if I do the changes myself rather than trying to argue with you about it. > You're creating a problem that will then waste people's time. I've hit > issues like these before and they show up in all kinds of apps. File bugs against those applications, if they can't detect that 2 mime-types are aliases, it's not really up to a database to do that. "Be conservative in what you send (eg. only registered mime-types, or correct unregistered mime-types), be liberal in what you accept (accept aliased mime-types)".
(In reply to comment #22) > (In reply to comment #21) > > I don't know whether to call this passive aggressive or straight up hostile. > > No, I just think that it's faster if I do the changes myself rather than > trying to argue with you about it. > > > You're creating a problem that will then waste people's time. I've hit > > issues like these before and they show up in all kinds of apps. > > File bugs against those applications, if they can't detect that 2 mime-types > are aliases, it's not really up to a database to do that. For having spent 10 years maintaining this repo, you're not much in the way of understanding how apps actually use it, do you? Here is a question for you: when I said "Let me explain the situation", did you immediately skip it and complain I sounded patronising rather than try to understand the problem? The base mime type is considered the canonical one. Consider the following setup: - Downstream application 1 deals with file types and uses shared-mime-info as backend - Downstream server (nginx, apache, whatever) is passed a file's content type from Downstream app 1 and will then send "Content-Type: <mime type>" given the content type it has been given. - Endpoint browser Google Chrome receives "Content-Type: image/x-webp", which it does not recognize as valid (it expects image/webp). At this point, we're not even on the same machine as where we started and xdg specs are irrelevant; image/x-webp is impossible to unalias. Yes, Google needs to get off its chair and get image/webp sent to the IANA. I'll ping some people to get the ball rolling again. In the mean time, I meant what I said: if you can't commit image/webp as it is, please don't commit it at all. You are creating a problematic situation here.
For the record, I completely agree with everything that Jerome Leclanche has said in this bug so far.
(In reply to comment #18) > I wrote that bit of spec. So consider it a MUST. I see a disconnect between your insistance on rejecting a MIME type because it's not registered and your opinion that a "SHOULD" can become a "MUST" on a whim.
(In reply to comment #25) > (In reply to comment #18) > > > I wrote that bit of spec. So consider it a MUST. > > I see a disconnect between your insistance on rejecting a MIME type because > it's not registered and your opinion that a "SHOULD" can become a "MUST" on > a whim. And I see a disconnect between your propensity to comment and your contribution to this project. It's a HACKING file, not a spec. Let me know when it actually breaks something in real life, as opposed to Jerome's case of a server blindly accepting the user's application's mime-type as truth.
(In reply to comment #26) > (In reply to comment #25) > > (In reply to comment #18) > > > > > I wrote that bit of spec. So consider it a MUST. > > > > I see a disconnect between your insistance on rejecting a MIME type because > > it's not registered and your opinion that a "SHOULD" can become a "MUST" on > > a whim. > > And I see a disconnect between your propensity to comment and your > contribution to this project. I think we can have this discussion without resorting to personal attacks.
(In reply to comment #26) > Let me know when it actually breaks something in real life, as opposed to > Jerome's case of a server blindly accepting the user's application's > mime-type as truth. I just tested the exact scenario I mentioned: http://leclan.ch/public/1_webp_ll.webp The server sends image/x-webp, the mime type is not recognized, chromium rejects it. With image/webp it lets you view the file. Furthermore, when the image is directly included in a file, chrome refuses to display it. It accepts the server's content type as the real one. http://leclan.ch/public/webp.html Bastien, you don't want image/webp in the repo, don't commit it in. Your change creates a problem. You can stick your head in the sand, the problem is still going to be there. As the maintainer of the repo you're responsible for not doing exactly what you're currently doing. PS: I'm tired of your ad hominems. I've been trying to explain to you the problem since comment #14 with support from other people and you've been, in order, dismissing it as "patronising", ignoring it, dismissing it as bureaucracy, ignoring it again and finally saying the problem does not exist in the real world. I hope that now that I've shown you that this *is* a real world problem, you actually start considering it as such.
(In reply to comment #28) > The server sends image/x-webp, the mime type is not recognized, chromium > rejects it. So the bug is really chromium not being able to hande aliases. > It accepts the server's content type as the real one. And there is another bug in chromium: blindly trusting mimetypes, without even checking for aliases. If the problems are the two above, I'd say it is just a chromium issue. Applications/libraries handling XDG mimetypes ought to handle aliases anyway, this is nothing special to this specific mimetype.
(In reply to comment #29) > (In reply to comment #28) > > The server sends image/x-webp, the mime type is not recognized, chromium > > rejects it. > > So the bug is really chromium not being able to hande aliases. > > > It accepts the server's content type as the real one. > > And there is another bug in chromium: blindly trusting mimetypes, without > even checking for aliases. > > If the problems are the two above, I'd say it is just a chromium issue. > Applications/libraries handling XDG mimetypes ought to handle aliases > anyway, this is nothing special to this specific mimetype. This is not how web browsers work. Chrome does not use xdg mime types, nor should it.
(In reply to comment #30) > (In reply to comment #29) > > (In reply to comment #28) > > > The server sends image/x-webp, the mime type is not recognized, chromium > > > rejects it. > > > > So the bug is really chromium not being able to hande aliases. > > > > > It accepts the server's content type as the real one. > > > > And there is another bug in chromium: blindly trusting mimetypes, without > > even checking for aliases. > > > > If the problems are the two above, I'd say it is just a chromium issue. > > Applications/libraries handling XDG mimetypes ought to handle aliases > > anyway, this is nothing special to this specific mimetype. > > This is not how web browsers work. Chrome does not use xdg mime types, nor > should it. To elaborate: We are talking about end user apps. Those apps can be on any platform, including non-xdg platforms (eg. Windows). The problem is not at the client level, it's at the server level.
(In reply to comment #26) Bastien, can you please at all defend your absolutely pointless inclusion of image/x-webp instead of ignoring anything that vaguely looks like reasonable discussion? I don't care that much whether webp is in fdo or not, but there is zero reasons to keep it in as image/x-webp as that is *not a real mime type*.
Doesn't RFC 6648 recommend against using X- prefixes in situations like this anyway?
(In reply to comment #33) > Doesn't RFC 6648 recommend against using X- prefixes in situations like this > anyway? RFC 6648 is a meta-rfc which is more relevant to *new* RFCs being written, encouraging the use of a proper standardization protocol instead of x- prefixes (eg. in http). While the logic applies to mime types in general, it's not really relevant to this problem. Anyway, it looks like Bastien Nocera is straight up ignoring this bug. Sickeningly disgusting behaviour for a maintainer, really. I pinged a few people at Google to see if the process of standardizing image/webp can be put on track. I'm going to leave this alone because it's turning into bullshit political drama and the entire thing is ridiculous. When this comes up (and it *will* come up, I deal with this crap on a weekly basis) I'll make sure people complain directly to the source of the problem. Ridiculous.
I wish I had seen this sooner. Typically, the xdg spec is used on the client side (when it comes to HTTP) rather than server-side. So mimetypes come from the HTTP server, and the xdg-based app works whichever the main mimetype is, as long as the naming used by the http server is present, either as main or alias). In such a case, no debate necessary. What's new in this report is the use case of using shared-mime-info on the server side, to determine which mimetype to send in the first place. I would say, the xdg spec isn't really made for this use case, it has many other instances where this could be an issue, depending on what apps expect. Example, application/stuffit (not iana-registered) is an alias, the main mimetype is application/x-stuffit. I could be wrong, but I suspect that sending x- would not make the StuffIt application happy. So, let's not mix the issues. Adding webp the way stuffit was added, is perfectly fine with the way the spec currently works and is currently used (client side rather than server side). If anyone actually uses shared-mime-info to determine which mimetype to *send* as a server, then they'll have a much wider problem than the webp single case. A very hard problem in fact, since non-xdg apps don't all agree on how to name stuff. application/x-targz or application/x-compressed-tar? audio/microsoft-wave or audio/x-wav? Good luck deciding, there's no consenssus AFAIK. Outside IANA registered mimetypes, in particular. But even in IANA: application/msword or application/vnd.ms-word? (both are in IANA). So overall, even though I'm generally in favour of pragmatic solutions that help with interoperability, I feel that the reasoning about an hypothetical server-side use of shared-mime-info, while a valid issue to raise, is outside the scope of this discussion, and in practice, for the current audience of shared-mime-info, having x-webp as main mimetype and webp as "pragmatic for interoperability" alias is fine, and in line with how s-m-i works and is currently used. For the record, I initially thought the other way so I looked at existing mimetypes that break the rule (main mimetype with no x- prefix and no IANA registration), and only found these, that are not in IANA: video/webm, audio/webm, video/annodex and audio/annodex (OK, that wasn't an exhaustive search, of course, more like random poking). But looking further, I see that annodex did request IANA (http://www.annodex.net/TR/annodex.html#anchor15), so the mistake (of assuming they did get registered) is understandable -- I don't know why IANA didn't add it to http://www.iana.org/assignments/media-types/media-types.xhtml#video. So only webm seems to be an oversight? Bastien? See https://bugs.freedesktop.org/show_bug.cgi?id=28313
(In reply to comment #35) > For the record, I initially thought the other way so I looked at existing > mimetypes that break the rule (main mimetype with no x- prefix and no IANA > registration), and only found these, that are not in IANA: video/webm, > audio/webm, video/annodex and audio/annodex (OK, that wasn't an exhaustive > search, of course, more like random poking). But looking further, I see that > annodex did request IANA (http://www.annodex.net/TR/annodex.html#anchor15), > so the mistake (of assuming they did get registered) is understandable -- I > don't know why IANA didn't add it to > http://www.iana.org/assignments/media-types/media-types.xhtml#video. > > So only webm seems to be an oversight? Bastien? See > https://bugs.freedesktop.org/show_bug.cgi?id=28313 Google has also sent the request to IANA for webp and friends, which hasn't been answered so far. Someone is currently tracking this down.
commit 721c7e33cfdfe35d85de44bc68e1f1c8629fec4f Author: Bastien Nocera <hadess@hadess.net> Date: Mon Mar 31 15:36:40 2014 +0200 Switch WebP mime-type and alias around The request for a WebP mime-type was made with the IANA, but still not processed to this day. It's unlikely that the mime-type ever be rejected, so add image/webp as the main mime-type.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.