Last Comment Bug 68425 - W3C CUAP: List only supported media types in HTTP Accept header
: W3C CUAP: List only supported media types in HTTP Accept header
Status: VERIFIED DUPLICATE of bug 58040
Product: Core
Classification: Components
Component: Networking: HTTP (show other bugs)
: Trunk
: All All
-- normal (vote)
: Future
Assigned To: Darin Fisher
: John Unruh
: Patrick McManus [:mcmanus]
Depends on:
Blocks: 61682 68427
  Show dependency treegraph
Reported: 2001-02-10 01:40 PST by Gervase Markham [:gerv]
Modified: 2002-12-23 14:17 PST (History)
6 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description User image Gervase Markham [:gerv] 2001-02-10 01:40:36 PST
[ This bug is one of the recommendations in the W3C's "Common User Agent 
Problems" document, URL above. One bug has been filed on each recommendation, 
for deciding whether we do it and, if not, whether we should. ]

3.6 List only supported media types in an HTTP Accept header.

     HTTP/1.1 [RFC2616] defines content negotiation. The client sending out
     a request gives a list of media types that it is willing to accept;
     the server then returns a representation of the object requested in
     one of the specified formats if it is available.

     When entities are embedded in a document (such as images in HTML
     documents), user agents should only send Accept headers for the
     formats they support.


     If a user agent can render JPEG, PNG and GIF images, the list of media
     types accepted should be image/jpeg, image/png, image/gif.

     Wrong: User agent agents should not send an HTTP header of Accept: */*
     since the server may support content types that the user agent does
     not. For instance, if a server is configured so that SVG images are
     preferred to PNG images, a user agent that only supports PNG, GIF, and
     JPEG will receive (unsupported) SVG rather than (supported) PNG.
Comment 1 User image Matthew Paul Thomas 2001-02-10 04:17:41 PST
On the other hand, sending out a complete list of supported types is a bit of a 
privacy problem.
Comment 2 User image Karl Ove Hufthammer 2001-02-10 09:46:13 PST
> On the other hand, sending out a complete list of
> supported types is a bit of a privacy problem.

Comment 3 User image Jesse Ruderman 2001-02-10 13:39:50 PST
Does this apply only to images, or does it apply to all supported file types?
Comment 4 User image Andrew Clark 2001-02-28 12:38:48 PST
Surely if privacy is an issue you can allow the user to disable the feature.

My personal preference would be to be able to manually edit the accept line, or
at least be able to specify q values on a per mime-type basis. Even without this
feature, sending */* as an accept header is not correct, and as a result a user
could receive an invalid file format when a valid one is available, AND not be
able to do anything about it without any control within the user-agent.
Comment 5 User image Gervase Markham [:gerv] 2001-03-01 11:02:48 PST
neeti: I strongly believe this bug should not be futured until there has been a 
discussion on the strategy we are taking.
cpp says:

367     // Send */*. We're no longer chopping MIME-types for acceptance.
368     // MIME based content negotiation has died.
369     // SetHeader(nsHTTPAtoms::Accept, "image/gif,image/x-xbitmap,image/jpeg, 
370     // image/pjpeg, image/png, */*");
371     SetHeader(nsHTTPAtoms::Accept, "*/*");

This comment was checked in by on the 24th of March 2000, 
and the SetHeader("*/*") by on the 23rd of June 2000. What we 
were sending between those times I have no idea. Nothing, I assume.

The checkin comments for neither of these checkins contain a reference to this 
change. Does this change apply to all requests we send, or only those for 
top-level documents? If it is all, we are definitely not in the spirit of the 
RFC, and probably not the letter either...

Comment 6 User image Darin Fisher 2001-03-02 14:10:25 PST
over to networking:http
Comment 7 User image Darin Fisher 2001-03-02 14:11:03 PST
reassigning this to myself.
Comment 8 User image Gervase Markham [:gerv] 2001-03-02 14:11:33 PST
No reason why this shouldn't be done soon. It's a trivial fix.

Comment 9 User image Darin Fisher 2001-03-02 14:11:46 PST
let me try that again...
Comment 10 User image Gervase Markham [:gerv] 2001-03-02 14:18:07 PST
Trying the keywords again.

Comment 11 User image Gervase Markham [:gerv] 2001-03-02 14:43:04 PST
There's a patch for this in bug 58040. These are roughly the same bug, but both 
have useful content, so I'm not closing either.

Comment 12 User image Darin Fisher 2001-03-02 15:08:50 PST
Gerv, I'm going to mark this as a dupe of bug 58040... so that we can focus
our attention on that bug.

*** This bug has been marked as a duplicate of 58040 ***
Comment 13 User image John Unruh 2002-12-23 14:17:41 PST
Verified dupe.

Note You need to log in before you can comment on or make changes to this bug.