gigazhang / urlrewritefilter Goto Github PK

One of the most powerful rewrite features that I use in Apache's rewrite
module is the "QueryStringAppend" [QSA] flag. Unfortunately, the
urlrewritefilter does not support this "flag" (bottom of the page at
http://urlrewritefilter.googlecode.com/svn/trunk/src/doc/manual/3.1/index.html).
I needed this filter functionality many a times in my JAVA stack of
applications. Should we provision a support for this flag?
I have modified my urlrewritefilter source to make the same work for me. If
you guys feel the need for such a support in the codebase, I can share the
implementation.

Nice filter to use though :)

Cheers
Avlesh
http://www.avlesh.com/

I wasn't sure where to post this, but it was difficult to find in the 
documentation. 

So, I had the need to redirect subdomains on a SaaS server. (ie, customers have 
myname.mysite.com ).  And If you have multiple subdomains, like mysite1.com and 
mysite2,com, 
you may have the situation like I did were your security certificate is only 
one one domain.  So, 
you would like to take all requests to:
http://myname.myUnsecureDomain.com => https://myname.mySecureDomain.com

This can be done with the following rule:
    <rule>
        <name>Redirect forum</name>
        <condition name="host" operator="equal">^(.*).myunsecuredomain.com$</condition>
        <from>^(.*)$</from>
        <to type="permanent-redirect">https://%1.mysecuredomain.com$1</to>
    </rule> 

request-uri-extension is uri extensionName

/foo.html  =>  html
/foo.js  => js
/foo  => EMPTY constant string

this is useful for some usecase.

The initial requirements are specified in the google group.

In our application we cannot bundle configuration files with the main web
application, instead configuration files are served, by secondary web
applications that correspond to the vhost of the incoming request, to the main
web application.

For this reason we require that the UrlRewriteFilter can handle multiple
urlrewrite.xml configuration files and for each request use the one appropriate
for the vhost.

I've achieved this by:
1) Taking out all the methods and logic related to the UrlRewriter member field
in UrlRewriteFilter to a separate class called UrlRewritterContainer. 
2) UrlRewriteFilter contains one non-final method "getUrlRewriterContainer". By
default returns an unmodified UrlRewriterContainer that behaves as it does
today.
3) UrlRewriterContainer contains one non-final method "getInputStream". By
default it returns the input stream to the WEB-INF/urlrewrite.xml resource.


This allowed for me in my application to override UrlRewriteFilter's
getUrlReriterContainer so that a different UrlRewriterContainer is returned
corresponding to each different vhost. Each UrlRewriterContainer overrides the
getInputStream to the corresponding urlrewrite.xml that is loaded from the
secondary web applications.
This patched version of urlrewrite will be running in production next week at
http://sesam.no


The patch is generic and only makes two methods non-final to supply this extra
feature to the urlrewrite library. No architecture in the library changes, and
the UrlRewriteFilter is broken down into more logical individual components.
For all of these reasons i hope the patch gets accepted :-)

------- Additional comments from michaelwever Tue Mar 20 09:55:56 +0000
2007 -------

Created an attachment (id=1)
Diff to existing code

------- Additional comments from michaelwever Tue Mar 20 09:56:49 +0000
2007 -------

Created an attachment (id=2)
New .java file

------- Additional comments from ptuckey Wed Apr 11 03:46:44 +0000 2007 -------

This will be merged into main source.

------- Additional comments from michaelwever Mon Apr 23 10:12:38 +0000
2007 -------

Status on this?

------- Additional comments from ptuckey Wed Apr 25 03:53:00 +0000 2007 -------

I've started on this.  Can't help thinking this would be better achieved by
refactoring the UrlRewriteFilter class, which could then be extended in your
applciation.  Am looking into it.  

------- Additional comments from michaelwever Mon Sep 17 11:58:09 +0000
2007 -------

What the status on this?
I thought that you had done some work for me to test?

note, moved here from 
https://urlrewrite.dev.java.net/issues/show_bug.cgi?id=9

Currently OutboundRule is a final class so we cannot provide custom
implementations of OutboundRule. Preferably, extract interface out of
OutboundRule or make it a non-final class.

I have the following rule in my urlrewrite:
<rule>
  <from>^/mytest</from>
  <to type="redirect">/myron/sample.ep?template=mypremisepen</to>
</rule>

If www.myron.com/mytest is entered, this rule works.
However, if there is a typo in the URL (i.e. www.myron.com/mytestabc),
the extra characters at the end of URL (abc) get appended at the end of 
the "redirect" URL. So, "/myron/sample.ep?template=mypremisepen" 
becomes "/myron/sample.ep?template=mypremisepenabc"
and our application generates an error

urlwrite Version 2.6

thank you.

I'd like to fix an issue I am seeing with this project and would be happy
to write a test to reproduce and fix the problem. However, my checkout of
the 3.2.0 release is failing with:

Tests run: 220, Failures: 1, Errors: 22, Skipped: 0


What steps will reproduce the problem?
1. Check out http://urlrewritefilter.googlecode.com/svn/tags/3.2.0
2. mvn install

Is this the right way to test and build the project? I did not see a guide
to building and testing.

What steps will reproduce the problem?
1. put ":" character into url that is beeing rewriten 
2. the unsupported encoding exception raise immediately


What is the expected output? What do you see instead?

I should get the page with search results

