ok, thanks. i wasnt aware of that topic being discussed in depth already.
-- heiko braun, fork unstable media http://www.unstablemedia.com On Mon, 15 Oct 2001, Peter Lynch wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
