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

D

David Blickstein

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"
version="1.0"?>

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

<?xml-stylesheet type="text/xsl" encoding="UTF-8"
href="http://dregs.zko.hp.com/db/makehtml.xslt" 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)"
http://dregs.zko.hp.com/db/makehtml.xslt

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.

Thanks,

Dave Blickstein

p.s. Unfortunately, my server (dregs.zko.hp.com) is behind a firewall so you
won't be able to access it.
 
D

David Blickstein

miseryman said:
This is probably due to a MIME type issue. Look at the
first question in the Mozilla XSLT FAQ:
<http://www.mozilla.org/projects/xslt/faq.html>.

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="http://dregs.zko.hp.com/db/makehtml.xslt" version="1.0"?>
<IRDump xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="girml2.xsd" >

Here's the header for the XSLT stylesheet:
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xs="http://www.w3.org/2001/XMLSchema">

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
Firefox?

Thanks again,

db
 
M

Martin Honnen

David Blickstein wrote:

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

<?xml-stylesheet type="text/xsl" encoding="UTF-8"
href="http://dregs.zko.hp.com/db/makehtml.xslt" version="1.0"?>

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 dregs.zko.hp.com.
But with normal security settings for IE and the internet zone that is
not different if you load an XML document via http.
 
M

Martin Honnen

David Blickstein wrote:

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.

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.
 
D

David Blickstein

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.

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?

Thanks
 
D

David Blickstein

I made another experiment of relevance here and have come to the following
conclusions:

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
that.

Thanks for all the help.
 
A

Alan J. Flavell

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...]
I made another experiment of relevance here and have come to the
following conclusions:

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

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.
but Firefox is only happy with .xsl

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
matter).

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
 
D

David Blickstein

1) Internet Explorer is happy with either .xslt or .xsl
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.

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
client"
2) I've told you that IE doesn't care what the extension is, it works with
either
extension
3) I've told you that Firefox fails with one file extension and works with
another
4) I conclude that Firefox is the one that is "concerned" with file
extensions
not IE.
5) This is a Firefox bug, not an IE bug???
 
A

Alan J. Flavell

3) I've told you that Firefox fails with one file extension and
works with another

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?
http://chrispederick.com/work/firefox/webdeveloper/

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).
4) I conclude that Firefox is the one that is "concerned" with file
extensions

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).
5) This is a Firefox bug,

I can't agree. On the evidence, Firefox is behaving impeccably.
not an IE bug???

IE's deliberate misbehaviour vis a vis RFC2616 is too crass to be
rated as a mere "bug".

best regards
 
P

Peter Flynn

David said:
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".

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

$ dog http://dregs.zko.hp.com/db/makehtml.xslt | head

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

///Peter
 
P

Peter Flynn

David said:
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
client"
2) I've told you that IE doesn't care what the extension is, it works with
either extension

Rename the stylesheet to makehtml.doc and see what happens.
3) I've told you that Firefox fails with one file extension and works with
another

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.
4) I conclude that Firefox is the one that is "concerned" with file
extensions not IE.

I would expect it to be the other way round.
5) This is a Firefox bug, not an IE bug???

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
 
J

Jim Moe

David said:
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
client"
2) I've told you that IE doesn't care what the extension is, it works with
either extension
3) I've told you that Firefox fails with one file extension and works with
another
4) I conclude that Firefox is the one that is "concerned" with file
extensions not IE.
5) This is a Firefox bug, not an IE bug???
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.
 
A

Andy Dingley

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

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
products.

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.
 
H

Harrie

Peter Flynn said the following on 8/11/2005 22:30 +0200:
David said:
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".

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

$ dog http://dregs.zko.hp.com/db/makehtml.xslt | head

dog is a drop-in replacement for the Unix cat command (seriously :)
available from http://jl.photodex.com/dog/ [..]

I just love those word tricks the UNIX world is famous off, thanks for this one, I didn't no of dog.
[..] I have no idea how you would
go about doing this under Windows though.

One can install lynx on Windows and use something like:

lynx -head -dump http://dregs.zko.hp.com/db/makehtml.xslt

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

http://web-sniffer.net/

Also, one can use

telnet http://dregs.zko.hp.com/db/makehtml.xslt 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).
 

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. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,996
Messages
2,570,238
Members
46,826
Latest member
robinsontor

Latest Threads

Top