Instead I see this exception: 
java.io.UnsupportedEncodingException: dog
        at java.net.URLEncoder.encode(URLEncoder.java:200)
        at
org.tuckey.web.filters.urlrewrite.functions.StringFunctions.escape(StringFunctio
ns.java:49)
        at
org.tuckey.web.filters.urlrewrite.utils.FunctionReplacer.functionReplace(Functio
nReplacer.java:118)
        at
org.tuckey.web.filters.urlrewrite.utils.FunctionReplacer.replace(FunctionReplace
r.java:78)
        at
org.tuckey.web.filters.urlrewrite.RuleBase.matchesBase(RuleBase.java:248)
        at
org.tuckey.web.filters.urlrewrite.NormalRule.matches(NormalRule.java:91)
        at
org.tuckey.web.filters.urlrewrite.RuleChain.doRuleProcessing(RuleChain.java:83)
        at
org.tuckey.web.filters.urlrewrite.RuleChain.process(RuleChain.java:137)
        at
org.tuckey.web.filters.urlrewrite.RuleChain.doRules(RuleChain.java:144)
        at
org.tuckey.web.filters.urlrewrite.UrlRewriter.processRequest(UrlRewriter.java:92
)
        at
org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter(UrlRewriteFilter.jav
a:381)



What version of the product are you using? On what operating system?

Version 3.2.0 beta on Windows XP

Please provide any additional information below.

It seems that tuckey rewrite is unable to process character: ":". I have a
search page with for example url: http://localhost/search/town:
springfield/in/category. Having this url will result into exception beeing
thrown by tuckey and page is redirected to http://localhost/.

What steps will reproduce the problem?
1. have a urlrewrite rule which adds a parameter to the request
2. fetch the incoming requests parameter map
3.

What is the expected output? What do you see instead?
The request object should return a map of all the request parameters (including 
the ones added 
by the urlrewrite filter), instead you get an expectation about trying to add 
to an immutable map.

What version of the product are you using? On what operating system?
3.2.0 on os x

Please provide any additional information below.

A fix for the problem is to create a new map rather than trying to edit the 
immutable one. Here's 
my fix for UrlRewriteWrappedRequest:getParameterMap()

    public Map getParameterMap() {      
        if (overridenParameters != null) {
            //the super map can't be modified
            Map modMap = new HashMap(super.getParameterMap());
            modMap.putAll(overridenParameters);
            return modMap;
        }
        return super.getParameterMap();
    }

What steps will reproduce the problem?
1. setup rule that uses type="proxy"
2. setup proxy target that returns output as 'chunked' output. I used
geoserver.  Use any geoserver setup.
3.

What is the expected output? What do you see instead?

When proxying the chunked response back to the requester, the data is
accumulated (probably incorrectly) rather than returned untouched. A
logically complete response is returned instead but the header
'transfer-encoding: chunked' is not removed from the response to the
requester.  This randomly breaks images and Geoserver's map tiles.

I fixed this for my case (by removing the transfer-encoding header) but I'm
sure there are cases where the encoding should be preserved the chunks
returned mostly untouched.  This fix will likely not help streaming
sources...  Map tiles have a definitive end.  I leave it to you to decide
what to do.  I would at least appreciate the inclusion of this patch as
type=proxy is not usable for the quasi case now.

What version of the product are you using? On what operating system?

urlrewrite 3.2 on Linux/Windows with JBOSS 4.2.2.GA.


Please provide any additional information below.

This is key to moving GeoServer behind a proxy!  Hopefully others can benefit.

* It works alongside with the current mapping xml.
* Takes a custom syntax which is a per page pattern configuration.
* Check this URL for more info
http://docs.google.com/View?docid=dk3vtwp_79chws9sdj
* We use this extension for all our normal pages and fall back to the
old style for more complex usecases

I originally posted this in the group:
http://groups.google.com/group/urlrewrite/browse_thread/thread/63e4f091564768a0
specifically mentioning %{query-string}.  The problem is more general than
that.

What steps will reproduce the problem?
1. Define a rule that sets a request attribute containing the query string,
e.g.:
<set name="urlrewrite.originalQueryString">%{query-string}</set>

2. Invoke a URL that matches the URL with a query parameter that contains a
dollar sign.  E.g.
 /whatver?x=$

What is the expected output? What do you see instead?
It should insert the query string into the request attribute.  Instead it
throws an exception:
 java.lang.StringIndexOutOfBoundsException: String index out of range: 3
        at java.lang.String.charAt(String.java:687)
        at java.util.regex.Matcher.appendReplacement(Matcher.java:711)
        at
org.tuckey.web.filters.urlrewrite.VariableReplacer.replace(VariableReplacer.java
:
88) 


What version of the product are you using? On what operating system?
Occurs with latest trunk revision: 105

Please provide any additional information below.
Problem is due to regex replacement.  It fails if a replacement value
contains a dollar or slash.  Problem also occurs for
%{session-attribute:whatever} replacement.

Attached a patch that:
a) Adds unit test to reproduce the problem
b) Fixes the problem

