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)

defect

Tracking

()

VERIFIED FIXED

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)
Assignee: guha → gagan
Taking over...
Setting all current Open Critical and Major to M3
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.
Status: NEW → ASSIGNED
setting paulmac as QA contact for all gagan's bugs (sorry for the spam)
Assignee: gagan → ebina
Status: ASSIGNED → NEW
Eric can you help with this one.
Status: NEW → ASSIGNED
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.
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;
Status: RESOLVED → VERIFIED
confirmed that text/xml is now in the accept header, marking verified
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 ?
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.
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.
Blocks: 12790
You need to log in before you can comment on or make changes to this bug.