153685 - Content negotiation sends Mozilla an XSLT transformation instead of document

Status: RESOLVED FIXED

(Tech Evangelism Graveyard :: English US, defect)

Description

[Henri Sivonen (:hsivonen)]

The W3C has links to http://www.w3.org/DOM/faq as opposed to
http://www.w3.org/DOM/faq.html. They also have other resources there:
http://www.w3.org/DOM/faq.xml and http://www.w3.org/DOM/faq.xsl. Apparently,
they also have mod_negotiation enabled.

As a result, they serve the XSLT transformation sheet when Mozilla requests
http://www.w3.org/DOM/faq

The right thing to do would be serving the HTML file (accomplished by setting
the source quality of the other files to zero or by moving/renaming them). It
doesn't make sense to serve the transformation file, because the transformation
is not an alternate version of the document. It does not make sense to serve the
source XML file, because it uses a private vocabulary and, therefore, can not be
rendered in a useful way by a user agent that does not have a priori knowledge
about that vocabulary.

Mozilla prefers the XML content types over text/html (in the HTTP Accept
header), but only in order to receive documents marked up using vocabularies
that an user agent can be can be expected to have a priori knowledge about (eg.
XHTML and MathML).

Comment 1

[Jim Ley]

Whilst serving up the xsl file is clearly wrong by the w3 (has anyone told the 
www-dom folks?)  this is also a mozilla error, accepting text/xml or 
application/xml over text/html or application/xhtml+xml is clearly flawed, the 
first two general xml versions have no reason to be understandable by humanss. 
Mozilla signifies it's preference for XHTML via the correct mime-type, 
application/xml is not correct for specifying the preference for xhtml.  

The only problem is with standalone MathML which doesn't have a mime-type, and 
it's probably reasonable to want this over a html version, I don't yet believe 
that is a common enough scenario, and is really caused by the W3 not having 
registered a mime-type.

This is also a Mozilla bug IMO, not just tech-evangelism.

Comment 2

[Pratik]

I got the following mail from Philippe. Copying it here for others to see.

---------------------
Subject: Bug 153685  Content negotiation sends Mozilla an XSLTtransformation
instead of document
Date: Wed, 24 Jul 2002 8:31 EST
From: Philippe Le Hegaret <[e-mail]>
  To:[e-mail]
  Cc:[e-mail], [e-mail]


[[
The W3C has links to http://www.w3.org/DOM/faq as opposed to
http://www.w3.org/DOM/faq.html. They also have other resources there:
http://www.w3.org/DOM/faq.xml and http://www.w3.org/DOM/faq.xsl.
Apparently, they also have mod_negotiation enabled.
]]

Yes, we are using the mod_negociation. I don't understand why we are
making a difference between text/xml and application/xml though.

[[
Whilst serving up the xsl file is clearly wrong by the w3 (has anyone
told the www-dom folks?)
]]

Obviously, someone did :)
I moved away the file since it is not even used by faq.xml.

Philippe
-- 
Philippe Le Hegaret - http://www.w3.org/People/LeHegaret/
World Wide Web Consortium (W3C), DOM Activity Lead

Comment 3

[Henri Sivonen (:hsivonen)]

CCing Gerv (The Official Guardian of the Accept Header) and Hixie.

There are two view points here:

1) Mozilla shouldn't Accept text/xml or application/xml (or at least shouldn't
prefer them), because content served with those content types might use markup
with no agreed-upon and known semantincs.

OR

2) Mozilla should continue to prefer all the XML content types, since adding a
new MIME type for each new agreed-upon application of XML isn't as feasible as
serving as application/xml and detecting namespaces. Servers shouldn't serve
content whose markup doesn't have widely known and agreed-upon semantics as a
result of content negotiation.

Opinions?

(Clearly, preferring application/xhtml+xml isn't an issue here. Mozilla should
continue to prefer it now that forms work again, since preferring it is required
for dealing with IE's inability to do the Right Thing with XHTML + MathML
without resorting to UA sniffing nor to XSLT.)

