mod_rewrite Interceptor - feedback please!!

[Mike Bremford <mi...@paperx.com>]

Hi all

I'm trying to write an interceptor to handle URI's rewritten by Apache's
mod_rewrite, but this is the first time I've opened Tomcat up - feedback on
my approach would be valuable.


The route I've taken is:

1. Read the rewritten URI in the Ajp12Connection, store it as a note on the
request.
2. Create a new interceptor (tentatively called ApacheInterceptor) which
reads the note and does something with it.


What I'm pondering at the moment is the best way to instruct Tomcat to use
the correct file but still have getRequestURI return the correct value. Here
are the options so far:


1. Set the ServletPath, leave the URI untouched.
   * Pros: Works perfectly (this is what JServ did), very low impact (one
line in  the Interceptor).
   * Cons: Seems to violate the Servlet 2.2 Spec. (Can someone who knows the
spec better than I confirm this).


2. Treat the redirected URI as a jsp:include by setting
javax.servlet.include.servlet_path.
   * Pros: Equally low impact, doesn't violate the spec like #1.
   * Cons: This works for JSP's, but will it work for servlets? The 2.2 spec
section 8.3 also limits what headers I can set in an include, which rules
this one out I believe.


3. Modify the HttpServletRequestFacade, so getRequestURI and related methods
return the rewritten URI (if it exists).
   * Pros & Cons: Don't know, but it looks good. My current favourite.


I'm swimming a bit out of my depth here - help! Any tips, thoughts or
whatever would be appreciated.


Cheers.... Mike

PS. In my efforts to work out what the hell is going on, I've knocked up a
quick diagram which may be useful to others working on Tomcat source for the
first time (assuming it's correct that is - can someone check it for errors?
It's at http://big.faceless.org/tomcat/requestflow.gif)

RE: mod_rewrite Interceptor - feedback please!!

[Mike Bremford <mi...@paperx.com>]

Hi Costin

> Before another war starts ( as this is definely not compliant with the
> servlet spec - even worse than the case-sensitive problem ),
> can you tell
> me how does Apache pass this information ?

<g> OK - I can't speak for mod_jk, but in mod_jserv it's passed in as the
field marked as "Script Name". As an example, if I call the URI /miketest,
which is rewritten to /cgi-bin/test, here's my environment.

REQUEST_URI=/miketest
SCRIPT_NAME=/cgi-bin/test
SCRIPT_FILENAME=/export/web/travolta/cgi-bin/test
REDIRECT_URL=/miketest

> What you do is a "special" mapping, common in Apache, IIS,
> NES ( and web
> server ) world, but illegal in servlets. That probably
> means it will never be enabled by default ( I hope we'll find a way to
> check in all the contributed interceptors - in a contrib/
> directory for example).

([OT] - Has anyone contributed a JSSI Interceptor? I share a server with a
guy who's never going to rewrite his code so we can migrate from JServ, but
with an interceptor I won't have to!)

Unfortunately I've come to the same conclusion - a shame, since I've spent
all week on it!

The thing I could never work out is, given a URI which *doesn't* map
directly to a file, how do you split it into Context Path, Servlet Path and
Path Info? What if you redirect from one context to another? (Aargh)

> Let me know how I can help, as I would like this problem
> resolved. Fact  is that servlet API define a ( maybe perfect ) set of
> mapping rules and all other servers use a ( maybe completely stupid
> ) different set of rules, and as long as Apache and other web
> server will persist in mistake and implement the "wrong" mappings they
> implemented for years, we'll have to have a way to  deal with that.

I'm fairly convinced there is no clean way of doing it so that it matches
the behaviour of CGI scripts, at least in 2.2. It would be an interesting
project to duplicate the functionality of mod_rewrite using a 2.3 filter.

If I had to make the call I would say make the rewritten URI become the
actual URI. This means the URI will always map to a physical file, avoiding
the problems above. It also is consistent with the way Resin does it.

I also liked what you were saying about setting an attribute. If people are
using mod_rewrite and if these restrictions are documented AND they can get
at the original URI that was requested, it's not too bad.

I've attached a patch to Apj12ConnectionHandler.java from Tomcat 3.2b3. (I
haven't done mod_jk, but it's a simple patch). Tweak it all you like. I
don't see why it wouldn't work with other webservers, but obviously I
haven't checked it.

>
> Costin
>

Cheers... Mike

RE: mod_rewrite Interceptor - feedback please!!

[cm...@yahoo.com]

Hi,

Before another war starts ( as this is definely not compliant with the
servlet spec - even worse than the case-sensitive problem ), can you tell
me how does Apache pass this information ?

What you do is a "special" mapping, common in Apache, IIS, NES ( and web
server ) world, but illegal in servlets. That probably
means it will never be enabled by default ( I hope we'll find a way to
check in all the contributed interceptors - in a contrib/ directory for
example). 

Let me know how I can help, as I would like this problem
resolved. Fact  is that servlet API define a ( maybe perfect ) set of
mapping rules and all other servers use a ( maybe completely stupid
) different set of rules, and as long as Apache and other web server will
persist in mistake and implement the "wrong" mappings they
implemented for years, we'll have to have a way to  deal with that. 

Costin


> 
> > I'm not sure how it works - the original request URI is re-written by
> > Apache, and you want the new request to be processed by tomcat?
> 
> Yup. The problem is that the servlet should see the **ORIGINAL URI**
> requested by the user, not the rewritten one. Important for relative URIs,
> for instance. This is the way both CGI and Apache/JServ work. The idea is
> that I can hide the internal structure of my site from the user.
> 
> > In this case you just need to change the fields in Request
> > probably both
> > URI and servletPath.
> 
> This passes through the rewritten URI instead of the original (this is what
> Resin does too, incidentally).
> 
> The main reason this is so tricky is that the URI is directly linked with
> the filename - a layer of abstraction between them would make this a lot
> easier. Either that or the ability to apply a chain of mappings, rather than
> just one (eg. map x.jsp to y.jsp, which maps to the JSP servlet, but the URI
> remains "x.jsp").
> 
> 
> > Please don't change the Facade - you can change
> > Request/Response if you
> > want. The facade is supposed to have minimal functionality, and be as
> > simple as possible ( and we'll likely have multiple facades - one for
> > servlet 2.3 ).
> 
> Gotcha. I'll have a crack at the Request object and see how I go.
> 
> > > It's at http://big.faceless.org/tomcat/requestflow.gif)
> > Excelent - can I check it in ?
> 
> Knock yourself out ;-). I hope it's correct!
> 
> > Costin
> 
> Cheers (and thanks for the feedback!)... Mike
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> 

