----------------------------------------------------------------
BEFORE YOU POST, search the faq at <http://java.apache.org/faq/>
WHEN YOU POST, include all relevant version numbers, log files,
and configuration files. Don't make us guess your problem!!!
----------------------------------------------------------------
We've had some trouble with IE 5.5, but it's been in the javascript
area mostly. We haven't seen any cookie weirdness yet.
The one thing I can suggest is to make sure you have the latest JServ
release; there was a bug in cookie parsing for a while. You would only
run into this problem if other (non-JServ) cgi apps were setting
and/or reading cookies on the same site. (We ran into because we had
some perl.) This could especially be a problem if you have cookies
with whitespace in the values.
(FYI, here's a summary of the IE 5.5 javascript problem)
For those who are interested, the fix for the bug I sent around last
week presents problems for IE5.0. A better workaround is this:
Click <span style="color:#003366;cursor:hand;text-decoration:underline"
onClick="myFunc()">here</span>
> Many have seen IE5.5 display a warning that states "This page contains
> both secure and nonsecure items..." in [ the application. ]
> My first thought was this was happening when javascript in one
> frame/window attempted to modify text/html in another frame/window (in
> https).
>
> In reality, this happens when you access a javascript function via a
> text or image link inside a multiframe document in https (even tho the
> function is in the same frame as the link!). For example:
>
> Click <a href="javascript:myFunc()">here</a>
>
> will trigger the message. One would hope that MS gets this fixed in a
> future release, but until then, the workaround is to assign the
> function call to the onClick attr as in:
>
> Click <a href="#" onClick="myFunc()">here</a>
Cheers,
billo
------------
From: Mike Olivieri <[EMAIL PROTECTED]>
Date: Mon, 25 Sep 2000 08:37:49 -0400
----------------------------------------------------------------
BEFORE YOU POST, search the faq at <http://java.apache.org/faq/>
WHEN YOU POST, include all relevant version numbers, log files,
and configuration files. Don't make us guess your problem!!!
----------------------------------------------------------------
I have been using JServ for nearly a year, with much success and very
few problems. My site has had visitors with every conceivable browser
type, again, with no problems relating to JServ. I am running Apache web
server on one Sun Solaris 8 server and JServ on another Sun Solaris 8
server (JDK1.2.1), which is dedicated for the purpose of being an
application
server.
Our software (entirely servlet/browser based) allows people to manage,
create, and distribute online courses and their corresponding
multimedia, and uses a variety of user interface techniques to make the
user's life easier. One of these techniques is to use "pop-up" windows:
using JavaScript, we open new browser windows that are smaller than the
open one so the user knows that they're in a pop-up. Not a very
exciting, cutting edge technique, I know, but it has worked flawlessly -
till now.
My boss recently upgraded his Dell laptop with Windows 98 to IE5.5.
Other people in my shop with NT have had no problems with 5.5. However,
his browser sometimes will stop sending the session ID cookie to my web
server! I keep an object in the Session table which identifies the user
and verifies if that user's authentication state, as well as some other
fast access kind of stuff (name, database ID, etc.). I cleverly named
this "User". When there is no session object, when the User object is
null, or when the User object indicates not-logged-in, I show a log-in
screen.
This technique has worked wonderfully, except that, after my boss closes
his pop-up windows, he _sometimes_, not always, gets the log-in
screen. His session is no longer in the session table, or the session ID
is not being passed. This is an intermittent, difficult-to-reproduce
problem. It gives me that scared, nauseous feeling that I used to get
when debugging C++ DLLs and knew there was a pointer problem somewhere
in those 100k lines of code.
I knew a bit about how cookies work, so I started poking around JServ
java code. Instead of using an in-memory, session-only cookie for the
session ID, I added an expiration date to the cookie to make the thing
get written to disk. I have a hunch it's an IE 5.5 bug, where it gets
confused about which window's cookies to keep/discard when a browser
window closes.
My test environment consists of only one server with both HTTPD and
JServ installed on it. There is no problem EVER for this guy's browser
on that test platform.
I want to blame MS for shoddy code, as I am wont to do, because of the
fact that it works great in many other browsers. However, if this is the
case, many users will have IE 5.5 installed in the not-too-distant
future, and I will need a way to support my app. So, here are some
questions:
1) Has anybody else seen this problem?
2) I added a parameter to my zone.properties file: session.maxCookieAge,
which is number of seconds until expiry. Is this technique insecure for
my users? Are there other problems with my trick? It works on my test
platform, but I am leery of putting it into production. I will show you
guys my code changes (very minor - three lines?) if anyone is
interested.
3) In the case that IE5.5 is using more strict standards compliance: is
there something special I need to do with session IDs in my output?
TIA,
Mike
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search Archives:
<http://www.mail-archive.com/java-apache-users%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search Archives:
<http://www.mail-archive.com/java-apache-users%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
