Rewrite functionality for 8

[Remy Maucherat <re...@apache.org>]

Hi,

I ported a valve providing mod_rewrite functionality (most of it) for
Tomcat "8", and committed it in the sandbox. This could be easily placed
in the main repository, where it would provide an additional item in the
"new features" department for this major release.

I have a documentation page for it that could be included. The basics is
that it uses a rewrite.properties that has the same contents as the
configuration for mod_rewrite. The rewrite.properties is placed in the
host config folder if the valve is declared in a Host, or in WEB-INF in
the webapp if declared in a Context.

The main differences with mod_rewrite are:
- (the big one) no proxy flag
- no SSL attributes
- less file related flags available
- allows virtual host rewriting using a host flag (it replaces the host
header instead of the URL and maps again)
Point 2 and 3 are probably relatively easy to fix, while obviously a
proxy is a more involving endeavor.

There are rewrite solutions out there already, but this one does not use
complex tricks (because it can simply start over request processing
instead of doing more complex request dispatching, which also impacts
the Servlet state), and is mod_rewrite compatible.

Comments ? Is it nice or useless ?

Rémy



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

Re: Rewrite functionality for 8

[Remy Maucherat <re...@apache.org>]

On Mon, 2013-01-21 at 15:52 +0100, Henri Gomez wrote:
> mod_rewrite is definitvly HTTPd Swiss Knife and having it in Tomcat is
> definitivly a good news.
> 
> This valve is for Tomcat 8 and higher or could it be used with Tomcat 7 ?

It will probably not build as is but as with almost everything, it can
be backported.

Rémy



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

Re: Rewrite functionality for 8

[Henri Gomez <he...@gmail.com>]

mod_rewrite is definitvly HTTPd Swiss Knife and having it in Tomcat is
definitivly a good news.

This valve is for Tomcat 8 and higher or could it be used with Tomcat 7 ?

Cheers


2013/1/9 Remy Maucherat <re...@apache.org>

> Hi,
>
> I ported a valve providing mod_rewrite functionality (most of it) for
> Tomcat "8", and committed it in the sandbox. This could be easily placed
> in the main repository, where it would provide an additional item in the
> "new features" department for this major release.
>
> I have a documentation page for it that could be included. The basics is
> that it uses a rewrite.properties that has the same contents as the
> configuration for mod_rewrite. The rewrite.properties is placed in the
> host config folder if the valve is declared in a Host, or in WEB-INF in
> the webapp if declared in a Context.
>
> The main differences with mod_rewrite are:
> - (the big one) no proxy flag
> - no SSL attributes
> - less file related flags available
> - allows virtual host rewriting using a host flag (it replaces the host
> header instead of the URL and maps again)
> Point 2 and 3 are probably relatively easy to fix, while obviously a
> proxy is a more involving endeavor.
>
> There are rewrite solutions out there already, but this one does not use
> complex tricks (because it can simply start over request processing
> instead of doing more complex request dispatching, which also impacts
> the Servlet state), and is mod_rewrite compatible.
>
> Comments ? Is it nice or useless ?
>
> Rémy
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>

Re: Rewrite functionality for 8

[Konstantin Kolinko <kn...@gmail.com>]

2013/1/9 Remy Maucherat <re...@apache.org>:
> Hi,
>
> I ported a valve providing mod_rewrite functionality (most of it) for
> Tomcat "8", and committed it in the sandbox. This could be easily placed
> in the main repository, where it would provide an additional item in the
> "new features" department for this major release.
>
> I have a documentation page for it that could be included. The basics is
> that it uses a rewrite.properties that has the same contents as the
> configuration for mod_rewrite. The rewrite.properties is placed in the
> host config folder if the valve is declared in a Host, or in WEB-INF in
> the webapp if declared in a Context.
>
> The main differences with mod_rewrite are:
> - (the big one) no proxy flag
> - no SSL attributes
> - less file related flags available
> - allows virtual host rewriting using a host flag (it replaces the host
> header instead of the URL and maps again)
> Point 2 and 3 are probably relatively easy to fix, while obviously a
> proxy is a more involving endeavor.
>
> There are rewrite solutions out there already, but this one does not use
> complex tricks (because it can simply start over request processing
> instead of doing more complex request dispatching, which also impacts
> the Servlet state), and is mod_rewrite compatible.
>
> Comments ? Is it nice or useless ?
>

1. First concern that I see here is how is this compatible with
AccessLogValve? The valve should log original request, and what
happens if you rewrite it?

2. Is it compatible with async processing?


