On 6/22/20 12:37 PM, ylavic@apache.org wrote:
> Author: ylavic
> Date: Mon Jun 22 10:37:41 2020
> New Revision: 1879080
>
> URL: http://svn.apache.org/viewvc?rev=1879080&view=rev
> Log:
> Allow for proxy servlet mapping at pre_translate_name stage.
>
> Provide alias_match_servlet(), the servlet counterpart of alias_match(),
> which maps the request URI-path to the ProxyPass alias ignoring path
> parameters, while still forwarding them (above the alias).
>
> This is needed to proxy servlet URIs for application handled by Tomcat,
> which can then make use of the path/segments parameters.
>
> Github: closes #128
>
>
> Modified:
> httpd/httpd/trunk/modules/proxy/mod_proxy.c
> httpd/httpd/trunk/modules/proxy/mod_proxy.h
>
> Modified: httpd/httpd/trunk/modules/proxy/mod_proxy.c
> URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_proxy.c?rev=1879080&r1=1879079&r2=1879080&view=diff
> ==============================================================================
> --- httpd/httpd/trunk/modules/proxy/mod_proxy.c (original)
> +++ httpd/httpd/trunk/modules/proxy/mod_proxy.c Mon Jun 22 10:37:41 2020
> @@ -570,6 +570,198 @@ static int alias_match(const char *uri,
> return urip - uri;
> }
>
> +/*
> + * Inspired by mod_jk's jk_servlet_normalize().
> + */
> +static int alias_match_servlet(apr_pool_t *p,
> + const char *uri,
> + const char *alias)
> +{
The code for alias_match_servlet looks awful complex. I think it is this way not because it is done wrong in some way, but because
the problem to solve is complex. This brought me to the point if it is worth having this complexity.
My understanding is that the original issue we faced was that traversal problem as HTTP and Servlet spec handle path parameters
differently in the '..' case. So we need to do something about
/app/..;pp=somevalue/admin
URI patterns. The question for me is: Are URI's that contain these patterns sensible for a servlet based application or can we
always assume bad intentions by the originator? If we always assume bad intentions we could just reject such URI's (probably only
if they match a ProxyPass with a flag set, for the Rewrite case we could just document a Rewrite rule that kills them).
The other case I see covered with alias_match_servlet is the case where we have path parameters on the prefix part that ProxyPass
should match. Without this commit
/app;pp=something/somethingelse
wouldn't match
ProxyPass /app schema://backend/app
But given the complexity of the code I am not sure if these cases are worth fixing or if people should just use ProyPassMatch / a
RewriteRule that covers such cases if the application needs that. Of course that depends on how often such cases appear. If they
are frequent than a direct ProxyPass support seems sensible. If they are rare probably not.
Regards
Rüdiger
> Author: ylavic
> Date: Mon Jun 22 10:37:41 2020
> New Revision: 1879080
>
> URL: http://svn.apache.org/viewvc?rev=1879080&view=rev
> Log:
> Allow for proxy servlet mapping at pre_translate_name stage.
>
> Provide alias_match_servlet(), the servlet counterpart of alias_match(),
> which maps the request URI-path to the ProxyPass alias ignoring path
> parameters, while still forwarding them (above the alias).
>
> This is needed to proxy servlet URIs for application handled by Tomcat,
> which can then make use of the path/segments parameters.
>
> Github: closes #128
>
>
> Modified:
> httpd/httpd/trunk/modules/proxy/mod_proxy.c
> httpd/httpd/trunk/modules/proxy/mod_proxy.h
>
> Modified: httpd/httpd/trunk/modules/proxy/mod_proxy.c
> URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/mod_proxy.c?rev=1879080&r1=1879079&r2=1879080&view=diff
> ==============================================================================
> --- httpd/httpd/trunk/modules/proxy/mod_proxy.c (original)
> +++ httpd/httpd/trunk/modules/proxy/mod_proxy.c Mon Jun 22 10:37:41 2020
> @@ -570,6 +570,198 @@ static int alias_match(const char *uri,
> return urip - uri;
> }
>
> +/*
> + * Inspired by mod_jk's jk_servlet_normalize().
> + */
> +static int alias_match_servlet(apr_pool_t *p,
> + const char *uri,
> + const char *alias)
> +{
The code for alias_match_servlet looks awful complex. I think it is this way not because it is done wrong in some way, but because
the problem to solve is complex. This brought me to the point if it is worth having this complexity.
My understanding is that the original issue we faced was that traversal problem as HTTP and Servlet spec handle path parameters
differently in the '..' case. So we need to do something about
/app/..;pp=somevalue/admin
URI patterns. The question for me is: Are URI's that contain these patterns sensible for a servlet based application or can we
always assume bad intentions by the originator? If we always assume bad intentions we could just reject such URI's (probably only
if they match a ProxyPass with a flag set, for the Rewrite case we could just document a Rewrite rule that kills them).
The other case I see covered with alias_match_servlet is the case where we have path parameters on the prefix part that ProxyPass
should match. Without this commit
/app;pp=something/somethingelse
wouldn't match
ProxyPass /app schema://backend/app
But given the complexity of the code I am not sure if these cases are worth fixing or if people should just use ProyPassMatch / a
RewriteRule that covers such cases if the application needs that. Of course that depends on how often such cases appear. If they
are frequent than a direct ProxyPass support seems sensible. If they are rare probably not.
Regards
Rüdiger