How would you do that if you are using Form authentication
and the web.xml file directs them to a loginpage before they
access the index.jsp
Have the same problem and found that If they accept session cookies
then all is ok
Your help would be greatly appreciated.
-Original Message-
Rob,
I'm not sure I understand what you want, but regarding session cookies,
IE5/Mac and SSL, I think that the problem is that TC 4 does not seem to
automatically support persistant TCP-connections which both gives bad
performance, and confuses at least one browser to the extent that it
stops
I am trying to use encodeURL for all my href's and login page
but I get:
Apache Tomcat/4.0.2 - HTTP Status 400 - Invalid direct reference to form
login page
type Status report
message Invalid direct reference to
Dave,
Perhaps there is something in the configuration of your server (server.xml),
or its default webapp settings (conf/web.xml), or the configuration of your
webapp (WEB-INF/web.xml) that is causing the session cookie to be set as a
secure cookie.
There is one thing that differs between the TC
Hi,
I have a Tomcat app using sessions based on cookies (i.e. std way) that
works with a huge set of browsers and OSes.
But on Mac using IE 5 it does not. The culprit seems to be that session
cookies are not compatible in some way as they are not visible in
TC.
Is this a known problem?
BTW,
Now i have digged a little bit further in this.
The IE 5 Mac missing session cookie problem only occurs when using SSL.
Too bad our app needs SSL.
Anders
- Original Message -
From: Anders Rundgren [EMAIL PROTECTED]
To: Tomcat Users List [EMAIL PROTECTED]
Sent: Friday, March 08, 2002
I think they best way you can solve this problem, is to
use response.encodeUrl() on all links to enable the session
tracking by url.
-Ursprüngliche Nachricht-
Von: Anders Rundgren [mailto:[EMAIL PROTECTED]]
Gesendet: Freitag, 8. März 2002 13:04
An: Tomcat Users List
Betreff: SSL:
Ralph,
Thanx for your advice but this is likely to be a bug in TC 4.0.2 that cannot be
too hard to fix. I just found-out that it only affects SSL, which I guess is the
reason no one has seen it before.
URL rewriting is a possibility but our app will get ugly, so I prefer to
launch without Mac.
I got the impression from your previous posts, that
the browser is the source not tomcat.
-Ursprüngliche Nachricht-
Von: Anders Rundgren [mailto:[EMAIL PROTECTED]]
Gesendet: Freitag, 8. März 2002 13:19
An: Tomcat Users List
Betreff: Re: IE 5 on Mac is incompatible with TC 4?
Ralph,
I got the impression from your previous posts, that
the browser is the source not tomcat.
Well This is matter of taste. As IE 5 is the current Mac release and
IE is relatively popular even by Mac-user's, I believe that TC should
adopt to IE 5 rather than the revse. A *really*
I haven't been following this thread but it seems like you are
saying that Tomcat should be modified to work correctly with IE 5. The
problem with that is that Tomcat is an reference implementation of a
particular spec (JSP/Servlet) which dictates how things have to work - it is
the
Randy,
I don't know if Mac IE 5 is doing something *outside* of the cookie-specification
(which governs this rather than the servlet specification), but I'm pretty sure that
the original Apache-server handles this differently than Tomcat. Do you know
any Apache SSL-site using session-cookies
On Fri, 8 Mar 2002, Randy Layman wrote:
I haven't been following this thread but it seems like you are
saying that Tomcat should be modified to work correctly with IE 5. The
problem with that is that Tomcat is an reference implementation of a
particular spec (JSP/Servlet) which
From: Anders Rundgren [mailto:[EMAIL PROTECTED]]
Well This is matter of taste. As IE 5 is the current
Mac release and
IE is relatively popular even by Mac-user's, I believe that TC should
adopt to IE 5 rather than the revse. A *really* strange thing is that
persistant cookies work.
I don't copletly agree with that.
As long as you don't break specs it is possible to do
something in tomcat to deal with errors in browsers.
(Like missbehavior in the headers of a http request)
If a browser has a bug that you can't deal with, without
breaking the spec there isn't much you can
On Fri, 8 Mar 2002, Ralph Einfeldt wrote:
I don't copletly agree with that.
As long as you don't break specs it is possible to do
something in tomcat to deal with errors in browsers.
(Like missbehavior in the headers of a http request)
If a browser has a bug that you can't deal with,
Ralph, at this stage we can just guess as it does not *have* to be a browser bug.
Particularly as other web-servers most likely handles this differently.
I have verified that IIS does this OK but that was hardly a surprise :-).
I will now perform some deeper investigation by writing a small
sounds to me that this whole line of conversation could be
summed up as
If you want users without cookies to use your site then use
encodeURL
if not tough.
This isn't a tomcat issue, it's a lazy ( web site) programmer issue ;-^)
(honest not flame bait :
D
Joe Laffey wrote:
On Fri, 8
I believe that Joe is right: the JSP/Servlet spec is a server-side spec, and
the servers serve (forgive the pun) the browser community. A spec that
actually excludes even 1% of the browsers is suspect, IMHO. (And I'm not
sure I believe that the JSP/Servlet spec could possibly be the culprit --
Sorry to jump in on this but I'm not sure that encodeURL will solve the
problem.
If I understand it correctly, encodeURL will 'ONLY' add session
information if it determines that it must be added because cookies are
disabled. To quote the JavaDoc for encodeURL:
quote
The implementation of
I've been watching this thread with some interest, because I have had no
difficulty using cookie-based sessions on Tomcat 4.0.1 with Mac OS X and IE.
Judging from the headers you reproduced in your email, it would appear the
Tomcat has been configured in such a way as to treat the session cookie
Dave,
snip
The system described above relies on correct behavior of cookies on the Mac
in IE, and it works for us. I don't know if any behavior on the Tomcat side
has changed since 4.0.1, but I would tend to doubt it.
That's nice to hear :-|
Why are you using a secure cookie for the session
On 3/8/02 11:36 AM, Anders Rundgren [EMAIL PROTECTED] wrote:
2. Actually, we do absolutely nothing but request.getSession() which
triggers the session-mechanism according to my fellow developer. I.e.
we don't handle cookies ourselves, we rely on Tomcat's handling which
has worked fine until
Just to list the possible sources:
- Tomcat doesn't send the cookie
Unlikely, as it works with other browsers
- Tomcat send it in a format that this version of ie doesn't recognize
Two variants for this
- The header contains/misses something that makes this version of IE
fail.
-
24 matches
Mail list logo
