tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Grigorov <mgrigo...@apache.org>
Subject Re: Redirect to buffer strategy may not work properly on Tomcat 7.0.29
Date Fri, 27 Jul 2012 08:10:13 GMT
Hi Pedro,

I've CC-ed Tomcat's team, so they can explain better what Tomcat does.

On Fri, Jul 27, 2012 at 3:24 AM, Pedro Henrique Oliveira dos Santos
<pedrosans@gmail.com> wrote:
> 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 don't quite understand what you mean with the above.
As far as I understood Mark he suggests to use
HttpServletRequestWrapper which should return the proper base url when
asked (#getRequestURI, #getPath, etc.)

Thinking more about it now I don't see how this will help actually
because this wrapper will be reachable only by Wicket code. To encode
an URL Wicket calls HttpServletResponse#encodeURL(), note this is the
*response*, and it has no reference from the response to the wrapped
request, so Tomcat will be able to find and use only the original
request.
Wrapping the response and link it to it the wrapped request wont help
because Tomcat wont be able to cast to our custom wrappers.

>
> 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.

Do you know of another bigger web framework that uses this approach ?
If you know please mention it in the ticket. This will be a stronger
argument for Tomcat to not ignore this solution.

It all started with a ticket by me in Tomcat's Bugzilla to normalize
the absolute urls which are send in "Location" response header. This
is the redirect url. Before the ticket Tomcat was sending urls like
'http://www.example.com/a/b/../c/d.html' and '..' in this url caused
some problems in some cases, e.g. JMeter complained about it, and
Chris Colman reported an issue with IE when using Tomcat virtual
hosts.
So now Tomcat normalizes the url to
'http://www.example.com/a/c/d.html' before sending it to the client.
All good so far.

The new problem is that Tomcat uses the normalization even in
#encodeURL(), this method just encodes jsessionid if needed, even for
relative urls. To decide whether the relative url is part of the
current application Tomcat makes the url absolute and normalizes it.
When Wicket starts rendering the rendering for PageB (from my first
mail) it produces relative urls to PageB, but later Tomcat normalizes
them against PageA and url like
'http://www.example.com/a/b/../../../../c/d.html' fails because there
are too many '..'s.

I hope the problem is more clear now.

>
> 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.

They didn't workaround it yet. For now we discuss possible solutions
for the next version.

>
> 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
>



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message