Last Comment Bug 155730 - (*/*+xml) Mozilla doesn't handle files served as */*+xml as XML files
(*/*+xml)
: Mozilla doesn't handle files served as */*+xml as XML files
Status: NEW
[Hixie-P2] Please read comment 6
: helpwanted, xhtml
Product: Firefox
Classification: Client Software
Component: File Handling (show other bugs)
: unspecified
: All All
: -- normal with 43 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: :Paolo Amadini
Mentors:
http://www.maths-informatique-jeux.co...
: 223584 261404 287264 (view as bug list)
Depends on:
Blocks: 535827 application/rdf+xml 160882 209637 249153 256379
  Show dependency treegraph
 
Reported: 2002-07-04 00:12 PDT by Dominique Hazaël-Massieux
Modified: 2016-08-19 12:22 PDT (History)
55 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Make htmlparser deal with content types that end by +xml (4.50 KB, patch)
2009-07-12 05:18 PDT, Frédéric Wang (:fredw)
no flags Details | Diff | Splinter Review
Try first approach: "*/*+xml" => "application/xml" (9.33 KB, patch)
2009-11-14 05:47 PST, Frédéric Wang (:fredw)
no flags Details | Diff | Splinter Review
First approach: "*/*+xml" => "application/xml" (9.95 KB, patch)
2009-11-16 10:41 PST, Frédéric Wang (:fredw)
no flags Details | Diff | Splinter Review
First approach: "*/*+xml" => "application/xml" (12.01 KB, patch)
2009-11-19 09:54 PST, Frédéric Wang (:fredw)
no flags Details | Diff | Splinter Review

Description Dominique Hazaël-Massieux 2002-07-04 00:12:48 PDT
RFC 3023 defines a mechanism to identify all the XML mime types through the use
of the suffix +xml. It spefically cites the case of browsers to use this mechanism:
"
Some areas where 'generic' processing is useful include:

   o  Browsing - An XML browser can display any XML document with a
      provided [CSS] or [XSLT] style sheet, whatever the vocabulary of
      that document.
"
Thus, Mozilla should handle any mime-type ending with +xml as a generic XML
document. 

Right now, it proposes to download it or to open it with another application. 

Test case: http://www.nimbustier.net/misc/test-rfc3023.php
This document is served as application/rdf+xml even though its content is really
XHTML. Since Mozilla doesn't handle (yet) this being registered RDF specific
Mime-Type, it should probably handle it as generic XML.

I'm not sure if it should or not treat it as XHTML since it is not served with
the appropriate mime type (I'll investigate).
Comment 1 Christopher Hoess (gone) 2002-07-04 09:26:44 PDT
I seem to recall that the "*/*+xml" pattern can theoretically include MIME-
types that aren't XML-based, and that UAs should deal with these types on a 
case-by-case basis. I can't find the reference right now, however.
Comment 2 Mike Young 2002-07-04 23:28:55 PDT
No, the purpose of +xml is specifically so that a UA should NEVER have to parse
the file to ascertain its MIME type. from RFC 3023:

A.4 Why not just have the MIME processor 'sniff' the content to
    determine whether it is XML?

   Rather than explicitly labeling XML-based media types, the processor
   could look inside each type and see whether or not it is XML.  The
   processor could also cache a list of XML-based media types.

   Although this method might work acceptably for some mail
   applications, it would fail completely in many other uses of MIME.
   For instance, an XML-based web crawler would have no way of
   determining whether a file is XML except to fetch it and check.  The
   same issue applies in some IMAP4[RFC2060] mail applications, where
   the client first fetches the MIME type as part of the message
   structure and then decides whether to fetch the MIME entity.
   Requiring these fetches just to determine whether the MIME type is
   XML could have significant bandwidth and latency disadvantages in
   many situations.

   Sniffing XML also isn't as simple as it might seem.  DOCTYPE
   declarations aren't required, and they can appear fairly deep into a
   document under certain unpreventable circumstances.  (E.g., the XML
   declaration, comments, and processing instructions can occupy space
   before the DOCTYPE declaration.) Even sniffing the DOCTYPE isn't
   completely reliable, thanks to a variety of issues involving default
   values for namespaces within external DTDs and overrides inside the
   internal DTD.  Finally, the variety in potential character encodings
   (something XML provides tools to deal with), also makes reliable
   sniffing less likely.
Comment 3 Christopher Hoess (gone) 2002-07-09 11:53:10 PDT
Oops. My memory was of bug 124709 comment 12. I'd still want to check with one of 
the XML-heads like Simon St. L. before going ahead with this, but my opinion is 
tipping towards this as being The Right Thing.
Comment 4 Hixie (not reading bugmail) 2002-11-08 07:17:47 PST
->networking
Comment 5 Doug Turner (:dougt) 2002-11-08 09:07:13 PST
harish, jst, any idea?
Comment 6 Boris Zbarsky [:bz] (still a bit busy) 2002-11-08 10:40:13 PST
There are at least two ways we could probably fix this (I could maybe come up
with more creative ones if needed, probably involving stream converters):

1)  Rewrite the content dispatch system to be smarter than just doing an exact
    string match on the content type (a worthwhile goal anyway)
2)  Have the HTTP channel change any */*+xml type to text/xml (which is
    what the data _should_ be being served as anyway, imo)
Comment 7 Hixie (not reading bugmail) 2002-11-08 13:17:59 PST
Well, the RFC is normative and says that */*+xml should go to our XML parser, so
I think the first is more correct.

We don't want to be lying in other parts of the code, e.g. Page Info, for example.
Comment 8 Boris Zbarsky [:bz] (still a bit busy) 2002-11-08 16:55:42 PST
Yeah, I know the first is more correct....  Note the word "rewrite" and the
"really fragile code" part I left out..... ;)
Comment 9 Doug Turner (:dougt) 2002-11-20 10:19:36 PST
over to ian.
Comment 10 Hixie (not reading bugmail) 2002-11-20 22:44:43 PST
I'm baffled as to why this was assigned to me, since my role in the Mozilla
project has settled into that of QA, not engineer.

