Closed
Bug 2808
Opened 26 years ago
Closed 26 years ago
Mozilla 5 supports XML, but it does not announce it in it's HTTP request headers...
Categories
(Core :: XML, defect, P4)
Core
XML
Tracking
()
VERIFIED
FIXED
M3
People
(Reporter: roland.mainz, Assigned: ebina)
References
Details
Hi !
----
Mozilla seems to support XML, but the HTTP request header does not include XML.
The request line from a "Snoop"-Servlet looks like this:
-- snip --
accept: image/gif, image/x-bitmap, image/jpeg, image/pjpeg, image/png, */*
-- snip --
A much better request would look like this:
-- snip --
accept: text/html, text/xml, image/png, image/gif, image/x-bitmap, image/jpeg,
image/pjpeg, */*
-- snip --
And what are the advantages:
a) In our case, our web-server can check if the browser support XML or not.
If the browser supports XML, nothing is done, but if the browser does
not support XML, a converter is started "on the fly" to create HTML code
from the
XML document.
We need this feature for a new medical documentation system, which
is XML-based, but we're required to be "backward-compatible" with
HTML and /or
text-based browsers (lynx etc.).
b) image/png was moved in front of image/gif to get a higher "priority"
(find first) than image/gif for those cases when a web-server is able to
make a choice (W3C's jigsaw has such a feature (but jigsaw has no problem
since V2.x
because jigsaw has a new resource attribute called "quality", e.g. PNG gets a
higher "quality" than image/gif, and the web-server delivers png if there
is the choice beween png and gif... But not all web-servers have such
compex features, sometimes there's only "first match"...).
----
Bye,
Roland
P.S.: It is very urgend bug-to-be-fix-request because our development can
currently only use IE 5.0 for testing because Mozilla 5.0 is only identified as
a HTML only browser...
(and sorry for my bad english)
Comment 3•26 years ago
|
||
I have a test page for what HTTP headers you are sending:
http://www.fas.harvard.edu/~dbaron/html/httpreq
It may be useful for this.
Comment 4•26 years ago
|
||
setting paulmac as QA contact for all gagan's bugs (sorry for the spam)
Updated•26 years ago
|
Assignee: gagan → ebina
Status: ASSIGNED → NEW
Comment 5•26 years ago
|
||
Eric can you help with this one.
Sure. I see no reason not to change the accept header as described.
I wish I knew why we weren't sending text/html in accept already.
Comment 7•26 years ago
|
||
Re: the above comment that putting image/png earlier will give it higher
priority. I don't think that's true. The priority is determined from quality
ratings (;q=...). See RFC 2068 ( http://info.internet.isi.edu/in-
notes/rfc/files/rfc2068.txt ), section 14.1.
However, I'm not sure if servers support this. Of course, not very many pages
even use content negotiation. It would be nice if Mozilla supported it
correctly. This includes sending a bunch of other headers - see the headers
that exist in
http://www.fas.harvard.edu/~dbaron/html/httpreq
and also in the HTTP RFC.
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Fixed to change the accept header as suggested in version 1.41 of
mozilla/network/protocol/http/mkhttp.c;
Updated•26 years ago
|
Status: RESOLVED → VERIFIED
Comment 9•26 years ago
|
||
confirmed that text/xml is now in the accept header, marking verified
Reporter | ||
Comment 10•26 years ago
|
||
What about adding text/css and text/css2 in the accept header;
and what about the idea of a boolean in the plugin-"database" which says that
the mime-type of this plugin should appear in the accept:-header ?
Comment 11•26 years ago
|
||
I don't think there's any such type as "text/css2". CSS2 should be sent
as "text/css". Forward compatible parsing means a CSS1 parser should be fine.
Comment 12•26 years ago
|
||
Any anyway, you don't want "text/css" for the main document, you want it for
the stylesheet, and the stylesheet type is announced in the document. type is
supposed to be on any stylesheet links (I think), so it shouldn't be negotiated.
Leaving as verified fixed. Further issues should probably go in a new bug,
anyway.
You need to log in
before you can comment on or make changes to this bug.
Description
•