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)

Product:
Core
Component:
XML
Type:
defect

Tracking

()

Status:
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.