For the record, the only major site that has shown problems with Accepting
text/xml is www.w3.org. The only other know case has been some relatively
unknown Danish golf site.

Comment 4

[Gervase Markham [:gerv]]

I'd plump for option 2, based on what I read so far in this bug. Adding xml MIME
types individually to Accept: just won't fly.

Gerv

Comment 5

[Jim Ley]

I don't understand this "adding of mime types" issue that's a concern, what xml 
formats are there mozilla understands the semantics of, which do not have a 
mime-type I believe it's only MathML, so the issue is purely MathML.  If in the 
future the W3 (or anyone else) develops a XML vocabulary with "widely known and 
agreed-upon semantics as a result of content negotiation." then the server 
would be fully justified in serving it up, however Mozilla wouldn't have a clue 
what to do with it.

You're fixing the accept headers for "agreed and known semantics" at the point 
of mozilla being shipped, the lifetime of a mozilla browser can be 10 years, 
whole new formats may arise in that time where text/html is the only one 
mozilla 1.1 has a hope of rendering.

Equally a server has to respect the accept headers of the client, if the client 
says they prefer text/xml over text/html, the server should give it, if 
contains the same semantic information there's no reason not to believe a 
client requesting knows what to do with it.  Mozilla is not in a position to 
dictate what servers choose to send in a content-negotiated sitauation.

Almost certainly the reason we don't have content negotiation of text/xml 
formats is because server users of content negotiation are clueful enough that 
text/xml is such a catch all as to be useless.  Just like giving a preference 
for application/octetstream is silly, text/xml covers too much with unknown 
semantics.

I'd vote for default to text/html with higher q value, but make the user aware 
of the contents of the vary header so they know of alternate representations, 
(and can access them obviously).

Comment 6

[Gervase Markham [:gerv]]

> so the issue is purely MathML.

MathML, SVG, XSLT, XUL...

Gerv

Comment 7

[Jim Ley]

>> so the issue is purely MathML.
>
>MathML, SVG, XSLT, XUL...

Is SVG on trunk? in any case image/svg+xml may not be registered, but it's what 
SVG is being delivered as, - What exactly is mozilla going to do with "XSLT" 
when there's an HTML version available - and as for XUL, if that doesn't have a 
mime-type give it one!

Comment 8

[Gervase Markham [:gerv]]

> Is SVG on trunk? 

Hopefully it will be soon.

> in any case image/svg+xml may not be registered, but it's what 
> SVG is being delivered as, - What exactly is mozilla going to do with "XSLT" 
> when there's an HTML version available 

I mean, there is an argument that the Accept: header should specify that we
support client-side XSLT style sheets (in the same way we currently Accept
text/css).

> - and as for XUL, if that doesn't have a 
> mime-type give it one!

The MIME type for XUL is application/vnd.mozilla.xul+xml . My point is that we
can't put the specific MIME types for all the XML types we understand in the
Accept: header, because that would make it too long.

Gerv

Comment 9

[Hixie (not reading bugmail)]

There's a huge can of worms here. Basically, MIME isn't good enough to cope with
mixed namespace content and we don't want to baloon our Accept headers, so we're
using text/xml as a catch-all for XML content.

I can see an argument for making application/xhtml+xml have a higher q level
than text/xml, but doing that simply starts us down the path of listing all our
supported MIME types and that leads to madness. (Not to mention that there's no
way to say that XHTML+MathML is better than XHTML on its own.)

Basically, though, if the server has text/xml content which it knows is of a
much lower quality level than the HTML alternative, then it should serve that to
us, since we only say that text/html is q=0.9 compared to text/xml's q=1.

I think what we are doing is fine.

Comment 10

[Hixie (not reading bugmail)]

Note that Henri's comments at the top of this bug ("The right thing...") exactly
represent my views as well.

Comment 11

[Peter Van der Beken [:peterv]]

http://www.w3.org/DOM/faq is now fixed, it sends http://www.w3.org/DOM/faq.xml
which is XML styled with CSS.

Comment 12

[Bob Clary [:bc] (inactive)]

thanks Peter.