A little background. This "bug" has been haunting Turbine for a while.
I just did some more thinking about it and I have some idea.
A about 3 - 4 months ago, it became apparent that the following code in
Turbine.java
if ( sessionValidator.requiresNewSession(data) &&
data.getSession().isNew() )
{
}
Could theoretically redirect forever. The problem is that if your HTTP
client doesn't support cookies you could be in a bad situation. I just
read the Session section of the Servlet 2.2 spec. Do all Servlet
engines require URL rewriting? It doesn't explicity say this is a
requirement although it does say cookie session tracking IS a
requirement:
"Session tracking through HTTP cookies is the most used session tracking
mechanism and is required to be supported by all servlet containers"
but it doesn't say this is a requirement for url rewriting:
"URL Rewriting URL rewriting is the lowest common denominator of session
tracking. In cases where a client will not accept a cookie, URL
rewriting may be used by the server to establish session tracking. URL
rewriting involves adding data to the URL path that can be interpreted
by the container on the next request to associate the request with a
session. The session id must be encoded as a path parameter in the
resulting URL string. The name of the parameter must be jsessionid. Here
is an example of a URL containing encoded path information:
http://www.myserver.com/catalog/index.html;jsessionid=1234"
- Jon. I think that this should be cleared up in the next rev of the
Servlet spec... IE whether this is explicity a requirement or not
Anyway. When I deployed a Turbine application (Jetspeed) on a different
machine and tested this with a WAP device that didn't support cookies I
noticed that the infinite redirection bug came back.
- Slightly rework the infinite redirect fix.
- if ( duri.toString().equals( currentURI ) )
- {
- String message = "Infinite redirect detected...";
- log(message);
- Log.error(message);
- throw new Exception(message);
- }
-
- data.getResponse().sendRedirect( duri.toString() );
- return;
+ if ( ! duri.toString().equals( currentURI ) )
+ {
+
+ data.getResponse().sendRedirect( duri.toString() );
+ return;
+
+ } else {
+
+ String message = "Infinite redirect detected at: "
+
+ rundata.getRemoteAddr() +
+ " - " +
+ rundata.getRemoteHost() +
+ " - " +
+ rundata.getUserAgent();
+
+ Log.warn( message );
+ }
Anyway... thoughts. In this situation ... if a session wasn't supported
your application would work but you wouldn't be able to store any
session information (obviously). I could see that some applications,
like shopping carts, could TOTALLY break whereas others such as Jetspeed
would just be slower. Should we have metainfo as to whether this is a
REQUIREMENT or a SUGGESTION to start a new session?
Of course this might just be a bug in Tomcat 3.1 but if this isn't a
Servlet 2.2 requirement (to support URI rewriting) then I think this
should be done to Turbine.
Kevin
--
Kevin A Burton (e-mail: [EMAIL PROTECTED], UIN: 73488596, ZKey:
burtonator)
http://relativity.yi.org
Message to SUN: "Please Open Source Java!"
To fight and conquer in all your battles is not supreme excellence;
supreme
excellence consists in breaking the enemy's resistance without fighting.
- Sun Tzu, 300 B.C.
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