3. Generally, having such a feature would be useful, but I am afraid
that it will be abused.

I would like to deem it as "experimental" and to continue to promote
url-rewrite filter as the recommended solution.


Several comments on the code:

4.
> protected String resourcePath = "rewrite.properties"

I do not like the file name "rewrite.properties" as it is not a Java
properties file. Maybe "rewrite.config" ?

5.
> new InputStreamReader(is)

Using an InputStreamReader like the above to read configuration files
is broken. You have to specify an encoding explicitly, e.g. UTF-8.

I think "default encoding" is only useful when you are reading/writing
to a console. I other cases it is an oversight.

6.
> invoked.set(null);

Clearing the flag (the thread local variable) must be done in a finally{} block.

7.
> rules[i]
in every line...  Declare a local variable.


8. Maybe add a property to this valve named "enabled". The idea is
from AccessLogValve that has such a property. If its value is false,
pass the request through as is without any rewriting.




Best regards,
Konstantin Kolinko

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

Re: Rewrite functionality for 8

[Remy Maucherat <re...@apache.org>]

On Fri, 2013-01-11 at 18:34 +0100, Rainer Jung wrote:
> I only had a look at the code and didn't play with it yet. I'm
> positively impressed how complete w.r.t. mod_rewrite compatibility it
> looks and personally I think it is nice and useful.

Thanks !

> One question that came to my mind and which I did not yet try to find
> the answer myself is the merging behavior of the rules if the valve is
> configured at host and context level.

I didn't really think about this scenario. There's no direct interaction
between the two valves. For the current implementation, if the valve in
the context has its config file in /WEB-INF/rewrite.properties, it will
use that. If not, it will try to use
conf/Catalina/localhost/rewrite.properties (the valve defined on the
host will only look there). But there's no rule inheritance or something
like it.

The two rewrite valves will do their processing only once (the valve has
a thread local boolean to avoid rewriting more than once per request).
If both valves do a rewrite, here's the processing (assuming the mapping
of the host and context doesn't change, since the request is pretty much
allowed to bounce between hosts and contexts as long as rewriting occurs
in each host or context):
adapter (mapping 1) -> rewrite in host -> adapter (mapping 2) -> rewrite
in context -> adapter (mapping 3) -> webapp

Rémy



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

Re: Rewrite functionality for 8

[Rainer Jung <ra...@kippdata.de>]

Hi Remy,

On 09.01.2013 16:04, Remy Maucherat wrote:
> Hi,
> 
> I ported a valve providing mod_rewrite functionality (most of it) for
> Tomcat "8", and committed it in the sandbox. This could be easily placed
> in the main repository, where it would provide an additional item in the
> "new features" department for this major release.
> 
> I have a documentation page for it that could be included. The basics is
> that it uses a rewrite.properties that has the same contents as the
> configuration for mod_rewrite. The rewrite.properties is placed in the
> host config folder if the valve is declared in a Host, or in WEB-INF in
> the webapp if declared in a Context.
> 
> The main differences with mod_rewrite are:
> - (the big one) no proxy flag
> - no SSL attributes
> - less file related flags available
> - allows virtual host rewriting using a host flag (it replaces the host
> header instead of the URL and maps again)
> Point 2 and 3 are probably relatively easy to fix, while obviously a
> proxy is a more involving endeavor.
> 
> There are rewrite solutions out there already, but this one does not use
> complex tricks (because it can simply start over request processing
> instead of doing more complex request dispatching, which also impacts
> the Servlet state), and is mod_rewrite compatible.
> 
> Comments ? Is it nice or useless ?

I only had a look at the code and didn't play with it yet. I'm
positively impressed how complete w.r.t. mod_rewrite compatibility it
looks and personally I think it is nice and useful.

One question that came to my mind and which I did not yet try to find
the answer myself is the merging behavior of the rules if the valve is
configured at host and context level.

Regards,

Rainer

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

Re: Rewrite functionality for 8

[Yoav Shapira <yo...@apache.org>]

Nice!

Thanks,

Yoav


