Firefox and XSLT (local stylesheet works, server-based stylesheet fails)

Discussion in 'XML' started by David Blickstein, Aug 11, 2005.

  1. I have some XML documents that I want to open in a web browser and be
    automatically translated to HTML via XSLT. I'm using an xml-stylesheet
    processing command in a file called "girml.xml".

    This all works in Internet Explorer, but doesn't work with Firefox.

    In both IE and Firefox this works:

    <?xml-stylesheet type="text/xsl" encoding="UTF-8" href="makehtml.xslt"

    The following works with IE and fails with Firefox (the server is WindowsXP

    <?xml-stylesheet type="text/xsl" encoding="UTF-8"
    href="" version="1.0"?>

    The difference is whether or not the stylesheet comes from a server or a
    local file.

    Another interesting datapoint is that I get different results depending on
    whether I try to open girml.xml as a local file ("Open File") or as a
    web-served file ("Open Location"). When I open it locally I just get a
    blank screen. When I try to open it from the server, I get:

    "Error loading stylesheet: (null)"

    I can load the stylesheet from that URL with IE. When I try to load it with
    Firefox it asks me what program I want to use to open it. But clearly the
    file is there, and accessible.


    Dave Blickstein

    p.s. Unfortunately, my server ( is behind a firewall so you
    won't be able to access it.
    David Blickstein, Aug 11, 2005
    1. Advertisements

  2. David Blickstein

    miseryman Guest

    This is probably due to a MIME type issue. Look at the
    first question in the Mozilla XSLT FAQ:
    miseryman, Aug 11, 2005
    1. Advertisements

  3. I'm unclear as to how to correct this.

    Here's the header for the XML file:

    <?xml version="1.0" encoding="UTF-8"?>
    <?xml-stylesheet encoding="UTF-8" type="text/xsl"
    href="" version="1.0"?>
    <IRDump xmlns:xsi=""
    xsi:noNamespaceSchemaLocation="girml2.xsd" >

    Here's the header for the XSLT stylesheet:
    <?xml version="1.0" encoding="UTF-8"?>
    <xsl:stylesheet version="1.0"

    Is there something I need to add.

    I can't get Firefox to report the MIME type because it seems to insist on
    using some OTHER program to view the XSLT stylesheet. IE seems to report it
    as "type: XSL Transformation".

    Does anyone have an example of two headers (XML and XSLT) that work with

    Thanks again,

    David Blickstein, Aug 11, 2005
  4. David Blickstein wrote:

    As a security measure you can only apply stylesheets from the same
    origin the XML is loaded from so Firefox will certainly load that
    stylesheet if your XML with the <?xml-stylesheet?> is located too on
    that server
    But with normal security settings for IE and the internet zone that is
    not different if you load an XML document via http.
    Martin Honnen, Aug 11, 2005
  5. David Blickstein wrote:

    That means that the file is served with a MIME type that Firefox does
    not know to handle. You have to set up your server to serve that file as
    text/xml or application/xml. If you can't change the server settings
    then rename the file makehtml.xml and your server will probably serve it
    with an XML MIME type like application/xml or text/xml.
    Martin Honnen, Aug 11, 2005
  6. That means that the file is served with a MIME type that Firefox does
    Renaming the stylesheet with a .xml extension and changing the href to
    reflect that in the xml-stylesheet tag solved the problem of not being able
    to view the stylesheet with Firefox, but I still can't load/translate the
    file I want the stylesheet applied to. I still end up with a blank screen
    when the href is to a URL rather than a local file.

    I've verified that the URL is correctly typed (by cutting and pasting it
    into Firefox).

    FWIW, Internet Explorer still works both ways. The problem is definitely
    specific to Firefox.

    Any further suggestions?

    David Blickstein, Aug 11, 2005
  7. I made another experiment of relevance here and have come to the following

    1) Internet Explorer is happy with either .xslt or .xsl but Firefox is only
    happy with .xsl

    2) The remaining problem is indeed that Firefox will not load a stylesheet
    from a separate location than the source file referring to it. That pretty
    much kills me and it doesn't seem like there are any user options to change

    Thanks for all the help.
    David Blickstein, Aug 11, 2005
  8. On Thu, 11 Aug 2005, David Blickstein wrote:

    [I'm adding a comment here from the sidelines, without having followed
    this thread in every detail. Use this comment or not, as you wish...]
    IE deliberately violates a mandatory requirement of the HTTP RFC,
    RFC2616 (and documents this violation, without actually admitting it
    for what it is), that in an HTTP transaction the only feature of
    relevance is the MIME content-type sent by the server. Filename
    extensions are of *no concern whatever* to a web-compatible client
    agent, in an HTTP transaction.
    I presume that Firefox conforms to RFC2616 at least as well as does
    Mozilla, with which I'm familiar. In an HTTP transaction, it
    considers solely and exclusively the MIME content-type from the
    server: filename extensions are not permitted to be of the slightest
    concern to it. This is fundamental to the HTTP protocol rules.

    (Processing of locally-stored files would of course be a different

    Corollary: the behaviour of MSIE can never be taken to be any
    indication of correctness. If it does what the author intended, in a
    situation where a web-compatible browser does otherwise, then in many
    cases that's because both the author and MSIE are wrong.

    best regards
    Alan J. Flavell, Aug 11, 2005
  9. 1) Internet Explorer is happy with either .xslt or .xsl
    I'm also just responding via a cursory reading of what you wrote but... I
    guess I don't understand why you're pointing the finger at IE rather than
    Firefox. Tell me where I went wrong in the following logic:

    1) You say the "file exts are of no concern whatever to a web compatible
    2) I've told you that IE doesn't care what the extension is, it works with
    3) I've told you that Firefox fails with one file extension and works with
    4) I conclude that Firefox is the one that is "concerned" with file
    not IE.
    5) This is a Firefox bug, not an IE bug???
    David Blickstein, Aug 11, 2005
  10. If we're talking about HTTP transactions as I has assumed, this
    indicates that your HTTP server is sending different MIME content
    types for these different filename extensions. The MIME content types
    are the sole desiderata at the interworking interface - and hence are
    what an adviser would need to know in order to help you further; the
    filename extension is of no concern to a web-compatible client agent -
    any effect that it's having is purely internal to your web server.

    Could I suggest that you install Chris Pederick's "web developer
    extension" for easy access to diagnostic information?

    Under its (i)nformation menu, one can call up the "view response
    headers" option, which shows clearly what the HTTP transaction
    returned in the way of MIME content-type and related information.
    This is the key to the behaviour of web-compatible client agents
    (from which MSIE deliberately excludes itself, as already noted).
    Not so. The effect is entirely shielded from any web-compatible
    client agent (which in this instance means RFC2616-conforming), by
    your web *server*. What it's responding to is the MIME type returned
    by your server.

    (You've already been told by another that it's a MIME-type issue, but
    you're apparently chosen to disregard that).
    I can't agree. On the evidence, Firefox is behaving impeccably.
    IE's deliberate misbehaviour vis a vis RFC2616 is too crass to be
    rated as a mere "bug".

    best regards
    Alan J. Flavell, Aug 11, 2005
  11. David Blickstein

    Peter Flynn Guest

    Use dog to access the file showing the headers, eg:

    $ dog | head

    dog is a drop-in replacement for the Unix cat command (seriously :)
    available from -- I have no idea how you would
    go about doing this under Windows though.

    Peter Flynn, Aug 11, 2005
  12. David Blickstein

    Peter Flynn Guest

    Rename the stylesheet to makehtml.doc and see what happens.
    The extension should be irrelevant in Firefox -- it's supposed simply to
    obey what the Content-Type header says the file is. Try using the extension
    which currently works but changing the Content-Type to something obviously
    wrong like image/gif and see what happens.
    I would expect it to be the other way round.
    It may be both. Either way, server-side XSLT is badly implemented by both
    browsers, and in general not a reliable way to serve. Use server-side
    transformations with (eg) Cocoon, AxKit, PropelX, etc

    Peter Flynn, Aug 11, 2005
  13. David Blickstein

    Jim Moe Guest

    You are confusing browser issues with HTTP server issues.
    When receiving data from a server, Firefox complies with the standard
    by honoring only the content-type value in the HTTP header. It ignores the
    extension. Loading a file locally it uses the extension to determine the
    file's content type since there is no HTTP transaction involved.
    IE is being "helpful" by ignoring those pesky and restrictive
    standards. It allows server administrators to do a bad job by glossing
    over their errors or omissions.
    Jim Moe, Aug 12, 2005
  14. David Blickstein

    Andy Dingley Guest

    Go and download the "Live HTTP Headers" extension for Firefox. It's
    extremely useful and will allow you to see what the headers from the
    server are telling the browser about the file.

    The browser needs to know the type of file to be able to use it.

    Firefox (correctly) expects to be given a content-type header to
    indicate this.

    IE will "guess" the document type from the file extension. This is
    typical M$oft behaviour - "helpful" for the simple cases when you don't
    need it, broken for the complex cases when you do need well-behaved

    Your server is probably configured to serve .xsl correctly, but
    unconfigured for .xslt (it probably sends them as text/plain). In this
    case, IE guesses and guesses coincidentally right. But this is not a
    behaviour you should rely on, because it is basically doing the wrong
    thing in the wrong way.

    Fix your server config. On Apache this is easy.
    Andy Dingley, Aug 12, 2005
  15. David Blickstein

    Harrie Guest

    Peter Flynn said the following on 8/11/2005 22:30 +0200:
    I just love those word tricks the UNIX world is famous off, thanks for this one, I didn't no of dog.
    One can install lynx on Windows and use something like:

    lynx -head -dump

    ... (where -dump is optional) or use the web tool Web Sniffer:

    Also, one can use

    telnet http

    ... and punch in some HTTP codes and look at the result This is a bit combursome, but give you exact control over which headers the client should send to the server (but there are probably other tools with or without a GUI for that).
    Harrie, Oct 16, 2005
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.