Bug 52719 - Send a more specific Accept http header
Summary: Send a more specific Accept http header
Status: RESOLVED FIXED
Alias: None
Product: kio
Classification: Frameworks and Libraries
Component: http (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Unassigned bugs mailing-list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-01-08 03:00 UTC by Jim Dabell
Modified: 2004-05-03 19:03 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jim Dabell 2003-01-08 03:00:13 UTC
Version:            (using KDE KDE 3.0.99)
Installed from:    Compiled From Sources
Compiler:          GCC 3.2.1 
OS:          Linux

Currently, the Accept HTTP header sent by Konqueror does not do a very good job.  This is important for content negotiation and also for stats purposes.  Right now, it sends the following when a url is requested by typing it into the location bar:

Accept: text/*, image/jpeg, image/png, image/*, */*

Firstly, it rates all text subtypes as being equally important.  I would say that virtually all Konqueror users would prefer HTML to plain text:

Accept: text/html, text/*;0.9, image/jpeg, image/png, image/*, */*

Secondly, the jpeg and png types are redundant, as they are also covered by the image/* entry (the ones that appear first in the list are not treated as more important, that is what the quality weighting is for):

Accept: text/html, text/*;0.9, image/jpeg, image/png, image/*;0.9, */*

Lastly, you want to indicate that you want something else only when all other options have failed:

Accept: text/html, text/*;0.9, image/jpeg, image/png, image/*;0.9, */*;0.01

This is more in line with current practice of Mozilla:

Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1

Also, the same header is sent for stylesheets attached with <link> elements.  The header I propose for this circumstance:

CSS:

Accept: text/css

CSS is the only type of stylesheet that Konqueror handles, so this is exactly what should be sent.  However, there are a few misconfigured servers out there that send *.css files as text/plain or application/x-pointplus so we may want to include a fallback:

Accept: text/css, */*;0.0.1

The first strategy is in line with Mozilla in Strict mode (non-text/css stylesheets are ignored), the second is in line with Mozilla in Compatibility mode.

Note that the solution should not be to send the other mimetypes in the Accept header: that would be saying to the server "I will accept Powerpoint files", which is clearly wrong.

Images:

Currently, it seems that every image supported by Konqueror is listed, without any weighting.  Considering that Konqueror accessing images embedded in HTML over HTTP is almost certainly a typical web browsing session, I think preference should be given to image/jpeg and image/png, with the others having a weighting of 0.8, and image/gif having a weighting of 0.9 (it's still probably a better choice in this situation than any of the others).

The list is quite long, this could be shortened by replacing all of the 0.8 weighted entries by an image/*;0.8 entry, however this wouldn't reflect the fact that Konqueror handles these types, but not others in the image group.  It also wouldn't mention video/mng, which I thought was supported by konqueror, but doesn't appear in the Accept header at the moment (that might just be my compilation parameters, though).

Other areas that need checking are the favicon support (should only accept mimetypes that Konqueror can render as favicons), external javascript files, and <object> elements (should give a bigger weighting to the mime-type supplied as the type attribute).   I haven't looked into these.

Relevent links:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1
http://bugzilla.mozilla.org/show_bug.cgi?id=170789
http://bugzilla.mozilla.org/show_bug.cgi?id=82526
Comment 1 Christian Wolfgang Hujer 2003-04-10 16:09:09 UTC
I suggest giving application/xhtml+xml higher priority than text/xml and
application/xml because the first one is more specific in any way than the
latter ones.

Also, video/x-mng should be preferred over png which itself should be preferred
over jpeg.

So I suggest to use:
Accept:
application/xhtml+xml,text/xml;q=0.9,application/xml;q=0.9,text/html;q=0.8,text/plain;q=0.7,video/x-mng,image/png;q=0.9,image/jpeg;q=0.8,image/gif;q=0.2,text/css,*/*;q=0.1


And as soon as Konqueror supports SVG, the Accept header should be:

Accept:
application/xhtml+xml,text/xml;q=0.9,application/xml;q=0.9,text/html;q=0.8,text/plain;q=0.7,image/svg+xml,video/x-mng;q=0.9,image/png;q=0.8,image/jpeg;q=0.7,image/gif;q=0.2,text/css,*/*;q=0.1


I would really not be anxious about the length as long as the header doesn't
exceed an MTU (and it doesn't).

Another relevant link:
http://bugzilla.mozilla.org/show_bug.cgi?id=201195
Comment 2 Jim Dabell 2003-04-10 16:36:30 UTC
I would *strongly* discourage putting application/xhtml+xml into the accept header.  
Last time I checked, konqueror just chucks xhtml documents through it's tag soup 
parser, which is not correct behaviour at all for xhtml served as application/xhtml+xml. 
 
For more details, please see bug #52665 
 
mng, png and jpeg all serve different purposes - it doesn't make sense to prefer one 
over another.  Where there is a specific reason for providing multiple image formats (I 
can't think of any off the top of my head), the author can weight the elements on the 
server-side - I don't see why konqueror should care which it gets. 
 
Comment 3 Christian Wolfgang Hujer 2003-07-07 07:30:38 UTC
Konqueror should care about different image formats having different priorities because thus it 
can tell the server it supports and prefers e.g. image/mng over image/gif. The only chance for 
a server to easily do content negotiation is to listen to the priorities given client side. The 
default priorities on the server side must match the crappy */* several browsers shamelessly 
send without adding a low priority, so the server itself must prefer old crap like image/gif or 
image/jpeg over the new formats like image/svg+xml, image/png or video/x-mng. 
 
So if I have some little animation which is smaller in video/x-mng than in image/gif, I'd like to 
put it on the server as both formats, serving mng-supporting browsers with video/x-mng and 
image/gif to the others. If a user agent doesn't tell my server it prefers video/x-mng it won't get 
video/x-mng. 
 
This is totally analogeous to the HTML vs. XHTML issue. (Of course, Konqueror doesn't 
support XHTML properly yet?) 
 
/Christian 
Comment 4 Dawit Alemayehu 2003-07-09 15:10:04 UTC
Hello, 
 
Please read RFC 2616 section 14.1 to see how the Accept header works. Your 
description about how the preference for a specific mime-type works is simply 
wrong.  If there is no quality factor specified the precedence is to prefer the 
more specific mime-types over the geneirc ones.  For example, for 
 
Accept: text/html, image/jpeg, image/png, text/*, image/*, */* 
 
The precedence would be 
 
text/html 
image/jpeg 
image/png 
text/* 
image/* 
*/* 
 
Now the server can substitute image/jpeg or image/png for text/html at will if that 
is the only mime-type it can send back. Anyways, I have fixed the default header 
so it now it does 
 
Accept: text/html, image/jpeg, image/png, text/*, image/*, */* 
 
instead of 
 
Accept: text/*, image/jpeg, image/png, image/*, */* 
 
BTW, we did start out sending the quality factor, but later removed it because it 
does not work with some webservers.  IIRC, it was the older version of 
Netscape's webservers (Sun's iplanet now??) that choked on it. 
 
Regards, 
Dawit A. 
 
Comment 5 Christian Wolfgang Hujer 2004-05-03 19:03:44 UTC
Hi Dawit,

I know how Mime works, but Microsoft doesn't, which forces me to configure my servers not just accordingly to the Mime RFCs but also to Microsoft's "Accept: */*".

/Christian