->nobody@mozilla.org
Comment 11 Doug Turner (:dougt) 2002-11-21 06:51:37 PST
ian, I am sorry.  lets move it to the XML component for now.
Comment 12 Henri Sivonen (:hsivonen) 2002-12-11 15:03:30 PST
The places where Mozilla handles the XML types can be seen in the patch for bug
160882.
Comment 13 Boris Zbarsky [:bz] (still a bit busy) 2003-10-24 13:33:18 PDT
*** Bug 223584 has been marked as a duplicate of this bug. ***
Comment 14 Hrotkó Gábor 2003-11-18 05:27:24 PST
Hi!

If you have a file with the extension .foo, and the header is like this:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="some.xsl"?>
<!DOCTYPE html    PUBLIC "-//W3C//DTD XHTML 1.1 plus MathML 2.0//EN"
           "http://www.w3.org/Math/DTD/mathml2/xhtml-math11-f.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head> ...

and you open the file locally like file:///C:/somefile.foo, mozilla will threat
it like an xml file. But when you open it from a server, like :
http://someserver.net/somefile.foo , mozilla will show the source only.
It should be fixed, to be correct in Firebird too.

Thanx
Comment 15 Boris Zbarsky [:bz] (still a bit busy) 2003-11-18 06:26:04 PST
You're right -- the server that sends a text/plain type for such a file should
be fixed.  Mozilla's behavior there is absolutely correct.
Comment 16 Alan Plum 2003-11-18 21:24:34 PST
Yupp. The server needs to have set an XML MIME type for .foo files like this (in
.htaccess):
AddType application/x-foo+xml .foo

