280812 - Accept header for images should prefer GIF over MNG

Status: RESOLVED WONTFIX

(Core :: Networking: HTTP, defect)

Description

[Phil Endecott]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 (Debian package 1.0-2)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 (Debian package 1.0-2)

I have an animation and can serve it as MNG or GIF using content negotiation. 
Firefox (& presumably Mozilla suite) can render GIF and not MNG, but mentions
neither in the accept: header (Accept: image/png,*/*;q=0.5).  So I'll send MNG,
since it is smaller and has better transparency.  This is bad.  The accept:
header for images needs to mention gif with higher q than */*.


Reproducible: Always

Steps to Reproduce:

Comment 1

[Matthias Versen [:Matti]]

All browsers support *.gif and JPEG but not all MNG.
You have to assume that if MNG is not in the accept header that you have to send
GIF.
The gif header got removed with bug 231357 for good reasons 

-> wontfix

Comment 2

[Phil Endecott]

Hi Matti,

The HTTP RFC defines what the client and server must do to make content
negotiation work.  If you want to change the rules - and I don't disagree that
improvements could be made - it would be best to try and get a revised version
of the standard (HTTP1.2?).  Mozilla takes a "code to the standards" view in
areas like HTML and CSS - why is HTTP any different?

As far as I can tell there is no way that I can implement the algorithm that you
describe ["assume that if MNG is not in the accept header that you have to send
GIF"] using Apache's content negotiation directives; it strictly supports
HTTP1.1.  Can you recommend a server that does?

I am familiar with the byte-saving arguments and consider them over-rated.  If
the bytes are so valuable I'd consider the user agent string to be a better
tagert (mine is exactly 100 bytes long and you can see it above).  How about:

Mozilla/5.0 (Linux) G20041111 FF1.0

55 bytes saved and I bet no user-agent-detection scripts are broken.  Certainly
no RFCs broken.  Shall I file a bug suggesting this?

--Phil.

Comment 3

[Darin Fisher]

Plenty of user-agent sniffing scripts would be broken by that change.  I
understand your concerns, but it's been a while since Mozilla advertized support
for GIF in its Accept header, and this is the first complaint that I've heard. 
Usually, there is a default on which to fallback on when the an advertized type
is not supported.  Wouldn't that likely be GIF or JPEG for images?

BTW, moz no longer supports MNG (or else it would appear in the Accept header).

Comment 4

[Phil Endecott]

Hi Darin,

In bug #189872 comment 17, where you proposed the current image accept header of
"image/png,*/*;q=0.5", you wrote:

> probably no server would care.  content negotiation zealots: bring it on!

I am the content negotiation zealot and I am bringing it on.

Seriously though, the problem here is that it is a "fail dangerous" rather than
a "fail safe" situation.  Other content-negotiation problems like bug #240493
(SVG) result in an RFC-compliant server sending something that is sub-optimal
but useable, e.g. PNG or Flash rather than SVG.  In this case an RFC-compliant
server will send MNG instead of an animated GIF, which is broken.

Note that the discussions in bug #189872 took place before the removal of MNG,
which may explain why this situation was not considered at the time.


Going back to Matti's hack^H^H^H^H algorithm ["if MNG is not in the accept
header you have to send GIF"]: I am wondering whether a server could implement
this by adding something, presumably based on user-agent detection, to the start
or end of the Accept: header, before applying its negotiation algorithm.  IFF
earlier elements override later elements in the header, you could get this
effect by adding a suffix of "image/mng;q=0".  It would probably be better to
instead codify the "we accept gif and jpeg but don't advertise it" by adding gif
and jpeg with q higher than the */* value.  I will investigate whether Apache
can be patched to do this transformation.

--Phil.

Comment 5

[Darin Fisher]

SVG enabled builds should mention SVG in the Accept header.  It's a bug that
they do not.

I don't understand why any web server would bother coding MNG support since it
is hardly used on the internet.  That said, I'm sure you intend your argument to
apply to some other file formats.  Do you have a better example?

I think our solution is a reasonable compromise between Accept header bloat and
utility.

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

surely you can choose what type apache will fallback on? I mean, if neither gif
nor mng are mentioned in the header, wouldn't sending GIF make more sense, given
the wider support?

Comment 7

[Phil Endecott]

Darin wrote:

> I don't understand why any web server would bother coding MNG support
> since it is hardly used on the internet.

Apache implements HTTP1.1 per the RFC, it doesn't do anything special for MNG.

This is a chicken and egg issue.  It is hardly used because it is hardly
supported => it is hardly supported because it is hardly used.  I think that I
get more hits from browsers that understand MNG than that understand SVG, though
it is hard to tell.

Christian wrote:

> surely you can choose what type apache will fallback on? I mean, if
> neither gif nor mng are mentioned in the header, wouldn't sending GIF
> make more sense?

It is not a case of "falling back" as both gif and mng are implicitly mentioned
in the header by the */* pattern, giving them equal preference.  So the
algorithm chooses one based on server preference, which is for smaller files
with higher quality.

--Phil.