Hi Martin, I don't see how to wrap the request or the response can be useful here. Even if we decorate the container request to return its URI based on the page being rendered address it will not be enough because Servlet API does not allow us to change the composition of a response. i.e. we are not able to set on which request URI the encode method of the response will work on (Tomcat API allows such thing but I'd rather not use to it).
I simply don't get why Tomcat added such validation in the encode method. To redirect the request to a buffered response is a very common strategy that has being saving tons of applications from double form submissions for instance rather than a weird web framework implementation like I read in the ticket. It looks like the response will not encode the session id to links and callbacks in the buffered pages in a deeper path from Tomcat 7.0.29 on. I'm OK with the way the Tomcat team worked around this issue. Who knows if they aren't only doing some good by preventing some session fixation attacks. Pedro Santos Em 25/07/2012, às 16:42, Martin Grigorov escreveu: > Hi, > > Please take a look at > https://issues.apache.org/bugzilla/show_bug.cgi?id=53469. > This issue describes a problem which prevents Wicket's default > RenderStrategy - REDIRECT_TO_BUFFER. > > Basically the problem is: > - PageA mounted at /mount/pageA is requested > - the code uses setResponsePage(PageB.class) which is mounted at > /deeper/mount/path/pageB > - Wicket starts to render PageB (in the same request cycle) and for > each url in the page it asks the web container to encode it > (HttpServletResponse#encodeURL()) > - here Tomcat 7.0.29+ tries to find whether the url to encode is part > of the web app. To do this it makes the relative url passed by Wicket > to absolute by using the HttpServletRequest's requestURI (i.e. > /mount/pageA). This may get wrong because Wicket actually generates > the urls against /deeper/mount/path/pageB > > Mark Thomas (Tomcat dev) suggests that Wicket could use > HttpServletRequestWrapper which should return the correct requestURI > depending on the current request cycle baseUrl. > > Any ideas and comments are welcome! > > -- > Martin Grigorov > jWeekend > Training, Consulting, Development > http://jWeekend.com
