Actually, AFAIK, this is a Netscape bug that has been known for ages.
Apparently it's timing dependent which is why you only get it sometimes. I
think it was mentioned as a potential bug with Java Web Server way back in
the day, but Sun tracked it down to Netscape.
see http://css.nu/pointers/bugs.html
Bottom line is, Netscape is flaky - VERY flaky! Expecting it to work
consistently is asking for trouble.
geoff
----- Original Message -----
From: "Tormod Hystad" <[EMAIL PROTECTED]>
To: "JRun-Talk" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Saturday, November 18, 2000 12:42 AM
Subject: JRun 3 has a "Netscape prints the .css content instead of the HTML
" problem
> Hi fellow JRunners!
>
> The problem in short:
> After upgrading from JRun 2.X to JRun 3.0(SP1 does not help) Netscape
> browsers randomly print the content of the stylesheet.css file we have
> externally linked instead of printing the HTML. But if I do a "View Frame
> Source", I see the HTML it is supposed to print. The stylesheet is linked
> this way (in a correct place in the <HEAD> part of the document):
>
> <link rel='stylesheet' type='text/css'
href='/SD/Stylesheets/Stylesheet.css'
> >
>
> I have spent several days with this issue, but have not found a
satisfactory
> solution yet. But I have nailed the problem down, and come up with a few
> workarounds (described later).
>
> Server Info:
> I run JRun 3.0SP1 (With a web application named SD, consisting of pure
> servlets), NT4SP6a Server, Netscape 4.75 (all Netscape 4.X browsers I have
> tested have the problem).
>
> The source of the problem is that Netscape is very sensitive of the
> format/content of the response the web server delivers when Netscape is
> loading external linked stylesheets, with this type of link:
>
> <link rel='stylesheet' type='text/css'
href='/SD/Stylesheets/Stylesheet.css'
> >
>
> With JRun 2.X, this was no problem, since it only served the files that
was
> requested with /servlet/ somewhere in the URL, IIS served the static
content
> (images, .js, .css).
>
> This has changed in JRun 3.0. IIS now hands over ALL requests that include
a
> JRun web application name to JRun. Meaning that all requests that contain
> /SD/ (in my case) will now be handled by JRun. JRun uses a special
servlet,
> allaire.jrun.file.FileServlet, to serve static content (None of this is
> confirmed by Allaire, but my "reasearch" indicates this).
>
> This is the root of the problem. The FileServlet seems to fail to format
the
> response to the request for .css files perfectly, so Netscape messes up
and
> prints the contents of the .css file instead of the HTML (formated by the
> linked .css file). But as an additional complexity, this does not happen
> consistently. The frequency varies, and one of our servers with Win2000,
> JRun 3.0 (Not SP1) and IIS 5.0 has no problems. While other Win2000,
JRun3.0
> servers HAVE the problem.
>
>
> What I have tried with failure:
> * I have searched the Internet thouroughly, and I found one other person
> (Phil Callister) with the same problem. ONE! I discussed it with him on
> email, he had not found any "real" solution, just a workaround (I also
found
> this workaround, it is described later in this email). But that is
> disturbing, I suspect that JRun 3.0 has a major flaw in it's handling of
> .css files and NO ONE else has the problem? It turns out that the use of
> external .css files seems to be rare (at least I could not find many
> examples of it out there!). I believe that is why so few others experience
> this, because JRun 3.0 HAS a flaw with handling .css files, I am 99% sure.
>
> * I have spent hours trying to change the MIME type - file extension
> mappings in JRun (and also in Netscape), but nothing helped. .css <->
> "text/css" is not registered in the properties files in JRun, so I added
it
> to both global.properties and local.properites for SD. No good. I used the
> admin tool for the SD app, added it there, no good. I manually modified
the
> Registry on my Win NT 4.0SP6 server, addedd the mapping every thinkable
> place, no good.
>
> * I created a servlet, CSSWriter, that writes the content of a .css file
> (after reading it from disk) to the response, ensuring that
> response.setContentType("text/css") is called. The I linked to this
servlet
> instead of Stylesheet.css. No good. I modified it, by manually examining
the
> response IIS sends when you request a .css file from it, so that my
servlet
> sent an EXACTLY similar response (with correct ContentLenght and a few
other
> "cannot-be-important" headers in addition to the ContentType).
>
> What I have tried with success:
> A) Create a virtual directory in IIS, named something else than my JRun
app,
> for example SDStyle. In this virtual directory I placed the Stylesheet.css
> file. Then I changed my links, to this:
>
> <link rel='stylesheet' type='text/css' href='/SDStyle/Stylesheet.css' >
>
> JRun does not have an application named "SDStyle", so IIS serves the file.
> And it works. The problem is gone. This was the solution the other
gentleman
> (Phil Callister) had also found (and used now, for several months, I
> believe).
>
> B) Stop using externally linked .css files and use <STYLE type="text/css">
> </STYLE> tags instead. This is interesting:
> One of the other developers here showed me that the JRun 3.0 Admin web
site
> uses externally linked stylesheets. I checked it with IE, and sure, they
do.
> I tried the admin tools in Netscape and they were fine. No problems. BUT
> THEN I checked their HTML source in Netscape, they do not use externally
> linked stylesheets if the browser is Netscape, they use the "inline"
> version, with <STYLE type="text/css"> <STYLE> tags.
>
> So it seems they have found a problem and used a quick workaround.
>
> There are two major drawbacks to this method for us:
> 1. A much larger amount of data will be transferred from the server to the
> client, since the style information now is sent everytime, instead of
being
> linked once and then cached in the browser.
>
> 2. We have to rewrite all our HTML pages (several hundreds).
>
> Anyone else having this problem? Any solutions? Allaire people, any
> information you can share with us? Is this a bug?
>
>
> ~ Tormod
>
> ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-
> Tormod Hystad
> Senior Developer, R&D
> CatalystOne Inc.
>
> email: [EMAIL PROTECTED]
> web: http://www.catalystone.com
> phone: +47 93 09 60 81 (Norway)
> ~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Your ad could be here. Monies from ads go to support these lists and
provide more resources for the community.
http://www.fusionauthority.com/ads.cfm
>
> Archives: http://www.mail-archive.com/[email protected]/
> Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Your ad could be here. Monies from ads go to support these lists and provide more
resources for the community. http://www.fusionauthority.com/ads.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
