Closed
Bug 189872
Opened 22 years ago
Closed 17 years ago
Accept: Add JNG and MNG MIME types (when they are supported)
Categories
(Core :: Networking: HTTP, defect)
Core
Networking: HTTP
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: bugmail, Unassigned)
Details
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?)
Keywords: clean-report
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.
Comment 4•22 years ago
|
||
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.
Comment 6•21 years ago
|
||
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
Comment 7•21 years ago
|
||
So there are no registered types at all for the jng/mng format?
Comment 8•21 years ago
|
||
bz: well, x- prefix means unregistered. if there are registered versions, then we should be sending those instead if anything at all.
Comment 9•21 years ago
|
||
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....)
Comment 10•21 years ago
|
||
>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.
Comment 11•21 years ago
|
||
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?
Comment 12•21 years ago
|
||
>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)
Comment 13•21 years ago
|
||
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
Comment 15•21 years ago
|
||
If JNG is a subset of MNG, surely advertising an MNG mime-type implies acceptance of JNG? Gerv ("Accept Header Czar" :-)
Reporter | ||
Comment 16•21 years ago
|
||
I think it may be a "subset" in architecture and background only, not in practical implementation.
Comment 17•21 years ago
|
||
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!
Comment 18•21 years ago
|
||
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
Comment 19•21 years ago
|
||
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
Comment 20•21 years ago
|
||
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.
Reporter | ||
Comment 21•21 years ago
|
||
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.
Comment 22•21 years ago
|
||
*** Bug 214857 has been marked as a duplicate of this bug. ***
Comment 23•21 years ago
|
||
I haven't used Mozilla recently, but does it still support MNG, or was it just Mozilla Firebird that removed MNG support?
Comment 24•21 years ago
|
||
Last I saw, you specifically had to include it in your .mozconfig otherwise it wouldn't be built.
Comment 25•21 years ago
|
||
Mozilla currently doesn't support MNG. However, when it does again, this bug will become relevant, so let's not close it. Gerv
Comment 26•21 years ago
|
||
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.
Comment 27•21 years ago
|
||
*** Bug 231101 has been marked as a duplicate of this bug. ***
Comment 28•21 years ago
|
||
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)
Comment 29•20 years ago
|
||
Isn't this a DUP of Bug 116381 ?
Comment 30•20 years ago
|
||
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.
Updated•18 years ago
|
Assignee: darin → nobody
Status: ASSIGNED → NEW
Target Milestone: Future → ---
Comment 31•17 years ago
|
||
Just echoing the WONTFIXed from bug 18574.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•