This is an ongoing topic. Search turbine-dev and turbine-user archive at www.mail-archive.com for "redirected true" and all will be revealed...hopefully.
Last I heard Sean Legassick was looking into modifying the logic a bit. http://www.mail-archive.com/[email protected]/msg03422.html ...And here is a timely message I wrote today on another list: ------------Start [EMAIL PROTECTED] message --------------- below please .... ----- Original Message ----- From: "Jon Stevens" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, October 14, 2001 7:38 PM Subject: Re: CVS update: MODIFIED: reports, Step3_1b.vm ... > on 10/14/01 7:10 PM, "Peter Lynch" <[EMAIL PROTECTED]> wrote: > > > Greetings, > > > > Let me first say that Scarab is looking good. Keep it up. > > > > On a recent Turbine 2.1 project, we encountered a similar problem about GET > > size with Apache. > > > > We posted a lot of data on a particular form( which worked initially) but in > > some cases the monstrous sendRedirect/redirected=true evil code inside the > > 2.1 Turbine servlet would interrupt causing the post data to be resent as a > > GET. Apache complained that the GET request was too long, over 1000 > > characters. > > > > Don't know if this will be an issue for you guys as I haven't seen mention > > of using Scarab with Apache. The only workaround was to modify our Turbine > > servlet and remove that evil code. Doing so has had no bad consequences for > > us. Wonder if that code is still there somewhere. > > > > -Peter > > The code isn't 'evil'...it is trying to solve a problem, which is the need > to establish a session id at the start of a users session so that they can > be tracked throughout the application. Even 'guest' users will be tracked. > If you have suggestions on how to do this another way, feel free to speak > up. Any code that is confusing, not particularly useful to the majority and causes more problems than it fixes I'll call evil, but I assure you its a lighthearted sort of way. :-) My thinking is that this particular code solves no common problem. Instead it is itself a hack for a very rare instance/combination of agent/container or at the very least some session tracking voodoo. Whoever encounters a problem stemming from this code not being in the core should be the one who adjusts their own code. I agree I should have not been the one hacking workarounds for this piece of code and sharing my findings more vigorously with others might have helped others. I can note several distinct problems caused by this code: 1. User bookmarks a link with the redirected key, causes Infinite redirect stack dump to client. Open a new browser and try it yourself: http://scarab.whichever.com:8080/scarab/servlet/scarab/redirected/true 2. When the code does execute it makes one request into 3 separate requests ( and responses) causing unnecessary traffic. 3. Posted data can be resubmitted as a get, causing overflow in Apache or the container. 4. working around the above problems means the developer has to add other hacks just to support a core hack condition that will never likely occur. Maybe this code had more solid purpose back in the days of Servlet spec 2.1, and crappy browsers and containers.. Reading the list archives tells a sorted tale about this redirect code. For example http://www.mail-archive.com/[email protected]/msg03347.html is one of many messages about the confusion this code causes. Here is what Sean Legassick had to say in http://www.mail-archive.com/[email protected]/msg02713.html "This mechanism is in place to ensure that session tracking works correctly. Particularly it allows the container to select URL-based session tracking if the client browser appears to have cookies disabled, and it guards against infinite redirects where a containers session tracking mechanism is broken (it could be argued this latter case is unlikely these days). It's a fairly common servlet API trick." Funny, actually it facilitates infinite redirects. See #1 above. The first part above is avoided if something like DynamicURI is used to construct all the URLS in your app. Doing so means the urls returned in the template from the first response would have the session id appended if a cookie could not be set. The encoding determines if session id should be appended to the URLs for you. There is no need to do the redirect thing for the server to figure it out. Lastly, the first call to request.getSession(true) will create a new session anyway if one does not exist. In Turbine 2.1 this happens in TurbineRunDataService when the session is put into RunData. Sorry, I just have no good things to say about it. The patch is simply to remove the code. Not add more hacks to work around the more common problems that the redirection creates. > > Yes, the code has its downsides...which as you found out, a monster GET > redirect will occur in the case where someone sits on a page longer than the > the session timeout and they click the submit button causing the data to be > sent, a redirect to occur and will fail if the GET data is to large. > > Needless to say, in both 2.1 and 3.0 (which is what we are using for > Scarab), there is a simple way to disable the session redirect, create your > own SessionValidator and have the requiresNewSession method return false. > > if ( sessionValidator.requiresNewSession(data) && > > Now, one 'better' solution is to chop off or remove entirely any GET data if > it exceeds a certain length and attempt to continue with the request. This > will cause the form submission to fail, however, it gives the application > developer a way to gracefully handle the situation instead of leaving it up > to Apache or Tomcat to show an error page. > Why not gracefully handle the original timed out request? > The reason why it is a good idea to chop off the data is because chances are > that the form submission is happening for an authenticated user. If the > session times out, then the user won't be authenticated any longer and the > form submission shouldn't happen anyway. > > Another solution would be to store the ParameterParser on the server in the > users new session before the redirect and then retrieve it after the > redirect and use that for the remainder of the 2 redirected request. This > however *could* allow non-authenticated users to submit data...not good > either. > Agree, not good > If you would like to submit a patch that one of these solutions happen, that > would be great. Definitely a much better solution than hacking the code or > just calling it 'evil'. > My only patch would be to remove it all together. I can followup to the turbine-dev list and test the reaction. -Peter > -jon > > ----------------End [EMAIL PROTECTED] message ----------------------- ----- Original Message ----- From: "Heiko Braun" <[EMAIL PROTECTED]> To: "Turbine List" <[EMAIL PROTECTED]> Sent: Monday, October 15, 2001 3:31 AM Subject: [OT] infinite redirect detected... > > hi, > > it might be slightly offtopic, > but i hope to find poeple having experienced > the similar problems. > > the thing is that i get an "Infinite redirect detected..." > error, from within my turbine app. i can locate the source > which produces the error, but unfortunatly i cant reproduce > it. does anyone know if their is a certain client that has problems > interpreting turbine/tomcat produced header information? > > maybe someone can explain the following lines to me: > > xxx.xx.xxx.xx - - [14/Oct/2001:21:27:34 1000] "HEAD > /mag/servlet/mag HTTP/1.1" 302 234 > xxx.xx.xxx.xx - - [14/Oct/2001:21:27:34 1000] "HEAD > /mag/servlet/mag/redirected/true HTTP/1.1" 200 - > xxx.xx.xxx.xx - - [14/Oct/2001:21:27:35 1000] "GET > /mag/servlet/mag/redirected/true HTTP/1.1" 200 2484 > > between these requests the error occures. > > the foo/redirect/true is either turbine internal or tomcat > specific. > > it would help a lot if someone can provide insights about the > redirecting processes inside turbine/tomcat or has experienced > similar problems. > > thanks in advance, > > -- > heiko braun, fork unstable media > http://www.unstablemedia.com > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
