tomcat-dev mailing list archives

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

"Rainer Jung" <rainer.jung@kippdata.de> wrote in message 
news:46508CC3.70601@kippdata.de...
> 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:
>> +++
>> -#define JK_OPT_FWDURIDEFAULT        JK_OPT_FWDURICOMPATUNPARSED
>> +#define JK_OPT_FWDURIDEFAULT        JK_OPT_FWDURIESCAPEDMINIMAL
>> +++
>> 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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message