If you use port in your url (like browsing http://stage.test.com:8080), its
included in the server-name or host in condition element check. I guess it
shouldnt be, as request.getServerName() does not include the port.

Following log debug:
2009-08-19 16:51:29,326 stdout DEBUG
org.tuckey.web.filters.urlrewrite.Condition  evaluating
"stage.test.com:8080" against ^stage.test.com$ 
2009-08-19 16:51:29,326 stdout DEBUG
org.tuckey.web.filters.urlrewrite.RuleBase  conditions do not match

With a rule like this:
    <rule>
        <from>^/((directory)(.*))$</from>        
        <condition name="server-name" operator="equal">stage.test.com</condition> 
        <to type="redirect">http://stage2.test.com%{context-path}/$1</to>
    </rule>

I realise that I can put the port or a regex in the value of condition
element. But the condition should be a match anyway I think. Version 3.2.0.

Thanks for a great package!

Make the  all the classes non-final as far as possible. 

I wish to extend UrlRewriterFilter by having a custom configuration syntax.
If the Conf class is not final I could have plugged in my own COnf easily.

Even better , I wish that loadDom and processConfDoc as protected so that I
ca easily plugin my custom syntax into the same xml

The first line in UrlRewriter.getNewChain(..)
String servletPath = hsRequest.getServletPath();
obtains the servlet path decoded.
EG the url /katalog/jack+%26+jones
is returned as
/katalog/jack+&+jones

My rewrite rule (with decode-using="null")

<rule><from>^/katalog/(.*)$</from><to>/search/?c=y&amp;q=$1&amp;who=$1&amp;where
=</to></rule>
will then rewrite it to
/search/?c=y&amp;q=jack+&amp;+jones&amp;who=tofte+&amp;+jones&amp;where=
The &amp; is interpretted as a parameter deliminator and so jones is not
includes in the q parameter.
The rewritten url should be 
/search/?c=y&amp;q=jack+%26+jones&amp;who=tofte+%26+jones&amp;where=

What steps will reproduce the problem?
1. add jar file and change WEB-INF/web.xml
2. add WEB-INF/urlrewrite.xml
    <rule>
        <note>
            The rule means that requests to /test/status/ will be 
redirected to /rewrite-status
            the url will be rewritten.
        </note>
        <from>^/gallery/abc</from>   
        <to>/gallery?name=abc</to>  
    </rule>

3. gallery class in Application.java defined
   mount(QueryStringUrlCodingStrategy("/gallery", gallery.class));
   mount(QueryStringUrlCodingStrategy("/home", Home.class));

  public Class getHomePage() {
        return Home.class;
  }


What is the expected output? What do you see instead?
   if i open http://www.xxxx.com/gallery/abc,but server not found 'abc',so 
redirect the home page,and url will be changed http://www.xxxx.com/home
   if i change  WEB-INF/urlrewrite.xml
   <rule>
        <note>
            The rule means that requests to /test/status/ will be 
redirected to /rewrite-status
            the url will be rewritten.
        </note>
        <from>^/gallery/abc</from>   
        <to>/test.jsp?name=abc</to>  
    </rule>
  it can open test.jsp and url path not changed.


What version of the product are you using? On what operating system?
 version 3.1

Please provide any additional information below.
  if i want to use urlrewrite on wicket,and not change url path,
  http://www.xxx.com/gallery/abc 
  replace
  http://www.xxx.com/gallery?name=abc
  what can i do?


  thanks

What steps will reproduce the problem?
1. Create a rule with a set with a variable that will contain a $n, for
example:
    <from>^/(.*)$</from>
    <set name="urlrewrite.originalRequestUri">%{request-uri}</set>
    <set name="urlrewrite.originalQueryString">%{query-string}</set>
    <to last="false">/app/$1</to>
2. Hit a url that matches from with a query string containing "$2".  E.g.
 /q?keyword=$2

(admittedly "$" should be encoded in the url, but users are free to do
stuff like this; anyhow many other variable values could contain "$2")

What is the expected output? What do you see instead?
An exception is thrown:
java.lang.IndexOutOfBoundsException: No group 2
    at java.util.regex.Matcher.group(Matcher.java:470)
    at java.util.regex.Matcher.appendReplacement(Matcher.java:737)
    at java.util.regex.Matcher.replaceAll(Matcher.java:813)
    at
org.tuckey.web.filters.urlrewrite.utils.RegexMatcher.replaceAll(RegexMatcher.jav
a:72)
    at
org.tuckey.web.filters.urlrewrite.SetAttribute.execute(SetAttribute.java:185)
    at org.tuckey.web.filters.urlrewrite.RuleBase.matchesBase(RuleBase.java:202)
    at org.tuckey.web.filters.urlrewrite.NormalRule.matches(NormalRule.java:88)
    at
org.tuckey.web.filters.urlrewrite.RuleChain.doRuleProcessing(RuleChain.java:79)
    at org.tuckey.web.filters.urlrewrite.RuleChain.process(RuleChain.java:133)
    at org.tuckey.web.filters.urlrewrite.RuleChain.doRules(RuleChain.java:140)
    at
org.tuckey.web.filters.urlrewrite.UrlRewriter.processRequest(UrlRewriter.java:90
)
    at
org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter(UrlRewriteFilter.jav
a:406)


What version of the product are you using? On what operating system?
3.0.4
Confirmed with trunk latest too.

Please provide any additional information below.

Attached a patch that fixes the problem by moving the capture-group
substitution _prior_ to variable and backref replacement in SetAttribute. 
It seems unlikely that anyone would expect a "$n" in a variable replacement
to actually result in a capture group replacement.  Only capture groups
literally written in the SetAttribute value will be substituted.

It includes a couple of unit tests, one of which tests the issue and
confirms it is fixed.

I am rewriting URLs to images that have spaces in their names. Something like:

<rule>
    <from>^/img/(.*)$</from>
    <to>/images/$1</to>
</rule>

The images themselves are being served by the container (Tomcat 6). When
image names have spaces in them, Tomcat reports a 404 because the to URL is
not being encoded and has a space in the name.

Changing this to <to encode="true"> has no effect because
NormalRewrittenUrl.doRewrite() does not encode forwards, only redirects.

I believe this is a bug in NormalRewrittenUrl as these forwards will always
fail for URLs that require reencoding.

I looked in to writing a test for this but the 3.2.0 test suite is failing
for me on clean checkout and I didn't want to get in to figuring out what
was going on there.

Hi All,

How do i configure to redirect to subdomain.

For e.g. i have a domain called www.xyz.com

for a specific college we need to display the url like collegename.xyz.com

What are the request parameters i need to handle.

Thanks in advance. 

What steps will reproduce the problem?
1. set confReloadCheckInterval to 10 or even to 0
2. change urlrewrite.xml
3. nothing happens

What is the expected output? What do you see instead?

I will be redirected to the old target. I expect to see the new target.

What version of the product are you using? On what operating system?
3.04 
Windows
Tomcat 6.0.16
Java 1.6.05

Please provide any additional information below.

What steps will reproduce the problem?
1. write condition with session attribute check
2. open page which passes through urlrewrite filter but doesn't operate on
session i.e static html
3. observe that new session is created

What is the expected output? What do you see instead?

IMHO if session wasn't created earlier filter shouldn't create one. 

What version of the product are you using? On what operating system?

3.1.0

Please provide any additional information below.

On big systems with many unique users creating condition with session check
will lead to creation of multiple unnecessary session, which can result in
increased memory consumption etc.

Only change needed is replacing request.getSession with
request.getSession(false)

I wasn't sure where to post this, but it was difficult to find in the 
documentation. 

So, I had the need to redirect subdomains on a SaaS server. (ie, customers have 
myname.mysite.com ).  And If you have multiple subdomains, like mysite1.com and 
mysite2,com, 
you may have the situation like I did were your security certificate is only 
one one domain.  So, 
you would like to take all requests to:
http://myname.myUnsecureDomain.com => https://myname.mySecureDomain.com

This can be done with the following rule:
    <rule>
        <name>Redirect forum</name>
        <condition name="host" operator="equal">^(.*).myunsecuredomain.com$</condition>
        <from>^(.*)$</from>
        <to type="permanent-redirect">https://%1.mysecuredomain.com$1</to>
    </rule> 

I find that when I have an URL that contains the percent character in it
encoded as '%25', it throws an exception after a forward. The problem is
that the URL does not get encoded before the forward. Since the URL does
not get encoded again, the next time the URL is decoded, the now unencoded
'%' is seen as part of an encoded character and the system attempts to
decode it again, resulting in an error.

This is related to the other issue (#1) entered here where the problem
involved the encoding of the ampersand. 

I found a solution that is different then the one suggested in issue #1. I
tested it with both the '%' and '&' and it seems to fix both problems.

The approach I took is to encode the URL in NormalRewrittenRule just before
forward() is called. To do the encoding I used
org.apache.commons.httpclient.HttpURL. One can not just encode the Url
string, since then the '/' characters also get encoded. 

I would suggest adding a new configuration setting called 'escape' to
control if the Url should be escaped. In my code I tied it to the encode
configuration, but this will not work if the escaping behavior is needed
for redirects. It will also lead to further confusion around what encode
really does do.

Here is the diff of NormalRewrittenRule.java:


Index: src/java/org/tuckey/web/filters/urlrewrite/NormalRewrittenUrl.java
===================================================================
--- src/java/org/tuckey/web/filters/urlrewrite/NormalRewrittenUrl.java 
(revision 63)
+++ src/java/org/tuckey/web/filters/urlrewrite/NormalRewrittenUrl.java 
(working copy)
@@ -34,6 +34,7 @@
  */
 package org.tuckey.web.filters.urlrewrite;

+import org.apache.commons.httpclient.HttpURL;
 import org.tuckey.web.filters.urlrewrite.utils.Log;
 import org.tuckey.web.filters.urlrewrite.extend.RewriteMatch;

@@ -191,6 +192,10 @@
                 log.error("response is comitted cannot forward to " + target +
                         " (check you haven't done anything to the response
(ie, written to it) before here)");
             } else {
+                if (isEncode()) {
+                    HttpURL uri = new HttpURL(target);
+                    target = uri.getEscapedPath();
+                }
                 final RequestDispatcher rq =
getRequestDispatcher(hsRequest, target);
                 rq.forward(hsRequest, hsResponse);
                 if ( log.isTraceEnabled() ) log.trace("forwarded to " +
target);

Hi,

I'd like to externalize configuration file "urlrewrite.xml", i.e., instead
of storing it under current context as "WEB-INF/urlrewrite.xml", store it
anywhere using absolutely path or using different context class loader. Is
this possible? For example, by integration with JBoss, I'd like to store
the xml in JBoss "conf" directory.

Even better, if it can provide auto-loading the xml file upon changes...

Thanks,

fy

Hi,
I had a requirement to proxy an incoming url to a backend service that 
used http basic authentication using a service acocunt.  I made some 
modifications to the code to support that functionality.  I can now use a 
<to> url in the following format http://username:[email protected].  
I've included the modifications below in case you want to add it to your 
trunk:

class org.tuckey.web.filters.urlrewrite.RequestProxy

added import: org.apache.commons.codec.binary.Base64;
modified method setupProxyRequest:

    private static HttpMethod setupProxyRequest(final HttpServletRequest 
hsRequest, final URL targetUrl) throws IOException {
        final String methodName = hsRequest.getMethod();
        final HttpMethod method;
        if ("POST".equalsIgnoreCase(methodName)) {
            PostMethod postMethod = new PostMethod();
            InputStreamRequestEntity inputStreamRequestEntity = new 
InputStreamRequestEntity(hsRequest.getInputStream());
            postMethod.setRequestEntity(inputStreamRequestEntity);
            method = postMethod;
        } else if ("GET".equalsIgnoreCase(methodName)) {
            method = new GetMethod();
        } else {
            log.warn("Unsupported HTTP method requested: " + 
hsRequest.getMethod());
            return null;
        }

        method.setFollowRedirects(false);
        method.setPath(targetUrl.getPath());
        method.setQueryString(targetUrl.getQuery());

        Enumeration e = hsRequest.getHeaderNames();
        if (e != null) {
            while (e.hasMoreElements()) {
                String headerName = (String) e.nextElement();
                if ("host".equalsIgnoreCase(headerName)) {
                    //the host value is set by the http client
                    continue;
                } else if ("content-length".equalsIgnoreCase(headerName)) {
                    //the content-length is managed by the http client
                    continue;
                } else if ("accept-encoding".equalsIgnoreCase(headerName)) 
{
                    //the accepted encoding should only be those accepted 
by the http client.
                    //The response stream should (afaik) be deflated. If 
our http client does not support
                    //gzip then the response can not be unzipped and is 
delivered wrong.
                    continue;
                } else if (headerName.toLowerCase().startsWith("cookie")) {
                    //fixme : don't set any cookies in the proxied 
request, this needs a cleaner solution
                    continue;
                }

                Enumeration values = hsRequest.getHeaders(headerName);
                while (values.hasMoreElements()) {
                    String headerValue = (String) values.nextElement();
                    log.info("setting proxy request parameter:" + 
headerName + ", value: " + headerValue);
                    method.addRequestHeader(headerName, headerValue);
                }
            }
        }

        String authority = targetUrl.getAuthority();
        if (authority.indexOf('@') != -1) {
            authority = authority.substring(0, authority.indexOf('@'));
            String headerValue = "Basic " + new String
(Base64.encodeBase64(authority.getBytes()));
            log.info("setting proxy request 
parameter:Authorization, value: " + headerValue);
            method.addRequestHeader("Authorization", 
headerValue);
        }

        log.info("proxy query string " + method.getQueryString());
        return method;
    }

[deleted issue]

On startup of our app, I see urlrewrite (2.6) say

  org.tuckey.web.filters.urlrewrite.utils.Log ERROR: logLevelConf: WARN

Looking at the code (Log.java, line 565), this is not an error, just an
internal log message displaying the configured log level:

  String logLevelConf = filterConfig.getInitParameter("logLevel");
  localLog.error("logLevelConf: " + logLevelConf); 


I think the log level of this message should be DEBUG or INFO.

What steps will reproduce the problem?
1. Add a condition with empty/null pattern to a rule.
2. Execute the rule.
3. The rule does not give the expected result.

What is the expected output? What do you see instead?

Operator | Pattern | Value    | Exp Result | Actual Result |
EQUAL    | NULL    | NULL     | TRUE       | FALSE         |
EQUAL    | NULL    | NOT NULL | FALSE      | TRUE          |
NOT EQUAL| NULL    | NULL     | FALSE      | TRUE          |
NOT EQUAL| NULL    | NOT NULL | TRUE       | FALSE         |

What version of the product are you using? On what operating system?
v2.6
I checked it on the latest code as well.

Please provide any additional information below.

I added 4 test methods for the above conditions to the ConditionTest.java 
and attached with this defect. All 4 are failing now (testParameter1..4)

inside the handleRewrite function (around line 158) there appears to be an 
object instance variable (rewriteHandled) to prevent this function from 
repeating inappropriately.

Well, when I use urlrewrite on glassfish v3 preview, I am seeing this 
looping going crazy.

It turns out that once execution enters handleRewrite, that subsequent 
calls that end up coming back through this function on the next iteration 
see 'rewriteHandled' as being 'false' instead of 'true' that it gets set 
to on the earlier iteration.

This tells me that there must be some new instance of the object that's 
handling the next iteration or somehow the instance value is being reset.

In any case, I found that by adding an attribute to the request object 
itself, and, looking for that attribute having been set already, that this 
works effectively in preventing the endless nesting that was happening.

ie:

private void handleRewrite(ServletRequest request, ServletResponse 
response) throws ServletException, IOException {

        boolean bRewriteHandled = (request.getAttribute("rewriteHandled")
==null ? false : true);

        if (bRewriteHandled)
        {
            //request.removeAttribute("rewriteHandled");
            return;
        }
        request.setAttribute("rewriteHandled", "true");
        //rewriteHandled = true;
        // wrap the request if necessary to allow overriding of request 
parameters and method
        if ( response instanceof UrlRewriteWrappedResponse && request 
instanceof HttpServletRequest) {
            HashMap overiddenRequestParameters = 
((UrlRewriteWrappedResponse) response).getOverridenRequestParameters();
            String overiddenMethod = ((UrlRewriteWrappedResponse) 
response).getOverridenMethod();
            if ( overiddenRequestParameters != null || overiddenMethod != 
null) {
                request = new UrlRewriteWrappedRequest
((HttpServletRequest) request, overiddenRequestParameters, 
overiddenMethod);
            }
        }
        if (finalRewrittenRequest != null) {
            responseHandled = true;
            requestRewritten = finalRewrittenRequest.doRewrite
((HttpServletRequest) request,
                    (HttpServletResponse) response, parentChain);
        }
        if (! requestRewritten) {
            responseHandled = true;
            parentChain.doFilter(request, response);
        }
    }

While the interface Rule is public the class RuleChain that is used in that
interface is not public it is package local

urlrewritefilter fails to properly handle encoded URLs such as
http://foo/plus+slash%2fsemicolon%3bquestionmark%3f?first=plus+plus

This is due to several common misconceptions. The previous URL once decoded
is http://foo/plus+slash/semicolon;questionmark??first=plus+plus which is
impossible to reencode correctly since we have just lost the precious
information that "plus+slash/semicolon;questionmark?" used to be a single
path segment, and not several, including one with a path parameter and an
invalid query string.

The first real error lies in using either java.net.URLDecoder or
commons-codec to decode URLs, since "+" in a path segment is a valid
character which should not be decoded to a space, as should be in the query
part. I've included URLEncoder and URLDecoder classes in the patch that
perform valid escaping based on where in the URL we are doing the
encoding/decoding.

The second obstacle is that there should be both ${escape:...} (assuming we
keep it for query parts) and ${escapePath:...} functions available for
substitution, since we may need to be able to decode from a path segment
and encode to a query part (and reverse):

<from>/(.*)?foo=(.*)</from>
<to>/foo/${encodePath:$2}?query=${encode:$1}</to>

I've added these functions (and decode) to my patch.

Actually we also may need <from decode="false">...</from> in many cases,
but I haven't made that change in my patch. We want it only for some rules,
as opposed to all rules as is currently the case.

The last thing my patch does is fix <to> substitution. Because this is not
evaluated as a real language with a lexer/parser there are many errors. For
example it is currently possible to have the following happen:

Suppose you have a variable FOO set to "$1" and the URL being matched "/bar":
<from>/(.*)</from>
<to>/url/%{FOO}</to>
will be substituted first to "/url/$1" then "/url/bar" due to sequential
substitution.

My patch introduces a poor-man's evaluation/substitution technique in the
form of a chain of substitution filters similar to servlet filters, which
means that the output of (backreferences, previous back-references,
variables and functions) will not be substituted again. Also it enables
recursive function evaluation such as "${escape:${unescapePath:$1}}" which
was not previously working.

The tests have been updated and all run except one weird test which I
suspect is not applicable any more.

The only thing I did not properly fix is
"${replace:${replace:foo:bar}:gee}" because the regexp which finds the
semicolons is wrong and will find the first one even though it belongs to
an inner function. If there is a way to write a regexp that matches a
semicolon which isn't withing "${}" then I could fix it, but my expertise
stops there.

This patch applies to 3.2.0 and fixes all URL issues we had with
urlrewritefilter for us. Do not hesitate to contact me for more info.

Thanks for this great product.

What steps will reproduce the problem?
In the code I try to set a cookie by calling addCookie() on the
HttpServletResponse. The configuration:

web.xml:
...
<filter>
    <filter-name>UrlRewriteFilter</filter-name>
    <filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class>
</filter>
<filter-mapping>
    <filter-name>UrlRewriteFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>
...

urlrewrite.xml:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE urlrewrite PUBLIC "-//tuckey.org//DTD UrlRewrite 2.6//EN"
        "http://tuckey.org/res/dtds/urlrewrite2.6.dtd">
<urlrewrite>
    <rule>
        <note></note>
        <from>^/project/([\w\-\.]+)/([\w\-\.]+/)*([\w\-\.]+)\?*(\S*)$</from>
        <to>/$2$3?project=$1&amp;$4</to>
    </rule>

    <outbound-rule>
        <note></note>
        <from>^/([\w\-\.]+)\?project=([\w\-\.]+)&amp;*(.*)$</from>
        <to>/project/$2/$1?$3</to>
    </outbound-rule>
</urlrewrite>

What is the expected output? What do you see instead?
I should see the cookie in the HTTP header from the server but I do not. If
I disable urlrewrite by commenting that portion out in web.xml the cookie
gets sent out to the browser as it should.

What version of the product are you using? On what operating system?
I use 2.6.0 and running on tomcat 6.0.18 in an linux environment

Please provide any additional information below.

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?

protected loadUrlRewrite() can be overridden, but the base class calls private 
checkConf() which 
is the only method that sets the private urlRewriter variable and so there's no 
way to truly 
overload the load.

Essentially, I'd like urlrewrite to load a configuration file from anywhere on 
the file system and 
not just inside the servlet context.


What version of the product are you using? On what operating system?

3.1 on RHEL4

Please provide any additional information below.

The "doFilter()" method contains the following lines at the end:

    // if no rewrite has taken place continue as normal
    if (!requestRewritten) {
            chain.doFilter(hsRequest, urlRewriteWrappedResponse);
    }

They break the normal filter pipeline. It causes the unneccessary 
limitation - UrlRewriteFilter must be the last filter at the filtering 
pipeline. This kind of limitations seems superfluous.

I think it will be better to allow filters configured after 
UrlRewriteFiletr to be called.

I am using the tuckey urlrewriter 3.1.0 and I set up the following rule.

<rule match-type="wildcard">
  <from>/nl/**</from>
  <to type="permanent-redirect">/$1</to>
</rule>

I would simply like to strip away the 'nl' part of my url and leave the
rest, but if slashes are present, with $1 only the first piece is
retrieved. As a result if I consider the http request coming in
nl/blabla1/blabla2?param=3 this will be translated in blabla1

Is this the expected behavior? What shall I do in order to retrieve the
part of the url following the nl/ ?

Thank you very much.

We mainly use SLF4J (http://www.slf4j.org) for our logging.
Here is a patch that enables a "slf4j" as the filter "logLevel" parameter.

Also, note that recent versions of Log4J have a trace level. You may want
to change your Log4J usage in Log.java (not included in this patch).

urlrewritefilter does not work in websphere 6.1, but work well in 
websphere 6.0.2.x

REQUEST_URI based rewrite conditions are not supported yet in the apache
style configuration. This should be supported.

Supporting REQUEST_FILENAME might not be a bad idea either. This represents
the full local filesystem path to the file or script matching the request.
On the LAMP stack of applications, this is a typical way of rewriting when
the condition is evaluated to be either a file name or a directory name. 

For the Xml style configuration, this can supported as
<rule>
<condition name="request-filename">some-javascript-file.js</condition>
<from>/js/(*).js</from>
<to>/servlet/my-file-servlet-and-access-logger.jsp?file=$1</to>
</rule>

For the Apache style configuration, this can be supported as
RewriteCond %{REQUEST_FILENAME} some-javascript-file.js
RewriteRule /js/(*).js /servlet/my-file-servlet-and-access-logger.jsp?file=$1

Flags "-f" (is file) and "-d" (is directory) can be optionally supported.

Currently (as of 3.2.0), the urlrewrite.xml file has to be in a path
relative to the application's context root (which can be set via the
confPath parameter).  If the application is in a packaged WAR or EAR, and
the confReloadCheckInterval value is set to anything other than -1, a null
pointer exception will occur the first time the application is accessed
after a deployment since the urlrewrite.xml file cannot be found (as it's
inside the WAR/EAR).

I propose a modification to allow the confPath initialization parameter to
be a location on the application's classpath as well as relative to the
context root, which would allow us to make urlrewrite.xml external to the
application.  Perhaps another initialization parameter could be added to
specify if the classpath is searched or not (defaulting to false to not
break any existing applications).

As soon as I have time I will attempt a checkout and modification of the
source with this change and will post back my results.

Note that this is occurring on Weblogic 9.2 SP3.

When setting a new request parameter with set element to the request and
later fetching the parameter map by request.getParameterMap() the value is
a String, not String[]. The interface ServletRequest says "The values in
the parameter map are of type String array.".

Rule like:
    <rule>
        <from>^/directory/(.*)$</from>
        <set type="parameter" name="file">$1</set>
        <to last="true">/dir2/index.action</to>
    </rule>

Version 3.2.0, os x.
Thanks!

What steps will reproduce the problem?
1. Adding the filter information to the server's web.xml file
2. Copying the provided jar file to the server's library
3. Defining a new rule to redirect all incoming traffic to another address
(e.g. http://www.google.com)
        <rule>
        <from>(.*)</from>
        <to type="redirect">http://www.google.de</to>
        </rule>

What is the expected output? What do you see instead?
Every request to the server should be redirected to Google, instead the
normal pages are shown.


What version of the product are you using? On what operating system?
Version 2.6 on a Windows 2000 machine.

Please provide any additional information below.
Is it actually possible to set the rules server-wide? In the documentation
I only found references how to use it in seperate contexts.

Hi Paul, hi all,

I created a patch for URLRewriteFilter 3.1, with which it is possible to
have cross-context forwards on a web application. For instance, it will be
possible to define rules such as:
app.mycompany.com   => www.mycompany.com/app
forum.mycompany.com => www.mycompany.com/forum
etc.

(see google groups thread http://tinyurl.com/5l7zk5).

The condition to enable cross-context forwards is that the application
server supports this. 

On Tomcat, for instance, we have to define the application contexts in the
server configuration (server.xml or context.xml) with the option
crossContext="true".

For instance, the two applications mentioned before ("app" and "forum")
have to be defined as:
<Context docBase="app" path="/app" reloadable="true" crossContext="true"/>
<Context docBase="forum" path="/forum" reloadable="true" crossContext="true"/>

To enable cross-context forwarding, I added the attribute "toContextPath"
to the rule definition. This attribute is optional.

The rule for forwarding the address forum.mycompany.com to
www.mycompany.com/forum will be:

<rule>
  <name>Redirect forum</name>
  <condition name="host" operator="equal">^forum.mycompany.com$</condition>
  <from>^(.*)$</from>
  <to type="forward">$1</to>
  <toContextPath>forum</toContextPath>
</rule> 

I would like this add-on to be included in the software, so that it could
be accessible to the user community of URLRewriteFilter.

Please comment and give me feedback.

Thank you very much in advance,

Paul P

What steps will reproduce the problem?
1. make urlrewrite rule in my project
2. in my project cookies can't read whole.
3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?
 i use the version of 3.0

Please provide any additional information below.
my project running on windows ,at the local file of client it makes many
other folder .
my rule like this:
<outbound-rule>

<from>^/productDetail.do\?method=displaydetail&amp;tsql=(.*)&amp;productid=(\w+)
$</from>
        <to>/productDetail/displaydetail/$1/$2.html</to>
</outbound-rule>
 it makes cookie folder'name :displaydetail/

What steps will reproduce the problem?
1. mvn clean package

Does not compile cleanly. However ant build.xml works fine.

I modified the pom.xml to include necessary dependencies to make it compile
properly. I couldn't find where Groovy was being used (it compiles fine
without Groovy) but I added it anyways because the ant build seemed to used
it. I've attached the changed pom.xml

However tests are still broken, it seems that the testResourceDirectory is
not working as it should.

What steps will reproduce the problem?
1. Use <run class="MyClass" method="myMethod" /> in a rule
2. The output works correctly
3. There are IllegalStateExceptions in the log

What is the expected output? What do you see instead?
The output is correct, however there are errors in the log for each request
which executes the run-class.

What version of the product are you using? On what operating system?
Latest trunk, tomcat6, ubuntu-server 8.04.

The exception happens because after running a class a filterChain.doFilter
should not be called because the processing is already done and response
has been written out. This leads to an IllegalStateException.

Please provide any additional information below.
The following exception is seen in the logs for each such request:

SEVERE: Servlet.service() for servlet default threw exception
java.lang.IllegalStateException
 at
org.apache.catalina.connector.ResponseFacade.sendError(ResponseFacade.java:405)
 at
javax.servlet.http.HttpServletResponseWrapper.sendError(HttpServletResponseWrapp
er.java:108)
 at
org.apache.catalina.servlets.DefaultServlet.serveResource(DefaultServlet.java:72
7)
 at org.apache.catalina.servlets.DefaultServlet.doGet(DefaultServlet.java:376)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
 at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilt
erChain.java:269)
 at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.
java:188)
 at
org.tuckey.web.filters.urlrewrite.RuleChain.handleRewrite(RuleChain.java:164)
 at org.tuckey.web.filters.urlrewrite.RuleChain.doRules(RuleChain.java:141)
 at
org.tuckey.web.filters.urlrewrite.UrlRewriter.processRequest(UrlRewriter.java:90
)
 at
org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter(UrlRewriteFilter.jav
a:406)
 at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilt
erChain.java:215)
 at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.
java:188)
 at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:2
13)
 at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:1
74)
 at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
 at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
 at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108
)
 at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
 at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:874)
 at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConne
ction(Http11BaseProtocol.java:665)
 at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:52
8)
 at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorker
Thread.java:81)
 at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:68
9)
 at java.lang.Thread.run(Thread.java:595)

matcher.find() should NOT be used as it is NOT the same as
matcher.matches() which I think is more logical for evaluating whether to
matches the web url or not.  ie. I spent hours on why URLRewriter was
matching a URL it should not be matching.  anyways, here is the code for a
sample where matches returns false and find returns true....(I am basicaly
screwed right now and this code returns a match in URLRewriter when I don't
want it too!!!!!

        String pat = "^/([a-zA-Z]*)(\\?.*)?";
        Pattern pattern1 =  Pattern.compile(pat, Pattern.CASE_INSENSITIVE);

        String url = "/web/home.xhtml";
        Matcher matcher = pattern1.matcher(url);

        boolean matches = matcher.matches();

        matcher.reset();

        //if not found return..
        boolean wasFound = matcher.find();

find can find multiple matches in a string and the ^ and $ mean start and
end of the match not of the string, whereas if matches is used, the string
being evaluated has to evaulate to starting at the match...oh this is hard
to explain...here is a rough example

  aabbaabbaa

^aa$  will find 3 matches in the above string.  find returns true
BUT
^aa$ will not MATCH the above string....find returns true, matches returns
false.

so why is URLRewriter using finds...it seems more restrictive as I can't
define my match like I want to.

Using an explicitly configured config file path with init param 'confPath'
UrlRewriteFilter will never reload changed configuration because it does
not check the file at that path.

    private long getConfFileLastModified() {
        File confFile = new File(context.getRealPath(DEFAULT_WEB_CONF_PATH));
        return confFile.lastModified();
    }

should be

    private long getConfFileLastModified() {
        File confFile = new File(context.getRealPath(confPath));
        return confFile.lastModified();
    }

File : UrlRewriteFilter.java
Currently the debug configuration are set in the init block lines

167.        // set the conf of the logger to make sure we get the messages
in context log
168.        Log.setConfiguration(filterConfig);


Due to this logs from line 152-166 are not logged

Can this config initiation be moved to start of the init block?

the junit dependency in pom.xml is declared with scope compile. 
Is junit really needed to compile this project?

I've got error when connecting to:
http://127.0.0.1:8080/myContext/rewrite-status/

java.lang.NullPointerException
org.tuckey.web.filters.urlrewrite.Status.showHeader(Status.java:304)
org.tuckey.web.filters.urlrewrite.Status.displayStatusInContainer(Status.java:76
)
org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.showStatus(UrlRewriteFilter.j
ava:445)
org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter(UrlRewriteFilter.jav
a:397)


I'm using latest urlrewritefilter-3.0.4


Thanks for help,
Artur