Since Mozilla supports JNG, the "image/x-jng" MIME type should be included in the HTTP_ACCEPT header (video/x-mng is already included).
Summary: Add "image/x-jng" to HTTP_ACCEPT header → Add JNG "image/x-jng" MIME type to HTTP_ACCEPT header
It looks like what needs to be edited is <http://lxr.mozilla.org/seamonkey/source/modules/libpref/src/init/all.js#540>.
+clean report greg: can you give a short explaination for why this should be added (for example, did we recently add support for this format, is it growing in popularity?)
Summary: Add JNG "image/x-jng" MIME type to HTTP_ACCEPT header → Accept: Add JNG "image/x-jng" MIME type
JNG support was added to Mozilla along with MNG support. JNG is, in fact, a sub-format of MNG. Both formats are fairly new, and it's my understanding that such new formats should be explicitly specified in the Accept header. Indeed, that's probably why MNG is listed. It was probably an oversight that JNG wasn't added at the same time.
cc'ing stuart for some history here. generally, we want to keep the Accept header as short as possible.
Probably video/x-mng should be removed - might as well only advertise acceptance of registered mimetypes.
tor: great! i'm all for shortening our Accept header :)
Status: NEW → ASSIGNED
Summary: Accept: Add JNG "image/x-jng" MIME type → Accept: Add JNG "image/x-jng" MIME type, or remove MNG MIME type
Target Milestone: --- → mozilla1.4alpha
So there are no registered types at all for the jng/mng format?
bz: well, x- prefix means unregistered. if there are registered versions, then we should be sending those instead if anything at all.
Of course. ;) Perhaps we could not list these in the main Accept header but list them in the one that gets sent on known image loads? (that header should be generated based on the installed image decoders anyway, so I would think that would happen automatically....)
>Of course. ;) my bad for assuming otherwise ;) >Perhaps we could not list these in the main Accept header but list them in the >one that gets sent on known image loads? (that header should be generated based >on the installed image decoders anyway, so I would think that would happen >automatically....) yeah, maybe. though folks might wonder why we send something different in each case.
Yeah, that's why it's a "perhaps" as opposed to a "we should do this". Does anyone know whether the registration process for these MIME types is likely to happen in the near future?
>that header should be generated based >on the installed image decoders anyway don't think that's what currently happens, there is no real good way for enumerating the installed image decoders (except enumerating all xpcom components and looking for the common contractid prefix of the decoders)
I requested registration of video/prs-mng 6 or more months ago, and asked that they consider waiving the RFC-publication requirement and register video/mng as well. They did get back to me after a few weeks to request an expanded "security issues" section, which I immediately sent, but then they went silent without registering either video/mng or video/prs-mng. Since IANA seems to be dormant and useless, I'd say just consider the official media types to be video/x-mng and image/x-jng. Glenn
glenn: thx for the info.
Target Milestone: mozilla1.4alpha → Future
If JNG is a subset of MNG, surely advertising an MNG mime-type implies acceptance of JNG? Gerv ("Accept Header Czar" :-)
I think it may be a "subset" in architecture and background only, not in practical implementation.
i spoke with pav a bit about this today. neither of us understand why we are advertizing support for an image format that isn't used on the web. we also don't understand why we have to make explicit our support of common image formats. practically every web browser supports GIF and JPEG, so why do we need to call them out in the accept header? maybe we should just be calling out PNG. "video/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1" could become: "image/png,*/*;q=0.5" and probably no server would care. content negotiation zealots: bring it on!
I'm having major deja vu. I believe fur made the same argument back in 3.x or 4.x days as darin makes in comment 17. It may be that fur was citing progressive jpegs, not pngs, as the exception to the "don't bloat Accept: with well-known and universally-supported MIME types" rule. I'm with darin. /be
I can see the argument for removing GIF and JPEG. By the same argument, should we be removing text/html? There's a related bug: bug 201195. The point of including GIF was to show we preferred PNG; but it can be caught by */*. Fair enough. However, I still feel we should include PNG (that seems clear) and MNG, precisely because not many browsers support it. As I see it, content-negotiation is about letting web servers send the best content they can; to do that, they need to know what we support that _isn't_ universal. Gerv
gerv: we also have to "want" servers to send MNG. is that the case? note: we also support bmp, xbm, ppm, and ico, which aren't exactly commonplace (or preferred) internet image formats. if MNG has something to offer the internet, then perhaps you could make a chicken-n-egg style argument that advertizing support for MNG is a good thing, but otherwise i'm not sure it is worth it.
As PNG was a desirable replacement for GIF, so MNG is a desirable replacement for *animated* GIF. JNG is a little more specialized. Content developers supplying JNG images (to use the alpha channel, probably; that's why I've used it) will probably supply a PNG backup version. That PNG version will not be compressed as much, though, so advertising JNG support is still beneficial.
*** Bug 214857 has been marked as a duplicate of this bug. ***
I haven't used Mozilla recently, but does it still support MNG, or was it just Mozilla Firebird that removed MNG support?
Last I saw, you specifically had to include it in your .mozconfig otherwise it wouldn't be built.
Mozilla currently doesn't support MNG. However, when it does again, this bug will become relevant, so let's not close it. Gerv
Re comment #24: That's how it will be when MNG comes back, as a configurable feature. Right now MNG is not supported at all in Mozilla-1.5 except via an XPI. It is still supported natively in MNG-1.4.x. See http://mngzilla.sf.net for more.
*** Bug 231101 has been marked as a duplicate of this bug. ***
updating summary - MNG type has been removed already, so this bug would be about adding the type or types back, as and when they are supported again
Summary: Accept: Add JNG "image/x-jng" MIME type, or remove MNG MIME type → Accept: Add JNG and MNG MIME types (when they are supported)
Isn't this a DUP of Bug 116381 ?
No. I suppose they could be somehow combined, though. This bug is about accepting the "experimental" MIME types video/x-mng and image/x-jng while bug #116381 is about accepting IANA mime types video/mng and image/jng prior to their actually being registered by IANA. It's not a dupe.
Assignee: darin → nobody
Status: ASSIGNED → NEW
Target Milestone: Future → ---
Just echoing the WONTFIXed from bug 18574.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.