231357 - Remove universal image mimetypes from accept header

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect)

Description

[Mike Connor [:mconnor]]

Spinoff from http://bugzilla.mozilla.org/show_bug.cgi?id=189872#c17

this seems like the sane thing to do, patch upcoming based on darin's comment

Comment 1

[Mike Connor [:mconnor]]

Attachment: patch

Comment 2

[Darin Fisher]

what about thunderbird, sunbird, standalone composer?  those apps have all
forked all.js and would need to be similarly touched.  however, i'm not sure
that i can provide r= for all of those (as well as firebird).  perhaps you
should break the patch up into several pieces for each product??

Comment 3

[Mike Connor [:mconnor]]

Comment on attachment 139339 [details] [diff] [review]
patch

already bitrotted due to bug 231200

in the process of splitting this off into separate patches for each product

Comment 4

[Mike Connor [:mconnor]]

darin, the changes in bug 231200 mean that Firebird will inherit this from the
app-independent all.js, which is relatively sane behaviour.  Attaching a second
patch with the change to mozilla/modules/libpref/src/init/all.js only in just a
moment.

bsmedsberg's second patch for bug 224578 left it in for Standalone Composer,
however I'm not sure there's a benefit to have this forked.  Sunbird and
Thunderbird, to my knowledge, have not carried out similar pruning to all.js for
their products, however in the process I would personally feel letting the main
GRE pref propagate as Firebird has done.

Comment 5

[Mike Connor [:mconnor]]

Attachment: patch to libpref all.js

Comment 6

[Mike Connor [:mconnor]]

Attachment: remove network.http.accept.default from Standalone Composer's all.js

supplement to above patch, r=bsmedsberg on IRC

Comment 7

[Mike Connor [:mconnor]]

Comment on attachment 139395 [details] [diff] [review]
patch to libpref all.js

if at all possible, I'd like to see this land for 1.7alpha

Comment 8

[Gervase Markham [:gerv]]

The current header tells us that we prefer GIFs and JPEGs to any other image
format - e.g. TIFF, BMP. The new header doesn't. Is this useful information?

The new header says we prefer PNGs to JPEGs. I guess that doesn't matter too
much, as they have different uses.

Gerv

Comment 9

[Mike Connor [:mconnor]]

are we likely to encounter any situations where we have the choice between JPEG
and TIFF/BMP?  I really don't think such a situation would arise, since they
have radically different uses.

Comment 10

[Gervase Markham [:gerv]]

I seem to remember some photography sites sending TIFFs if you support it, but
otherwise JPEG. But I could be wrong. You're right - it's probably quite rare.

Gerv

Comment 11

[Darin Fisher]

Comment on attachment 139395 [details] [diff] [review]
patch to libpref all.js

what about imgLoader.cpp:199 (or there abouts)?

Comment 12

[Mike Connor [:mconnor]]

darin, I won't be home until 10 PM PST at the absolute earliest (work sucks) so 
there's just no way I'll get that done before the midnight freeze unless I were 
to get a really last minute r+sr.  Although, I really think this would belong 
in alpha if we can get it in, if it breaks stuff we have lots of time for 
feedback... 

Comment 13

[Mike Connor [:mconnor]]

Attachment: patch that includes change to imgLoader.cpp

Comment 14

[Mike Connor [:mconnor]]

Comment on attachment 141910 [details] [diff] [review]
patch that includes change to imgLoader.cpp

As a note, Thunderbird will now inherit this as well, since they have done the
needed upgrades to their default prefs.

Comment 15

[Roland Mainz]

mconnor:
Can you give any arguments why Mozilla should NOT announce that it supports
image/jpeg and image/gif ?

Comment 16

[Mike Connor [:mconnor]]

because we don't need to.  Other than lynx, every major web browser released in
the last seven years accepts jpg/gif.  Other than priority in content
negotiation, there's no reason to include text/html either.

The problem with bloating the accept header with extra info is that you can end
up pushing two packets instead of one, just to transmit the header.  That's not
a lot on one machine on one connection, but you multiply by the number of times
it gets sent for a number of users and its a lot of wasted packets flying around.

Comment 17

[Roland Mainz]

Mike Connor wrote:
> because we don't need to.

So you suggest to sacrify standard-compilance for that ? Mozilla claims to be
closer to the standards than IE, but now you're suggesting something for which
IE is hated for. I can't find any comments in the RFC which defines HTTP which
would allow such a behaviour.

Comment 18

[Stuart Parmenter]

What are you going on about roland?  We claim to accept */* which last i checked
meant we did support image/jpeg and image/gif

Comment 19

[Roland Mainz]

Stuart Parmenter wrote:
> What are you going on about roland?  We claim to accept */* which last i 
> checked meant we did support image/jpeg and image/gif

*/* is just a NO-OP and delivers zero information to CGIs (with your
argumentation we can reduce the "Accept:"-header to */* - or obmit ot
completely. That's would save even more bytes... =:-)
The "Accept:"-header should list ALL the image formats supported and I can't
find any comments which would allow Mozilla just to shorten the list.

Comment 20

[Brendan Eich [:brendan]]

Roland: you're clearly out of date on the history of Accept: headers and content
negotiation on the web.  Please read
http://bugzilla.mozilla.org/show_bug.cgi?id=58040#c10 and other comments.  There
is no requirement to send a bloated Accept: header listing every MIME type that
might be supported by a plugin, let alone every type definitely supported by
Gecko without plugins.

Content negotiation via Accept: headers is marginally useful, not worth bloating
such headers over.  Get over it!

/be

Comment 21

[timeless]

mconnor: links, elinks, wannabe. i'm sure i'm missing a few.

Comment 22

[Darin Fisher]

Comment on attachment 141910 [details] [diff] [review]
patch that includes change to imgLoader.cpp

>Index: mozilla/modules/libpref/src/init/all.js

>-pref("network.cookie.warnAboutCookies",     false);
>-pref("network.cookie.lifetime.enabled",     false);
>-pref("network.cookie.lifetime.behavior",    0);
>-pref("network.cookie.lifetime.days",        90);
>+pref("network.cookie.lifetimePolicy", 0); // accept normally, 1-askBeforeAccepting, 2-acceptForSession,3-acceptForNDays
>+pref("network.cookie.alwaysAcceptSessionCookies", false);

wrong bug i presume?


r=darin

Comment 23

[Mike Connor [:mconnor]]

Attachment: patch without silly cruft

darin, right, that was bug 233339

I think I need a couple more trees while I'm still messing with prefs

Comment 24

[Mike Connor [:mconnor]]

checking in at 02/25/2004 20:16

Comment 25

[tor]

Given that we're doing a wildcard, why are we still explicitly listing PNG?
Every major browser shipped supports this as well.  Sure IE doesn't do
alpha right, but even it gets things right up to level of GIF.

Comment 26

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Comment on attachment 139401 [details] [diff] [review]
remove network.http.accept.default from Standalone Composer's all.js

r=[e-mail]

Comment 27

[Mike Connor [:mconnor]]

checked in the supplementary patch for Composer this morning

tor: IIRC, the reasons given originally for leaving image/png specified is for
content negotiation purposes.

Comment 28

[tor]

We're removing all the image types precisely because content-negotiation
is never done in the real world. so why leave image/png hanging out there?

Comment 29

[tor]

*** Bug 209683 has been marked as a duplicate of this bug. ***