Open Bug 155730 (*/*+xml) Opened 22 years ago Updated 6 months ago

Mozilla doesn't handle files served as */*+xml as XML files

Categories

(Firefox :: File Handling, defect)

Product:
Firefox
Component:
File Handling
Type:
defect

Tracking

()

People

(Reporter: dominique.hazael-massieux, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: helpwanted, xhtml, Whiteboard: [Hixie-P2] Please read comment 6)

Attachments

(2 files, 4 obsolete files)

First approach: "*/*+xml" => "application/xml"
12.01 KB, patch
Details | Diff | Splinter Review
Test case v2
282 bytes, application/x.custom+xml
Details
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).
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
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.
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.
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.
QA Contact: petersen → rakeshmishra
Target Milestone: --- → Future
->networking
Assignee: heikki → new-network-bugs
Component: XML → Networking
QA Contact: rakeshmishra → benc
Target Milestone: Future → ---
harish, jst, any idea?
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)
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.
Yeah, I know the first is more correct.... Note the word "rewrite" and the "really fragile code" part I left out..... ;)
over to ian.
Assignee: new-network-bugs → ian
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
Alias: */*+xml
Assignee: ian → nobody
Keywords: helpwanted
Whiteboard: [Hixie-P2]
ian, I am sorry. lets move it to the XML component for now.
Assignee: nobody → heikki
Component: Networking → XML
QA Contact: benc → rakeshmishra
Target Milestone: --- → Future
The places where Mozilla handles the XML types can be seen in the patch for bug 160882.
Blocks: 209637
Keywords: xhtml
QA Contact: rakeshmishra → ashishbhatt
*** Bug 223584 has been marked as a duplicate of this bug. ***
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
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.
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
biesi: Isn't this a file dispatch bug?
Whiteboard: [Hixie-P2] → [Hixie-P2] Please read comment 6
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?)
Assignee: hjtoi-bugzilla → file-handling
Component: XML → File Handling
QA Contact: ashshbhatt → ian
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.)
(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?
Depends on the text/ vs application/ bit iirc. See RFC3023.
You'll need to change nsParser, yes.
(In reply to comment #22) > You'll need to change nsParser, yes. isn't our architecture lovely.
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....
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.
Blocks: application/rdf+xml
FYI: This bug is leading to problems like bug 249153 when the OS maps .xslt to application/xslt+xml.
Blocks: 249153
*** Bug 261404 has been marked as a duplicate of this bug. ***
Blocks: 256379
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.)
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.
(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" ? >
(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.
*** Bug 287264 has been marked as a duplicate of this bug. ***
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?
*** Bug 209637 has been marked as a duplicate of this bug. ***
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
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.
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.
(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.
*/*+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.
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?
Assignee: file-handling → nobody
QA Contact: ian → file-handling
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.
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....
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"...
Assignee: nobody → fred.wang
URL: http://www.maths-informatique-jeux.co... → http://www.maths-informatique-jeux.co...
Attachment #388134 - Attachment is obsolete: true
> 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...
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.
> 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).
(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...
Attachment #412391 - Attachment is obsolete: true
> 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. :(
(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?
> 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.
(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.
Ah, hmm. Those sound like a pretty serious problem to me...
(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)?
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.
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).
(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.
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).
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.
(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.
> 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.
(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.
No longer blocks: 124709
> 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.
(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.
Blocks: 535827
(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".
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?
(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.
OK, done.
Assignee: fred.wang → nobody
blocking-b2g: 2.6? → ---
tracking-b2g: backlog → ---
Flags: needinfo?(thao.ghost.com)
Product: Core → Firefox
Target Milestone: Future → ---
Version: Trunk → unspecified

Yes, but does anyone else anywhere implement it?

(And note that mimesniff is unmaintained and known-wrong about a bunch of things; it needs an editor and a lot of work put into it to be useful.)

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #73)

Yes, but does anyone else anywhere implement it?

(And note that mimesniff is unmaintained and known-wrong about a bunch of things; it needs an editor and a lot of work put into it to be useful.)

I’ve been trying to test Chromium, but I can’t get VirtualBox to work for whatever reason (probably because there’s something else that’s hogging AMD‑V).

And I refuse to install Google spyware directly on my PC.

You can use the following custom-xml.reg file and test.custom-xml files to test whether any browser actually supports this.

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\.custom-xml]
@="xmlfile"
"Content Type"="application/x.custom+xml"

<?xml version="1.0" encoding="UTF-8"?>
<!-- Do not remove this test for UTF-8: if “Ω” doesn’t appear as greek uppercase omega letter enclosed in quotation marks, you should use an editor that supports UTF-8, not this one. -->
<custom-xml>
	Custom XML document.
</custom-xml>
Attached file Test case (obsolete) —
Attachment #9104920 - Attachment mime type: text/plain → application/x.custom+xml

I just tested it, and it more or less works in Safari (on iOS), in that Safari displays it as text, rather than trying to download it.

Same with Firefox for iOS.

Keywords: parity-safari
Attached file Test case v2 —
Attachment #9104920 - Attachment is obsolete: true

I can't test Safari on iOS, but Safari on MacOS does NOT have this behavior. Loading data:application/custom+xml,<root/> does a download instead of treating it as XML. I don't know what exact case you tested on iOS, but if you tested text/something+xml, then what you saw is that Safari basically treats text/anything as text/plain with some special-casing for text/html. It most certainly doesn't implement the behavior this bug is talking about.

As for Chrome, it has the same behavior as Safari as far as I can tell: treat text/anything as text/plain, download application/something+xml.

Keywords: parity-safari
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 4 duplicates, 46 votes and 59 CCs.
:Gijs, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(gijskruitbosch+bugs)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(gijskruitbosch+bugs)

(In reply to Boris Zbarsky [:bzbarsky] from comment #78)

As for Chrome, […]: treat text/anything as text/plain, download application/something+xml.

I'm unable to reproduce downloading behaviour in Chrome.

https://chriscoyier.net/feed/ https://timotijhof.net/feed/ etc
These use WordPress and emit Content-Type: application/rss+xml; charset=UTF-8.

These are visually shown in Chrome, the same as for Atom feeds and JSON feeds.

Safari behaviour varies by macOS version and by what else is installed.
Safari 8-12 (macOS 10.11-10.13) prompts to subscribe in its built-in RSS "Shared Links" lists sidebar.
Safari 13 (macOS 10.14 Mojave+) prompt to open the News app, or if not installed, displays a grey placeholder page indicating that the content type cannot be displayed, with a link to search for RSS apps in the Mac App store.

Mobile Safari iOS 11-16, prompts to open Apple News app, or prompts to search for an RSS app in the App Store.
Mobile Safari iOS 6-9, prompts to search for an RSS app in the App Store.

Firefox places RSS feeds as a file with a seemingly random file name in the Downloads folder.
Atom feeds and JSON feeds are shown visually by Firefox (albeit by accident as Atom tends to be served as text/xml whereas RSS is more widely served with its dedicated application/+xml MIME type, and Firefox has a first-class JSON viewer).

(In reply to Timo Tijhof from comment #82)

(In reply to Boris Zbarsky [:bzbarsky] from comment #78)

As for Chrome, […]: treat text/anything as text/plain, download application/something+xml.

I'm unable to reproduce downloading behaviour in Chrome.

https://chriscoyier.net/feed/ https://timotijhof.net/feed/ etc
These use WordPress and emit Content-Type: application/rss+xml; charset=UTF-8.

And the RSS mimetype is handled specifically as you describe - much like the XHTML mimetype is probably also handled by just displaying it like a normal webpage. Neither is the point of this bug. The example attached to this bug that uses application/x.custom+xml as the content type trivially reproduces the download behaviour in current Google Chrome. Firefox does the same with RSS because it does not have dedicated RSS support (and adding such support would be a separate bug that wouldn't address this one).

I came here from bug 1524719 which has been marked as duplicate 4 years ago. I was lead here because the CMS I use (Drupal) decided (years ago) to use the recommended RSS mimetype. Today, my clients are asking why the links to their RSS feed does not act like other websites' ones (which are mostly using text/xml).

The work started by :fredw 14 years ago was promising and would have solved most issues we face today with these "+xml" mimetypes. I don't get why some of you are trying to compare how other browsers are handling when Firefox could just follow the RFC and handle all uncatched mimetypes ending with "+xml" as "application/xml".

I am no CPP developper but I think that :fredw's work would be a very good starting point for someone willing to restart this on the latest version of Firefox (I believe the codebase changed a lot since 2009).

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

Attachment

General

Creator:
Created:
Updated:
Size: