tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Security container behavior toward .js file reference
Date Thu, 06 Jan 2011 21:31:32 GMT
Hash: SHA1


On 1/6/2011 1:16 PM, Propes, Barry L wrote:
> I'm experiencing (what I think is) a weird problem regarding a
> javascript reference file when accessed across the security
> container.

What do you mean "across the security container"? John Lennon really got
weird toward the end, huh?

> For several years, I've had some manual breadcrumb links written in
> each separate JSP file. So I thought I'd more easily consolidate into
> a .js file and just reference the link in each page that way.

So you went from server-side dynamic breadcrumb-trails to client-side
ones built using Javascript? Yikes! Might I recommend using a JSP include?

> e.g.   <script language="javascript" src="myapp_breadcrumb.js"></script>

Try: <script type="text/javascript" src="myapp_breadcrumb.js"></script>

In HTML4, "language" is deprecated because it never had any well-defined
values. From

language = cdata [CI]
    Deprecated. This attribute specifies the scripting language of the
contents of this element. Its value is an identifier for the language,
but since these identifiers are not standard, this attribute has been
deprecated in favor of type.

> It now prompts me if I want to save it (in IE) or in Firefox tries to display the javascript

No content type = undefined behavior, though the server should have been
serving .js files as text/javascript. Check with a protocol sniffer to
see if that happened. You probably have comments at the top of the file
which make MSIE do foolish things because it always tries to guess
content-type from content.

> To me this is odd because I already have a .js reference that's been
> in there for several years, and the container never balked at that.

What does that reference look like? The container is unlikely to balk at
it since it never considers is. In these cases, the /clients/ are balking.

> I'm not altogether positive, but perhaps it's the fact that I used
> some document.write methods to write them into the file? Although I
> wouldn't think that would really be any different, but this is puzzling
> behavior to me.

Why are you using document.write to add <script> elements to the file?
Maybe I just don't understand "Web 2.0" :)

> Anyway, if anyone knows why this might be happening, I welcome any feedback.
> If you're thinking this isn't Tomcat-related, it's HTML/JavaScript related, well, it
works fine on the non-protected area from the container.

What happens if you use MSIE and actually download the file. What
contents do you get? Do you get an error page in .js clothing?

> It's when logging on that it suddenly gets flagged. Another weird
> issue, to me, is that initially in Firefox it tried to display the
> .js file reference in the browser.

What does it mean to display a .js file reference in the browser?

> But if I just type over the .js file in the web browser and key in
> the intended page, sans URL parameters of any kind, it gets there
> fine and displays the content as intended.

Are you usually using parameters?

- -chris
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message