Oh, I'm sorry Doug! I misunderstood your question! To my knowlodge only
BEA's Weblogic Application Server supports it automatically!
Bye,
Philip
Thanks.
Just to clarify: I've been told that some containers will do this
*automatically*, that is, they will recognize links in JSP/HTML (hey,
recommended
(back by BEA e-docs) using encodeURL regardless of whether you are using URL
rewriting, sessions, or even straight cookies.
A look at the 6.1 e-docs shows that this has not changed in the new release:
http://e-docs.bea.com/wls/docs61///webapp/sessions.html#100770
-Tim
-Original Message
Tim's right, you should ALWAYS use encodeURL from the beginning of your
project--it doesn't take much effort and it will save you heartache in the
future. And it's part of the Servlet spec, who knows if they will use it
for something else in the future.
Or even better, create your own method
container might switch to URL rewriting
to keep the sessions.
URL rewriting works, but there are a lot of drawbacks. That's why you should
only use it when cookies are not possible.
Now, why is it bad:
- It provides ugly URL's. At first you might say that this is not that
important, but in a lot
Thanks to all, who answered in such a long and detailed way! I'm very happy
about this!
I have to realize a project for a customer, who don't want cookies and I
have tried to convince him of using cookies, but i didn't want! To use the
automatic mechanism of switching to URL-Rewriting, when
specification and reference
[mailto:[EMAIL PROTECTED]]On Behalf Of Philip M. Meier
Sent: woensdag 2 januari 2002 12:57
To: [EMAIL PROTECTED]
Subject: Re: Sessions and URL-Rewriting?
Thanks to all, who answered in such a long and detailed way! I'm
very happy
about this!
I have to realize
I will tell him the extra cost and I think, he will see that this is an
important fact... ;-)
But when cookies are not support the Container automaticly detects that and
I don't have to prepare every Link with encodeURL to ensure that the
session is still handled correct around?
Thanks,
Philip
Hello Philip!
PMM But when cookies are not support the Container automaticly detects that and
PMM I don't have to prepare every Link with encodeURL to ensure that the
PMM session is still handled correct around?
I do. I do have to do that. :-(
Best regards, Anton
: Re: Sessions and URL-Rewriting?
Shit! ;-) Every Link? I lot of work is coming to my room! ;-)
Bye,
Philip
- Original Message -
From: Anthony Tagunov [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, January 06, 2002 2:26 PM
Subject: Re: Sessions and URL-Rewriting?
Hello Philip
I know these containers, which supports URL-Rewriting:
Resin 2.01
Tomcat 4.0 4.01
Does anyone know of any servlet/jsp containers that support automatic URL
rewriting (which is referred to in the link Philip sent, and which I've
heard referred to by other folks)?
Thanks.
Just to clarify: I've been told that some containers will do this
*automatically*, that is, they will recognize links in JSP/HTML (hey, if
browsers can do it, why not servlet containers) and insert the necessary
info to handle session identification. This is done, supposedly, without
Hello!
I'd like to make use of the session-object, but I don't want the
session-object to use cookies, but instead to use URL-rewriting! Is there a
method or whatever to
tell the session-object to use url-rewriting and no cookies?
Thanks in advance,
Philip
: Sessions and URL-Rewriting?
Hello!
I'd like to make use of the session-object, but I don't want the
session-object to use cookies, but instead to use URL-rewriting!
Is there a
method or whatever to
tell the session-object to use url-rewriting and no cookies?
Thanks in advance,
Philip
Hello Geert!
There's no special reason, but I thought, that url-rewriting is better
until! Why is it better? Is there a method or whatever to tell the
session-object to use url-rewriting and no cookies?
Greetings,
Philip
Why?
Cookies are better than URL Rewriting.
Geert Van Damme
Message-
From: A mailing list about Java Server Pages specification and reference
[mailto:[EMAIL PROTECTED]]On Behalf Of Philip M. Meier
Sent: Saturday, January 05, 2002 2:59 PM
To: [EMAIL PROTECTED]
Subject: Re: Sessions and URL-Rewriting?
Hello Geert!
There's no special reason, but I thought
First of all thank you, Zvika!
I use JBoss 2.4 with Tomcat 4.01 and I didn't find any element in the DTD of
the Deployment-Descriptor, which is able to force URLRewriting! So I will
use the default properties, which is to use only URLRewriting, when cookies
are not supported or allowed.
PM
To: [EMAIL PROTECTED]
Subject: Re: Sessions and URL-Rewriting?
First of all thank you, Zvika!
I use JBoss 2.4 with Tomcat 4.01 and I didn't find any element in the DTD of
the Deployment-Descriptor, which is able to force URLRewriting! So I will
use the default properties, which is to use only
URL rewriting is part of the spec. You need to use response.encodeURL()
around every one of the links you put on your site.
For example, instead of:
a href=page2.jspnext page/a
you need to do:
a href=%= response.encodeURL(page2.jsp) %next page/a
If you do this, then the servlet container
Hi,
I don't know how to handle this. I have two servlets which both use sessions
persistence engine. One must use cookies because with multipart forms, jrun
stores the session identifier into the resquest parameters, ie in an object
it cannot access. But for another servlet, my need is to handle
As Jim Haungs is fond of saying, "the only interesting numbers are one and
infinity". Designing a workaround for exactly two sessions could cause
problems when you need to go to three...
Also, note that if a user starts a new browser process, that browser will
get a new session no matter what
with cookies, sessions with url rewriting
As Jim Haungs is fond of saying, "the only interesting numbers are one and
infinity". Designing a workaround for exactly two sessions could cause
problems when you need to go to three...
Actually, this IS a matter of two servers, as long as I want o
I'm not sure if this is efficient or even a reasonable thing to do, but
could you could put the subsession id in the path itself and set up a
servlet to translate the path. There are probably some subtle nuances that
you may have to deal with, but here is the general idea:
Set up a servlet that
Also, note that if a user starts a new browser process, that browser will
get a new session no matter what you do. In fact, that's how I support
Do you mean for example start once Netscape and then IE ? Because that's
far
No -- session cookies are kept in process memory for the browser, so
23 matches
Mail list logo