On Wed, Jan 9, 2013 at 10:04 AM, Remy Maucherat <re...@apache.org> wrote:
> Hi,
>
> I ported a valve providing mod_rewrite functionality (most of it) for
> Tomcat "8", and committed it in the sandbox. This could be easily placed
> in the main repository, where it would provide an additional item in the
> "new features" department for this major release.
>
> I have a documentation page for it that could be included. The basics is
> that it uses a rewrite.properties that has the same contents as the
> configuration for mod_rewrite. The rewrite.properties is placed in the
> host config folder if the valve is declared in a Host, or in WEB-INF in
> the webapp if declared in a Context.
>
> The main differences with mod_rewrite are:
> - (the big one) no proxy flag
> - no SSL attributes
> - less file related flags available
> - allows virtual host rewriting using a host flag (it replaces the host
> header instead of the URL and maps again)
> Point 2 and 3 are probably relatively easy to fix, while obviously a
> proxy is a more involving endeavor.
>
> There are rewrite solutions out there already, but this one does not use
> complex tricks (because it can simply start over request processing
> instead of doing more complex request dispatching, which also impacts
> the Servlet state), and is mod_rewrite compatible.
>
> Comments ? Is it nice or useless ?
>
> Rémy
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>

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

Re: Rewrite functionality for 8

[Remy Maucherat <re...@apache.org>]

On Wed, 2013-01-09 at 13:16 -0500, Christopher Schultz wrote:
> I haven't looked at the code but my first reaction was "why not use
> url-rewrite?" When you say that it can re-start request processing, you
> mean that you can essentially perform internal rewrites/forwards/etc.
> without having to use the request dispatcher? Certainly reducing stack
> size is not a bad idea and should improve performance.

It may improve performance, but most importantly the application's state
is untouched. It will not see any of the original request in its
filters, only the modified one, etc.

> The fact that it is mostly compatible with mod_rewrite configuration
> syntax is definitely a plus, though url-rewrite 4 can read
> mod_rewrite-style configuration files, too.
> 
> Finally, there is the spec-versus-implementation issue. It's great that
> Tomcat could provide this kind of capability, but since it is
> out-of-spec we might be doing a disservice to our users. I know I'm
> always irritated when someone posts to the users' list that they are
> switching from JBoss/Sun/Jetty/Whatever and Tomcat doesn't mirror some
> out-of-spec capability and they are all mad about it. That's what I like
> about url-rewrite: you make it a part of your webapp and it should work
> everywhere.

The valve works at the vhost level as well (as I mentioned in my
previous email), there were [minor] user requests for "creative" vhost
mapping.

So it should be able to do a lot of things that are quite complex to do
otherwise, and is generally useful for customer support [since it can do
anything except proxying].

Rémy



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

Re: Rewrite functionality for 8

[Christopher Schultz <ch...@christopherschultz.net>]

Remy,

On 1/9/13 10:04 AM, Remy Maucherat wrote:
> Hi,
> 
> I ported a valve providing mod_rewrite functionality (most of it) for
> Tomcat "8", and committed it in the sandbox. This could be easily placed
> in the main repository, where it would provide an additional item in the
> "new features" department for this major release.
> 
> I have a documentation page for it that could be included. The basics is
> that it uses a rewrite.properties that has the same contents as the
> configuration for mod_rewrite. The rewrite.properties is placed in the
> host config folder if the valve is declared in a Host, or in WEB-INF in
> the webapp if declared in a Context.
> 
> The main differences with mod_rewrite are:
> - (the big one) no proxy flag
> - no SSL attributes
> - less file related flags available
> - allows virtual host rewriting using a host flag (it replaces the host
> header instead of the URL and maps again)
> Point 2 and 3 are probably relatively easy to fix, while obviously a
> proxy is a more involving endeavor.
> 
> There are rewrite solutions out there already, but this one does not use
> complex tricks (because it can simply start over request processing
> instead of doing more complex request dispatching, which also impacts
> the Servlet state), and is mod_rewrite compatible.
> 
> Comments ? Is it nice or useless ?

I haven't looked at the code but my first reaction was "why not use
url-rewrite?" When you say that it can re-start request processing, you
mean that you can essentially perform internal rewrites/forwards/etc.
without having to use the request dispatcher? Certainly reducing stack
size is not a bad idea and should improve performance.

The fact that it is mostly compatible with mod_rewrite configuration
syntax is definitely a plus, though url-rewrite 4 can read
mod_rewrite-style configuration files, too.

Finally, there is the spec-versus-implementation issue. It's great that
Tomcat could provide this kind of capability, but since it is
out-of-spec we might be doing a disservice to our users. I know I'm
always irritated when someone posts to the users' list that they are
switching from JBoss/Sun/Jetty/Whatever and Tomcat doesn't mirror some
out-of-spec capability and they are all mad about it. That's what I like
about url-rewrite: you make it a part of your webapp and it should work
everywhere.

In general, I'm -0 on the idea mostly given the existence of a
well-supported alternate tool (url-rewrite) and the risks of vendor
lock-in (even when the vendor is the ASF ;).

-chris