Accept: Add JNG and MNG MIME types (when they are supported)

RESOLVED WONTFIX

Status

()

Core
Networking: HTTP
--
minor
RESOLVED WONTFIX
16 years ago
11 years ago

People

(Reporter: Greg K., Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 years ago
Since Mozilla supports JNG, the "image/x-jng" MIME type should be included in
the HTTP_ACCEPT header (video/x-mng is already included).
(Reporter)

Updated

16 years ago
Summary: Add "image/x-jng" to HTTP_ACCEPT header → Add JNG "image/x-jng" MIME type to HTTP_ACCEPT header
(Reporter)

Comment 1

16 years ago
It looks like what needs to be edited is
<http://lxr.mozilla.org/seamonkey/source/modules/libpref/src/init/all.js#540>.

Comment 2

16 years ago
+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
(Reporter)

Comment 3

16 years ago
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

15 years ago
cc'ing stuart for some history here.  generally, we want to keep the Accept
header as short as possible.

Comment 5

15 years ago
Probably video/x-mng should be removed - might as well only advertise
acceptance of registered mimetypes.

Comment 6

15 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
So there are no registered types at all for the jng/mng format?

Comment 8

15 years ago
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....)

Comment 10

15 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.
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

Comment 14

15 years ago
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" :-)
(Reporter)

Comment 16

15 years ago
I think it may be a "subset" in architecture and background only, not in
practical implementation.

Comment 17

15 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!
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

Comment 20

15 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

15 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

15 years ago
*** Bug 214857 has been marked as a duplicate of this bug. ***

Comment 23

15 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

15 years ago
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.

Comment 27

15 years ago
*** Bug 231101 has been marked as a duplicate of this bug. ***

Comment 28

15 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)
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.

Updated

12 years ago
Assignee: darin → nobody
Status: ASSIGNED → NEW
Target Milestone: Future → ---

Comment 31

11 years ago
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.