Thanks for the info/pointer!

But I do not agree with your conclusion. This problem got much worse after
we upgraded to JRun 3 (probably because it serves the css instead of letting
IIS do it, as JRun 2.x did). When we implemented the "fix" Phil Callister
recommended (create a virtual directory in IIS that points to the .css files
and have all HTML reference this virtual directory), the problem almost
disappeared. This is the info from the css.nu site:

* CSS appears on screen

* Causes include: Incorrect type sent by server, longish stylesheets,
reloading/resizing load in progress, a fast connection, earlier versions of
NN

* Fix/Workaround: Use embedded style instead of external

So my theory is that JRun 3 triggers the "Incorrect type sent by server"
cause, but when we worked around this with letting IIS server the css, we
sometimes trigger the "fast connection" (or one of the others) cause, which
are triggered much less frequently.


~ Tormod

~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-
Tormod Hystad
Senior Developer, R&D
CatalystOne Inc.

email:  [EMAIL PROTECTED]
web:        http://www.catalystone.com
phone:      +47 93 09 60 81 (Norway)
~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-


-----Original Message-----
From: Geoff Soutter [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 05, 2000 6:09 AM
To: JRun-Talk
Cc: [EMAIL PROTECTED]
Subject: Re: JRun 3 has a "Netscape prints the .css content instead of
the HTML " problem


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

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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

Reply via email to