RE: mod_rewrite Interceptor - feedback please!!

[Mike Bremford <mi...@paperx.com>]

Hi Costin

> I'm not sure how it works - the original request URI is re-written by
> Apache, and you want the new request to be processed by tomcat?

Yup. The problem is that the servlet should see the **ORIGINAL URI**
requested by the user, not the rewritten one. Important for relative URIs,
for instance. This is the way both CGI and Apache/JServ work. The idea is
that I can hide the internal structure of my site from the user.

> In this case you just need to change the fields in Request
> probably both
> URI and servletPath.

This passes through the rewritten URI instead of the original (this is what
Resin does too, incidentally).

The main reason this is so tricky is that the URI is directly linked with
the filename - a layer of abstraction between them would make this a lot
easier. Either that or the ability to apply a chain of mappings, rather than
just one (eg. map x.jsp to y.jsp, which maps to the JSP servlet, but the URI
remains "x.jsp").


> Please don't change the Facade - you can change
> Request/Response if you
> want. The facade is supposed to have minimal functionality, and be as
> simple as possible ( and we'll likely have multiple facades - one for
> servlet 2.3 ).

Gotcha. I'll have a crack at the Request object and see how I go.

> > It's at http://big.faceless.org/tomcat/requestflow.gif)
> Excelent - can I check it in ?

Knock yourself out ;-). I hope it's correct!

> Costin

Cheers (and thanks for the feedback!)... Mike

Re: mod_rewrite Interceptor - feedback please!!

[cm...@yahoo.com]

Hi,

I'm not sure how it works - the original request URI is re-written by
Apache, and you want the new request to be processed by tomcat? 

In this case you just need to change the fields in Request probably both
URI and servletPath. 

If you want to access both the original and the re-written URI you can use
an attribute - the spec doesn't have any mention of this ( AFAIK ) and all
rules applies to the original request. See also the discussion about
case-sensitivity ( probably a particular case of rewrite ).


> 3. Modify the HttpServletRequestFacade, so getRequestURI and related methods
> return the rewritten URI (if it exists).
>    * Pros & Cons: Don't know, but it looks good. My current favourite.

Please don't change the Facade - you can change Request/Response if you
want. The facade is supposed to have minimal functionality, and be as
simple as possible ( and we'll likely have multiple facades - one for
servlet 2.3 ).

> PS. In my efforts to work out what the hell is going on, I've knocked up a
> quick diagram which may be useful to others working on Tomcat source for the
> first time (assuming it's correct that is - can someone check it for errors?
> It's at http://big.faceless.org/tomcat/requestflow.gif)

Excelent - can I check it in ? 

Costin