However the above is not recognized as an XML MIME type by Mozilla yet, so
THAT's what this bug report is all about. For now, stick to this:
AddType application/xml .foo
Comment 17 Hixie (not reading bugmail) 2004-02-22 15:58:18 PST
biesi: Isn't this a file dispatch bug?
Comment 18 Christian :Biesinger (don't email me, ping me on IRC) 2004-02-23 04:22:42 PST
hixie: true, per comment 6. although per that comment it could be an http bug as
well, but that seems like a suboptimal solution.

we could probably check if the content type ends with +xml in uriloader and map
that to text/xml or something... but would that be a good idea?

(would that require changse to the xml parser as well?)
Comment 19 Hixie (not reading bugmail) 2004-02-23 04:36:52 PST
biesi: So long as it doesn't break things like Page Info. See comment 7.

(Indicentally, note that text/xml and application/xml (and */*+xml) have 
different rules for defaulting the character encoding.)
Comment 20 Christian :Biesinger (don't email me, ping me on IRC) 2004-02-23 06:09:02 PST
(In reply to comment #19)
> biesi: So long as it doesn't break things like Page Info. See comment 7.

Of course. If it was done in a way that breaks page info, I would not be
concerned about requiring xml parser changes.

> (Indicentally, note that text/xml and application/xml (and */*+xml) have 
> different rules for defaulting the character encoding.)

all three have different ones from each other?
Comment 21 Hixie (not reading bugmail) 2004-02-23 07:30:53 PST
Depends on the text/ vs application/ bit iirc. See RFC3023.
Comment 22 Boris Zbarsky [:bz] (still a bit busy) 2004-02-23 09:42:56 PST
You'll need to change nsParser, yes.
Comment 23 Christian :Biesinger (don't email me, ping me on IRC) 2004-02-23 13:39:24 PST
(In reply to comment #22)
> You'll need to change nsParser, yes.

isn't our architecture lovely.
Comment 24 Boris Zbarsky [:bz] (still a bit busy) 2004-02-23 14:32:22 PST
Well.. the parser actually has some call to handle MIME types.  It's the
nsContentDLF crap that should really go.

In fact, it would be great if we could do that....
Comment 25 Anne (:annevk) 2004-08-09 00:01:49 PDT
I think we want to support bug 61839 ('application/rdf+xml') in a general way in
the end, not hardcoded.

By the way, isn't the handling of character encoding identical for
'application/xml' and '+xml' MIME types, UTF-8?

I thought that only 'text/xml' was different (it is now in proces of being
deprecated) since over HTTP it should be read as US-ASCII (when served without
an explicit 'charset' parameter) and should be read as UTF-8 when loaded from a
local file system.
Comment 26 Chris Hubick 2004-08-19 16:33:36 PDT
FYI: This bug is leading to problems like bug 249153 when the OS maps .xslt to
application/xslt+xml.
Comment 27 HARUNAGA Hirotoshi 2004-10-01 00:54:03 PDT
*** Bug 261404 has been marked as a duplicate of this bug. ***
Comment 28 Jan Egil Kristiansen 2005-02-10 04:05:18 PST
The Piggu Bank side bar for Firefox (http://simile.mit.edu/piggy-bank/) can now
browse RDF. But surfing stops when one RDF links to another. (Try Piggy bank at
http://www.wiwiss.fu-berlin.de/suhl/ueber_uns/hauptseite_ueber_uns.htm, focus on
any *.rdf item, and try to navigate its link.)
Comment 29 Anne (:annevk) 2005-02-10 04:16:45 PST
Please use a recent build when you are testing something. 'application/rdf+xml'
has been supported for some time now. It is also useful to read the entire bug
first, for example comment 25 which mentions that the RDF MIME type is supported.
Comment 30 Jan Egil Kristiansen 2005-03-14 02:05:35 PST
(In reply to comment #29)
> Please use a recent build when you are testing something.
> 'application/rdf+xml'
> has been supported for some time now.
I.e. supported in nightly builds? It certainly doesn't work in my 1.0.1 on
Windows 2000. (Should Bugzilla differentiate between "fixed in nightly build"
and "fixed in production build" ?)
> It is also useful to read the entire bug
> first, for example comment 25 which mentions that the RDF MIME type is supported.

Bug 61839 is mainly about "text/rdf", no "application/rdf+xml" ?

>
Comment 31 Anne (:annevk) 2005-03-14 06:26:41 PST
(In reply to comment #30)
> I.e. supported in nightly builds?

Obviously.


> It certainly doesn't work in my 1.0.1 on Windows 2000.

That is not a nightly build.


> (Should Bugzilla differentiate between "fixed in nightly build"
> and "fixed in production build" ?)

Probably not. Bugzilla is not for end users.


> Bug 61839 is mainly about "text/rdf", no "application/rdf+xml" ?

Have you even read the summary? (Not to mention you should always read the
entire bug, including all of its comments, before making assumptions or
conclusions that aren't justified.
Comment 32 Anne (:annevk) 2005-03-22 14:05:02 PST
*** Bug 287264 has been marked as a duplicate of this bug. ***
Comment 33 Phil Ringnalda (:philor) 2005-08-08 08:45:44 PDT
Probably a stupidly obvious comment, but not my first: when people are saying
"just map application/*+xml to (text|application)/xml," they do mean "after
checking to see whether the OS knows about a registered handler for that type,
since that's why it's being sent as *+xml," don't they?
Comment 34 Hixie (not reading bugmail) 2005-09-29 10:55:18 PDT
*** Bug 209637 has been marked as a duplicate of this bug. ***
Comment 35 chris 2005-10-28 01:53:46 PDT
Here is a test case.It deliberately uses a bogus media type that is not registered (but has +xml)
http://www.w3.org/2005/10/SVGinXHTML.foobar
Comment 36 Mark Baker 2006-04-20 08:40:14 PDT
My concern here is that "as XML files" is ambiguous.  Mozilla already dispatches XML documents to handlers based on namespaces for the application/xml media type, but it's another thing altogether to assume that can be done for arbitrary */*+xml types, since not every XML based format works that way.

Consider the following Atom sub-document;

   <content type="application/rdf+xml">
      <xhtml:div xmlns:xhtml="http://www.w3.org/1999/xhtml">
         <xhtml:b>Hello there</xhtml:b>
      </xhtml:div>
   </content>

That's an example of a perfectly valid Atom content element, containing a perfectly valid RDF/XML document.  But if it were interpreted using namespace dispatching, then that would be inconsistent with the Atom specification which prescribes that it's to be interpreted as an RDF/XML document.

Moreover, RDF/XML documents by themselves, without an encapsulating rdf:rdf envelope, would also be misinterpreted.

This is just to show that not every document described with an XML media type can be understood by using namespace dispatching.  That said, if Mozilla wanted to throw up an XML tree view on unknown */*+xml types, to provide some generic XML handling capabilities, that would be fine by me, and better than the application/octet-stream "save as dialog" fallback behaviour that exists today.
Comment 37 Michael Newton 2006-04-20 09:08:01 PDT
When I voted for this bug, that's what I assumed would be the eventual fix.  Just a tree view for unknown MIME types that have +xml at the end.
Comment 38 Mark Baker 2006-04-20 21:59:54 PDT
(In reply to comment #37)
> When I voted for this bug, that's what I assumed would be the eventual fix. 
> Just a tree view for unknown MIME types that have +xml at the end.
> 

That's great, thanks.  FWIW, Opera displays, for example, an XHTML document sent as "application/foobar+xml", as XHTML.  I was concerned that Mozilla might be considering doing that too.
Comment 39 Alan Plum 2006-04-21 01:36:24 PDT
*/*+xml means the document contains XML data and should be treated as such if the client does not know any better.

If a client has an application/rdf+xml specific parser, that's what should be doing the work -- nothing wrong about that.

The key words here are "hierarchy" and "fallback". application/xhtml+xml is application/xhtml+xml first and */*+xml second. An XML capable client which does not know application/xhtml+xml should treat it as */*+xml.

The problem may also be the lack of namespace recognition -- if the root namespace is known, the document should probably be treated the same as if the MIME type were that expected the */*+xml one expected for documents with that root namespace.

However, namespace recognition is a problem not related to the */*+xml fallback mechanism, although it would improve its usefulness a great lot.

As for that problem, I'd definitely suggest that a known namespace within an unknown root namespace should NOT trigger any specific behaviour, although the other way (unknown within known) probably should. You wouldn't want to render something as XHTML if you don't know the namespace of the elements wrapping it -- plus that could get ugly at times and produce unexpected behaviour.
Known namespaces within known namespaces should pose no problem, though -- MathML and SVG show that rather nicely already.
Comment 40 Frédéric Wang (:fredw) 2009-07-12 05:18:17 PDT
Created attachment 388134 [details] [diff] [review]
Make htmlparser deal with content types that end by +xml

	I would like this to be fixed because it blocks bug 124709 and bug 152001 for MathML. Here is a first patch for htmlparser/src but it is not sufficient. I made a test with a document of content type "application/mathml+xml". The function net_ParseMediaType recognizes it but CParserContext::SetMimeType is never called. Does anyone know the other parts to modify?
Comment 41 Frédéric Wang (:fredw) 2009-10-24 14:45:04 PDT
I've had a look to this bug again. nsDocumentOpenInfo::DispatchContent retrieves the right mContentType ("application/mathml+xml" for the URL I gave) from aChannel, but all attempts to dispatch the content fail.
Comment 42 Boris Zbarsky [:bz] (still a bit busy) 2009-10-26 19:34:26 PDT
Right.  That's part of the code I'm talking about in comment 6 item 1.  Luckily, that code is a lot less fragile now than it was in 2002.... ;)

If you want to preserve the */*+xml content-type end-to-end I think you have three main options.

1)  Dispatch using a type different from the type set on the channel (e.g. using
    application/xml).  The document will pick up the type from the channel.
    This might be worth trying as a first cut to see whether you get the right
    behavior.
2)  Propagate both the "real" type and the type to dispatch on through the
    whole dispatch chain.
3)  Change dispatch to allow dispatch on */*+xml (either just that, or some sort
    of general pattern-matching setup; I would probably avoid the latter for
    now).  You'd probably need to edit
    nsWebNavigationInfo::IsTypeSupportedInternal (probably a good idea with
    either of the other approaches too), nsDocShell::NewContentViewerObj, plus
    the code your patch edits.  I _think_ this might be enough....

Oh, and depending on the behavior desired for */*+xml, you may need to edit nsExternalResourceMap::PendingLoad::SetupViewer as well.  It seems there's a fair amount of argument about whether it's ok to treat */*+xml the same way as we treat application/xml here....
Comment 43 Frédéric Wang (:fredw) 2009-11-14 05:45:23 PST
Thanks Boris,

I've tried suggestion 1. Dispatching all "*/*+xml" using "application/xml" seems to give the right behaviour: unknown XML are displayed as a tree while the others (XHTML or MathML for instance) are rendered as usual. But I guess it is not really correct to use this method (for example, I have to exclude "application/vnd.mozilla.xul+xml" not to get trouble with XUL windows), so I'll rather try suggestion 3 and see what I need to modify to get the same behaviour as "application/xml"...
Comment 44 Frédéric Wang (:fredw) 2009-11-14 05:47:15 PST
Created attachment 412391 [details] [diff] [review]
Try first approach: "*/*+xml" => "application/xml"
Comment 45 Boris Zbarsky [:bz] (still a bit busy) 2009-11-14 07:32:15 PST
> for example, I have to exclude "application/vnd.mozilla.xul+xml" not to get
> trouble with XUL windows

You wouldn't need that if you just moved that block lower down in the function (after the "fifth step" part, and right before we'd go out to the helper app service).

Though even that is somewhat questionable: if I have a helper app for a particular +xml type, should we use that helper app, or treat the data as plain xml?  But that's a question about the basic goals of this bug...
Comment 46 Mark Baker 2009-11-14 12:54:41 PST
As I mentioned earlier, you guys need to reconsider what "treat as plan xml" means.  You are currently assuming it means more than it is specified to mean and are running into some of the problems with that assumption. There is simply no guarantee that all existing or future XML languages have to use a specific namespace as their root element.  See XSLT or RDF/XML.

I think the correct approach here that will cause the least harm, is to turn off namespace dispatching for application/xml, and only enable it for those XML languages that have specified its use or else for which a majority of implementations agree to use it.  I suppose application/xhtml+xml might be at that point already, but haven't done any testing recently.
Comment 47 Boris Zbarsky [:bz] (still a bit busy) 2009-11-14 14:18:29 PST
> you guys need to reconsider what "treat as plan xml" means

That's really outside the scope of this bug.  If you have a problem with the way application/xml is handled, file a separate bug.

In any case, this is not relevant to the issue I raise in comment 45 paragraph 2.

> There is simply no guarantee that all existing or future XML languages have to
> use a specific namespace as their root element

That's fine; nowhere do we make the assumption that they have to do so.

> turn off namespace dispatching for application/xml

We don't perform "namespace dispatching".  What we _do_ do is that if a document is dealt with via parsing into a DOM and then rendering the DOM then we use the semantics and default presentation defined by the namespaces for the elements in that DOM.  It sounds like you think that application/xml should not be parsed into a DOM and presented this way.  As I said, that's a separate issue from this bug.  The only root element namespaces that are special-cased in any of this process are the XUL and SVG ones, because those don't use the CSS formatting model for the document and hence have to have different formatting objects created for the root element (e.g. no viewport scrollbars for XUL).
Comment 48 Frédéric Wang (:fredw) 2009-11-16 10:41:49 PST
Created attachment 412635 [details] [diff] [review]
First approach: "*/*+xml" => "application/xml"

(In reply to comment #45)
> You wouldn't need that if you just moved that block lower down in the function
> (after the "fifth step" part, and right before we'd go out to the helper app
> service).

I moved this block, but then I only try step 1 again with this "application/xml" type. I would have imagined that I also need to try the other steps 2-5...

> Though even that is somewhat questionable: if I have a helper app for a
> particular +xml type, should we use that helper app, or treat the data as plain
> xml?  But that's a question about the basic goals of this bug...

If displaying the xml tree is the fallback when we don't know at all what to do with a document, then I suppose that an available helper app should be used instead. However, the author of an XML document may also provide a stylesheet with his document, and in that case he certainly expects that his document is displayed by the browser...
Comment 49 Boris Zbarsky [:bz] (still a bit busy) 2009-11-16 10:58:02 PST
> then I only try step 1 again

What you should probably do instead is something along the lines of what ConvertData does: create a new nsDocumentOpenInfo, set its mContentType to application/xml, set it as our m_targetStreamListener and return.  Then it'll handle going through all the steps with the application/xml type.

> However, the author of an XML document may also provide a stylesheet
> with his document, and in that case he certainly expects that his document is
> displayed by the browser...

Yep.  There's just no good way to win this one...  no matter what we do, it's pretty easy to construct a scenario where that's the "wrong" behavior.  :(
Comment 50 Frédéric Wang (:fredw) 2009-11-19 09:52:51 PST
(In reply to comment #49)
> What you should probably do instead is something along the lines of what
> ConvertData does: create a new nsDocumentOpenInfo, set its mContentType to
> application/xml, set it as our m_targetStreamListener and return.  Then it'll
> handle going through all the steps with the application/xml type.

It's what the patch does now, thanks for the hint. So now that the alternative content type "application/xml" is only used as a replacement for unknown XML content types, I wonder whether it is really necessary to try option 2 or 3. If we really want the same behavior as "application/xml", I don't think it's worth to duplicate the code. One thing that I would have imagined is to extract the "*/*" part from "*/*+xml" to give a special behavior when "*/*" is known, but section A.13 of RFC 3023 clearly says not to do that.

> Yep.  There's just no good way to win this one...  no matter what we do, it's
> pretty easy to construct a scenario where that's the "wrong" behavior.  :(

I don't know whether it is a correct assumption, but it seems to me that files that are likely to be handled by an helper app are mostly binary files. Hence I guess it is not too dramatic if Gecko displays all unknown XML files, and anyway that's what RFC 3023 suggests to do. If it happens that a XML format needs to be handled by an helper app and that people start to complain, then the only reasonable things I see is to add an option "try to open with an helper app" while displaying the tree (or any other configuration options). But I don't believe it is necessary to do that for the moment.

+#define NS_IS_STAR_SLASH_STAR_PLUS_XML(S, L)\
+  (L >= 4 && !strncmp(S + L - 4, "+xml", 4) && memchr(S, '/', L - 4))

A word about the NS_IS_STAR_SLASH_STAR_PLUS_XML macro. First is it OK to use a macro, or should I write a function or do anything else instead? I put it in netwerk/mime/public/nsMimeTypes.h since it seems to be the place where all MIME types are stored (*). I use memchr rather strnchr, because the latter does not seem to work on my platform. Last but not least, the search for '/' is probably going to work only for US-ASCII encoding, is it safe to assume that the content type uses this encoding?

(*) BTW, maybe it's better to use the macros from nsMimeTypes.h in place of those from filesparser/htmlparser/public/nsIParser.h and of the hardcoded strings in layout/build/nsContentDLF.cpp. Do you want I do this change? Maybe in a separate bug/patch?
Comment 51 Frédéric Wang (:fredw) 2009-11-19 09:54:42 PST
Created attachment 413375 [details] [diff] [review]
First approach: "*/*+xml" => "application/xml"
Comment 52 Boris Zbarsky [:bz] (still a bit busy) 2009-11-19 10:07:45 PST
> I wonder whether it is really necessary to try option 2 or 3. 

You mean from comment 42?  Probably not, though the current setup is a little weird in that you ask consumers whether they can consume application/xml and then send them some other type.  In practice, it probably doesn't matter since there's a consumer who gets first crack at application/xml and you've changed that consumer.

> files that are likely to be handled by an helper app are mostly binary files.

Well, sure.  I was specifically talking about files with a */*+xml type that a helper app is registered for.  Maybe I shouldn't worry about this; what +xml types are actually used in practice?

> A word about the NS_IS_STAR_SLASH_STAR_PLUS_XML macro.

Now that you mention it...  Do we need to do anything more than StringEndsWith(mContentType, NS_LITERAL_CSTRING("+xml"))?  Checking for the '/' seems a little redundant to me; if someone is sending a MIME type without a '/' (_and_ our MIME type parser accepts it) I'm not sure I care about not dispatching it as XML.  ;)

> is it safe to assume that the content type uses this encoding

Yes.

> Do you want I do this change? Maybe in a separate bug/patch?

Yes and yes.
Comment 53 Phil Ringnalda (:philor) 2009-11-19 11:44:49 PST
(In reply to comment #52)
> Maybe I shouldn't worry about this; what +xml
> types are actually used in practice?

Assuming this isn't planning on breaking the Firefox feed handler for application/atom+xml and application/rss+xml (and application/rdf+xml, if we're still sniffing that), I'd guess the one that will get the first screams from nightly users would be vnd.google-earth.kml+xml, followed by maybe application/vnd.adobe.xdp+xml or the application/vnd.openxmlformats-officedocument.* things.
Comment 54 Boris Zbarsky [:bz] (still a bit busy) 2009-11-19 12:25:45 PST
Ah, hmm.  Those sound like a pretty serious problem to me...
Comment 55 Frédéric Wang (:fredw) 2009-11-19 16:27:12 PST
(In reply to comment #52)
> Now that you mention it...  Do we need to do anything more than
> StringEndsWith(mContentType, NS_LITERAL_CSTRING("+xml"))?  Checking for the '/'
> seems a little redundant to me; if someone is sending a MIME type without a '/'
> (_and_ our MIME type parser accepts it) I'm not sure I care about not
> dispatching it as XML.  ;)

Yes, "*+xml" sounds good to me and it makes things simpler. So I guess I can remove this macro and just use 3 times the StringEndsWith function.

(In reply to comment #53)
> Assuming this isn't planning on breaking the Firefox feed handler for
> application/atom+xml and application/rss+xml (and application/rdf+xml, if we're
> still sniffing that), I'd guess the one that will get the first screams from
> nightly users would be vnd.google-earth.kml+xml, followed by maybe
> application/vnd.adobe.xdp+xml or the
> application/vnd.openxmlformats-officedocument.* things.

What about trying to find an helper app before using content-type "application/xml" (i.e. swapping step 6 and 7 in the current patch)?
Comment 56 Boris Zbarsky [:bz] (still a bit busy) 2009-11-19 18:47:02 PST
Step 7 never fails: it always consumes the data.  Specifically, always accepts the data, and then later when it has more information about it does things like prompting the user whether to prompt or use a helper, etc.

Some of this could be rearchitected, but fundamentally you don't know whether you have a helper app until you've asked the user to pick one or confirm that the OS one is desired.
Comment 57 David Baron :dbaron: ⌚️UTC-8 2009-11-19 21:05:06 PST
I think this bug should either:

 (a) be WONTFIX, because Mozilla attempting to handle */*+xml will just make anybody defining new XML-based MIME types not use the +xml syntax to avoid Mozilla's handling (and probably force anybody already using such MIME types to come up with new ones), or

 (b) be fixed by specifically checking for stylesheets as described in comment 0 before attempting to handle the document internally

I strongly prefer (a).
Comment 58 Frédéric Wang (:fredw) 2009-11-20 01:39:16 PST
(In reply to comment #56)
> Some of this could be rearchitected, but fundamentally you don't know whether
> you have a helper app until you've asked the user to pick one or confirm that
> the OS one is desired.

Yes, that's what I feared...

(In reply to comment #57)
> I strongly prefer (a).

As I said in comment 40, my purpose is to fix MathML bugs and the recommended way given in bug 124709 comment 35 is to fix this bug for */*+xml content type. However, I won't really care about the way this bug is resolved. It seems that the main argument in favor of this bug is that we should follow RFC 3023. But from a pragmatic point of view, if people want to display in a browser a generic XML using stylesheets, won't they just send the document as "application/xml"? What are the other arguments in favor of this bug? Is there any real-life problem that requires it to be solved? I think bug 124709 can be solved without it, in the same way as bug 160882 for svg. Bug 256379 seems fixed for me, even the example given in bug 256379 comment 14 works.
Comment 59 Julian Reschke 2009-11-20 01:56:20 PST
This may be slightly off-topic (sorry if it is): 

Many years ago I tried to configure Firefox so that it would treat an XML mime type in the vnd tree by just opening the XML in firefox (applying the supplied XSLT stylesheet). I think this wasn't possible back then, and may not be possible today (but it *was* the default in IE6 back then).
Comment 60 Dominique Hazaël-Massieux 2009-11-20 02:00:28 PST
The reason I reported the bug initially was for a real-life problem: Firefox wouldn’t display application/rdf+xml back then, and would only offer to download it.

It feels like this problem is likely to happen each time a new XML media type is coined or proposed in the /vnd. subree. 

I can surely understand if it’s not practical to fix that problem, but just wanted to make it clear this wasn’t out of architectural purity that this was bug created.
Comment 61 Frédéric Wang (:fredw) 2009-11-20 06:23:04 PST
(In reply to comment #56)
> Step 7 never fails: it always consumes the data.  Specifically, always accepts
> the data, and then later when it has more information about it does things like
> prompting the user whether to prompt or use a helper, etc.
> 
> Some of this could be rearchitected, but fundamentally you don't know whether
> you have a helper app until you've asked the user to pick one or confirm that
> the OS one is desired.

Maybe it would be possible to modify step 7, so that we can retrieve whether the user really wants to display the XML tree? For example if a default helper app is not found and a prompt menu is displayed to ask the user to choose an app, then we can have an entry "display the XML document in the browser" in that menu. We can also add configuration options so that this choice is made automatically for certain content-types?

BTW, I don't think option (b) from comment 57 is good, because this does not take into account the case when we simply want to display the XML tree, without any formatting transformation.
Comment 62 Boris Zbarsky [:bz] (still a bit busy) 2009-11-20 08:39:50 PST
> the recommended way given in bug 124709 comment 35 is to fix this bug for
> */*+xml content type.

Ah.  I think that recommendation was just wrong.  We should simply add the matml type and be done with it.

> configure Firefox so that it would treat an XML mime type in the vnd tree by
> just opening the XML in firefox

This is a separate issue; such configuration for a _specific_ type is trivial with an extension right now, and there's a bug about having it easily available via the dialog that currently offers the "open in a helper or save" options.

> this wasn’t out of architectural purity that this was bug created.

I understand that, yeah.  I think it's not feasible to make this work without breaking things, unfortunately.

> Maybe it would be possible to modify step 7

Yes, absolutely.  There are existing bugs on making the set of choices in that menu richer (e.g. adding "view as text").  It requires some substantial rework (e.g. have to cache all that data while the user is deciding), but there are partial patches with review comments on the bugs that could be picked up by someone interested.  It'd be a lot more work than just adding the mathml type, of course.

If someone is interested, I can pull up the relevant bugs.
Comment 63 Frédéric Wang (:fredw) 2009-11-21 01:57:42 PST
(In reply to comment #52)
> > Do you want I do this change? Maybe in a separate bug/patch?
> 
> Yes and yes.

See bug 530275.

(In reply to comment #62)
> If someone is interested, I can pull up the relevant bugs.

I don't think I'm going to continue to work on this bug for the moment, but please give these references when you have time.
Comment 64 Boris Zbarsky [:bz] (still a bit busy) 2009-11-22 20:13:53 PST
> please give these references when you have time.

Bug 57342.  Make sure to click the "Show Obsolete" link under the attachments pane to see the patches-in-progress.
Comment 65 David Baron :dbaron: ⌚️UTC-8 2009-11-22 21:11:10 PST
(In reply to comment #60)
> The reason I reported the bug initially was for a real-life problem: Firefox
> wouldn’t display application/rdf+xml back then, and would only offer to
> download it.

I think having UI in the XML prettyprinter (and in view source) to allow them to show documents that they don't handle by default would be a better solution for this.  (Could this be done by an extension?)  The XML prettyprinting UI is not a useful default for most of our users.
Comment 66 Tyler Downer [:Tyler] 2009-12-24 20:01:35 PST
*** Bug 535827 has been marked as a duplicate of this bug. ***
Comment 67 Vincent Lefevre 2010-07-29 08:04:09 PDT
(In reply to comment #57)
> I think this bug should either:
> 
>  (a) be WONTFIX, because Mozilla attempting to handle */*+xml will just make
> anybody defining new XML-based MIME types not use the +xml syntax to avoid
> Mozilla's handling (and probably force anybody already using such MIME types to
> come up with new ones), or

I disagree. This bug is not just about dealing with arbitrary */*+xml MIME types, but also specific ones, like "application/vnd.wap.xhtml+xml". This MIME type should really be recognized as XHTML. I recall that bug 209637 (about application/vnd.wap.xhtml+xml) was marked as a duplicate of this bug.

>  (b) be fixed by specifically checking for stylesheets as described in comment
> 0 before attempting to handle the document internally

This wouldn't solve the problem with "application/vnd.wap.xhtml+xml".
Comment 68 Boris Zbarsky [:bz] (still a bit busy) 2010-07-29 08:10:02 PDT
If we wontfix this bug, we should obviously reopen any mis-duped bugs like the one you mention.  That's standard operating procedure, no?

This is why it's better to mark bugs that aren't actually duplicates as dependent instead...  Perhaps worth doing that right now for the bug in question?
Comment 69 Vincent Lefevre 2010-07-29 08:37:14 PDT
(In reply to comment #68)
> If we wontfix this bug, we should obviously reopen any mis-duped bugs like the
> one you mention.  That's standard operating procedure, no?

Yes, but if it isn't reopened now, it's very easy to forget. However...

> This is why it's better to mark bugs that aren't actually duplicates as
> dependent instead...  Perhaps worth doing that right now for the bug in
> question?

Yes, if someone who has the rights (I don't: I'm not the bug submitter) could do this... Thanks.
Comment 70 Boris Zbarsky [:bz] (still a bit busy) 2010-07-29 08:46:33 PDT
OK, done.
Comment 71 thao.ghost.com 2016-05-24 17:06:01 PDT Comment hidden (spam)

Note You need to log in before you can comment on or make changes to this bug.