tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <>
Subject Re: Improving mod_jk URI forwarding
Date Sun, 20 May 2007 18:58:19 GMT

"Rainer Jung" <> wrote in message
> Jean-Frederic wrote:
>> On Sun, 2007-05-20 at 18:17 +0200, Rainer Jung wrote:
>>> Before I answer, let me first ask a question: What's wrong withg my 
>>> suggestion?
>> Well thinking to it I am not very happy with the change:
>> +++
>> +++
>> Because that is what the SPEC's says.
> The Servlet SPEC says, that the web container should not decode 
> RequestURI. So if the reverse proxy tries to come close to this 
> requirement, it needs to send the URI as unencoded as it can.
> Now the reverse proxy should have the ability to modify the URI (in the 
> sense of mod_rewrite). If we accept, that mod_rewrite in httpd 1.3-2.2 is 
> only able to operate on the decoded URI, we have no chance of making this 
> interoperable with forwarding the original undecoded URI.

Yes, RFC 2616 permits *any* intermediate proxy to alter the URI in *any* way 
before passing it on.  So to be meaningful, the Servlet spec requirement can 
only apply to the URI that TC receives from the last proxy in the chain.

> Using the encoding from mod_proxy_ajp we at least try to produce a URI 
> which is as close to the original one, as we can achieve. At least 
> logically the new URI is fine.
> All in all I think that "compat unparsed" will result in more user 
> problems as default then the new proposed way.
> The whole discussion is:
> 1) At the moment all options have a problem (mod_rewrite, sessions, 
> security)
> 2) My proposal should be checked if it is secure. If so, it fixes 
> mod_rewrite, sessions and security. This seems to have some value. If you 
> (community) agree on that value, I find it correct to add this option. The 
> answers might depend on
> - encode only '%'
> - encode '%' and '+' (easy, performing, but needs some thinking about 
> correctness)

We pass the original query string to TC, so there is no point in worrying 
about '+' (since it only means ' ' in the qs).

> - encode like in mod_proxy_ajp (not as performing but more complete)
> 3) Yes, it will influence how well the container can obey the spec (as two 
> of the three existing options also do). So we could discuss, if the value 
> is huge enough, that we make it the default (and thus need no more 
> explicit option name), or we keep "compat unparsed" the default and add a 
> new option.
> Regards,
> Rainer 

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message