rewritevalve

[Jake Orel]

Hi all, My name is Jake. I'm a newbie to tomcat and I'm working on setting
up the rewrite valve. I've configured it host specific rather than global.
I have put my rewrite.config file inside of my Catalina base for the host
name and I know I'm reading the file at the very least because if i fill it
with gunk it crashes tomcat. my first rule is just trying to rewrite from
an empty forward slash: "RewriteRule ^/$ /path/to/jsp"  (quoted for email
purposes) If I enter the jsp
path in the browser it will take me there but I'm not getting my rewrite if
i just leave the /. Any help would be appreciated and thank you in advance!
- Jake Orel

Re: RewriteValve does not work on HTTPS

[Hua Zhang]

Thank you for the information and fix, Mark.

On Fri, Feb 7, 2020 at 12:31 AM Mark Thomas  wrote:

> On 06/02/2020 23:00, Mark Thomas wrote:
> > The issue appears to be that the following RewriteCond does not match
> > when the request is served over HTTP/2 (with TLS) but it does if the
> > request is served over HTTP/1.1 with TLS.
> >
> > RewriteCond %{HTTP_HOST} localhost
> >
> > (Note the RewriteCond quoted at the start of this thread is invalid)
> >
> > I'm wondering if this is related to the thread about
> > HttpServletRequest.getRemoteAddr() returning null at the start of a
> > request. It looks as if the request information may be being populated
> > too late.
>
> Nope. Unrelated.
>
> The root cause here is that the RewriteCond is looking for an HTTP Host
> header but HTTP/2 does not have any such header.
>
> HTTP/2 has the pseudo-header ":authority" that replaces the Host header.
> While you could argue that a strict interpretation of the mod_rewrite
> docs (since the rewrite valve aims to emulate a sub-set of mod_rewrite
> behaviour) means that "host" != ":authority" I think the reasonable
> thing to do in this instance is to look at the ":authority" value if the
> request is using HTTP/2. I'll work on a patch.
>
> Mark
>
>

Re: RewriteValve does not work on HTTPS

[Mark Thomas]

On 06/02/2020 23:00, Mark Thomas wrote:
> The issue appears to be that the following RewriteCond does not match
> when the request is served over HTTP/2 (with TLS) but it does if the
> request is served over HTTP/1.1 with TLS.
> 
> RewriteCond %{HTTP_HOST} localhost
> 
> (Note the RewriteCond quoted at the start of this thread is invalid)
> 
> I'm wondering if this is related to the thread about
> HttpServletRequest.getRemoteAddr() returning null at the start of a
> request. It looks as if the request information may be being populated
> too late.

Nope. Unrelated.

The root cause here is that the RewriteCond is looking for an HTTP Host
header but HTTP/2 does not have any such header.

HTTP/2 has the pseudo-header ":authority" that replaces the Host header.
While you could argue that a strict interpretation of the mod_rewrite
docs (since the rewrite valve aims to emulate a sub-set of mod_rewrite
behaviour) means that "host" != ":authority" I think the reasonable
thing to do in this instance is to look at the ":authority" value if the
request is using HTTP/2. I'll work on a patch.

Mark


> 
> Mark
> 
> 
> 
> On 06/02/2020 20:42, Pierre Chiu wrote:
>> I just want to concur I have the same issue.
>> Removing that one line upgradeprotocol
>> and rewrite works again.
>>
>>
>>
>> On Thu, Feb 6, 2020 at 3:28 PM Hua Zhang  wrote:
>>
>>> Nope, I also tested it with NIO instead of APR, same issues happen.
>>> RewriteValve does not function as expected. Besides it, there are also two
>>> https-443-exec executed by one request.
>>>
>>> There is definitely something wrong with Http2Protocol. And it results in
>>> this case a problem in RewriteValve.
>>>
>>> And what kind of extra information do you want to have. I cannot send any
>>> pictures in the email. You want the server.xml configuration? Except that
>>> file, almost every other configuration file is untouched. No load balancer,
>>> no any proxy here. Just a straight forward connection to tomcat instance.
>>>
>>> Here an remark, you can only reproduce errors if Http2Protocol is indeed
>>> activated, namely you see in browser h2 protocol is used by request. In
>>> Eclipse, I cannot reproduce the issue, since I cannot get h2 protocol
>>> working there.
>>>
>>>
>>> Hua
>>>
>>> Rémy Maucherat  于 2020年2月6日周四 下午3:06写道：
>>>
>>>> On Thu, Feb 6, 2020 at 2:56 PM Hua Zhang  wrote:
>>>>
>>>>> Thank you for the response. I am finally able to confirm the issue.
>>>>>
>>>>> When I put the following line in comment, everything works fine. I mean
>>>> as
>>>>> expected.
>>>>>
>>>>> **
>>>>>
>>>>>
>>>>> If the above line UpgradeProtocol is activated, I observe now at least
>>>> two
>>>>> weird situations.
>>>>>
>>>>> 1) As mentioned before, RewriteValve does not work as expected.
>>>>> 2) Besides it, I observed that serviet behaviors weird. According to
>>> the
>>>>> log file it seems that a servlet is sometimes called *twice by one
>>>>> request*.
>>>>>
>>>>> This is a snapshot of my log files. You can see that two https-443-exec
>>>> are
>>>>> called almost at the same time.
>>>>>
>>>>> 06-Feb-2020 13:38:04.676 SEVERE *[https-openssl-apr-443-exec-9]*
>>>>> org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service()
>>>>> for servlet [uploadServlet] in context with path [] threw exception
>>>>>
>>>>> org.apache.commons.fileupload.MultipartStream$MalformedStreamException:
>>>>> Stream ended unexpectedly
>>>>> 06-Feb-2020 13:38:04.999 SEVERE *[https-openssl-apr-443-exec-2]*
>>>>> org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service()
>>>>> for servlet [uploadServlet] in context with path [] threw exception
>>>>>
>>>>> org.apache.commons.fileupload.MultipartStream$MalformedStreamException:
>>>>> Stream ended unexpectedly
>>>>>
>>>>
>>>> Ok, so your problem seems to be about HTTP/2 rather than the rewrite
>>> valve:
>>>> HTTP/2 is usually not used without TLS and ALPN. You should continue to
>>>> post more details. Something you can try is use the NIO connector (with
>>>> OpenSSL or JSSE) rather than APR, it would be a more common
>>> configuration.
>>>>
>>>> Rémy
>>>>
>>>>>
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Hua
>>>>
>>>
>>
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: RewriteValve does not work on HTTPS

[Mark Thomas]

The issue appears to be that the following RewriteCond does not match
when the request is served over HTTP/2 (with TLS) but it does if the
request is served over HTTP/1.1 with TLS.

RewriteCond %{HTTP_HOST} localhost

(Note the RewriteCond quoted at the start of this thread is invalid)

I'm wondering if this is related to the thread about
HttpServletRequest.getRemoteAddr() returning null at the start of a
request. It looks as if the request information may be being populated
too late.

Mark



On 06/02/2020 20:42, Pierre Chiu wrote:
> I just want to concur I have the same issue.
> Removing that one line upgradeprotocol
> and rewrite works again.
> 
> 
> 
> On Thu, Feb 6, 2020 at 3:28 PM Hua Zhang  wrote:
> 
>> Nope, I also tested it with NIO instead of APR, same issues happen.
>> RewriteValve does not function as expected. Besides it, there are also two
>> https-443-exec executed by one request.
>>
>> There is definitely something wrong with Http2Protocol. And it results in
>> this case a problem in RewriteValve.
>>
>> And what kind of extra information do you want to have. I cannot send any
>> pictures in the email. You want the server.xml configuration? Except that
>> file, almost every other configuration file is untouched. No load balancer,
>> no any proxy here. Just a straight forward connection to tomcat instance.
>>
>> Here an remark, you can only reproduce errors if Http2Protocol is indeed
>> activated, namely you see in browser h2 protocol is used by request. In
>> Eclipse, I cannot reproduce the issue, since I cannot get h2 protocol
>> working there.
>>
>>
>> Hua
>>
>> Rémy Maucherat  于 2020年2月6日周四 下午3:06写道：
>>
>>> On Thu, Feb 6, 2020 at 2:56 PM Hua Zhang  wrote:
>>>
>>>> Thank you for the response. I am finally able to confirm the issue.
>>>>
>>>> When I put the following line in comment, everything works fine. I mean
>>> as
>>>> expected.
>>>>
>>>> **
>>>>
>>>>
>>>> If the above line UpgradeProtocol is activated, I observe now at least
>>> two
>>>> weird situations.
>>>>
>>>> 1) As mentioned before, RewriteValve does not work as expected.
>>>> 2) Besides it, I observed that serviet behaviors weird. According to
>> the
>>>> log file it seems that a servlet is sometimes called *twice by one
>>>> request*.
>>>>
>>>> This is a snapshot of my log files. You can see that two https-443-exec
>>> are
>>>> called almost at the same time.
>>>>
>>>> 06-Feb-2020 13:38:04.676 SEVERE *[https-openssl-apr-443-exec-9]*
>>>> org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service()
>>>> for servlet [uploadServlet] in context with path [] threw exception
>>>>
>>>> org.apache.commons.fileupload.MultipartStream$MalformedStreamException:
>>>> Stream ended unexpectedly
>>>> 06-Feb-2020 13:38:04.999 SEVERE *[https-openssl-apr-443-exec-2]*
>>>> org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service()
>>>> for servlet [uploadServlet] in context with path [] threw exception
>>>>
>>>> org.apache.commons.fileupload.MultipartStream$MalformedStreamException:
>>>> Stream ended unexpectedly
>>>>
>>>
>>> Ok, so your problem seems to be about HTTP/2 rather than the rewrite
>> valve:
>>> HTTP/2 is usually not used without TLS and ALPN. You should continue to
>>> post more details. Something you can try is use the NIO connector (with
>>> OpenSSL or JSSE) rather than APR, it would be a more common
>> configuration.
>>>
>>> Rémy
>>>
>>>>
>>>>
>>>> Best regards,
>>>>
>>>> Hua
>>>
>>
> 


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: RewriteValve does not work on HTTPS

[Pierre Chiu]

I just want to concur I have the same issue.
Removing that one line upgradeprotocol
and rewrite works again.



On Thu, Feb 6, 2020 at 3:28 PM Hua Zhang  wrote:

> Nope, I also tested it with NIO instead of APR, same issues happen.
> RewriteValve does not function as expected. Besides it, there are also two
> https-443-exec executed by one request.
>
> There is definitely something wrong with Http2Protocol. And it results in
> this case a problem in RewriteValve.
>
> And what kind of extra information do you want to have. I cannot send any
> pictures in the email. You want the server.xml configuration? Except that
> file, almost every other configuration file is untouched. No load balancer,
> no any proxy here. Just a straight forward connection to tomcat instance.
>
> Here an remark, you can only reproduce errors if Http2Protocol is indeed
> activated, namely you see in browser h2 protocol is used by request. In
> Eclipse, I cannot reproduce the issue, since I cannot get h2 protocol
> working there.
>
>
> Hua
>
> Rémy Maucherat  于 2020年2月6日周四 下午3:06写道：
>
> > On Thu, Feb 6, 2020 at 2:56 PM Hua Zhang  wrote:
> >
> > > Thank you for the response. I am finally able to confirm the issue.
> > >
> > > When I put the following line in comment, everything works fine. I mean
> > as
> > > expected.
> > >
> > > **
> > >
> > >
> > > If the above line UpgradeProtocol is activated, I observe now at least
> > two
> > > weird situations.
> > >
> > > 1) As mentioned before, RewriteValve does not work as expected.
> > > 2) Besides it, I observed that serviet behaviors weird. According to
> the
> > > log file it seems that a servlet is sometimes called *twice by one
> > > request*.
> > >
> > > This is a snapshot of my log files. You can see that two https-443-exec
> > are
> > > called almost at the same time.
> > >
> > > 06-Feb-2020 13:38:04.676 SEVERE *[https-openssl-apr-443-exec-9]*
> > > org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service()
> > > for servlet [uploadServlet] in context with path [] threw exception
> > >
> > > org.apache.commons.fileupload.MultipartStream$MalformedStreamException:
> > > Stream ended unexpectedly
> > > 06-Feb-2020 13:38:04.999 SEVERE *[https-openssl-apr-443-exec-2]*
> > > org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service()
> > > for servlet [uploadServlet] in context with path [] threw exception
> > >
> > > org.apache.commons.fileupload.MultipartStream$MalformedStreamException:
> > > Stream ended unexpectedly
> > >
> >
> > Ok, so your problem seems to be about HTTP/2 rather than the rewrite
> valve:
> > HTTP/2 is usually not used without TLS and ALPN. You should continue to
> > post more details. Something you can try is use the NIO connector (with
> > OpenSSL or JSSE) rather than APR, it would be a more common
> configuration.
> >
> > Rémy
> >
> > >
> > >
> > > Best regards,
> > >
> > > Hua
> >
>

Re: RewriteValve does not work on HTTPS

[Hua Zhang]

Nope, I also tested it with NIO instead of APR, same issues happen.
RewriteValve does not function as expected. Besides it, there are also two
https-443-exec executed by one request.

There is definitely something wrong with Http2Protocol. And it results in
this case a problem in RewriteValve.

And what kind of extra information do you want to have. I cannot send any
pictures in the email. You want the server.xml configuration? Except that
file, almost every other configuration file is untouched. No load balancer,
no any proxy here. Just a straight forward connection to tomcat instance.

Here an remark, you can only reproduce errors if Http2Protocol is indeed
activated, namely you see in browser h2 protocol is used by request. In
Eclipse, I cannot reproduce the issue, since I cannot get h2 protocol
working there.


Hua

Rémy Maucherat  于 2020年2月6日周四 下午3:06写道：

> On Thu, Feb 6, 2020 at 2:56 PM Hua Zhang  wrote:
>
> > Thank you for the response. I am finally able to confirm the issue.
> >
> > When I put the following line in comment, everything works fine. I mean
> as
> > expected.
> >
> > **
> >
> >
> > If the above line UpgradeProtocol is activated, I observe now at least
> two
> > weird situations.
> >
> > 1) As mentioned before, RewriteValve does not work as expected.
> > 2) Besides it, I observed that serviet behaviors weird. According to the
> > log file it seems that a servlet is sometimes called *twice by one
> > request*.
> >
> > This is a snapshot of my log files. You can see that two https-443-exec
> are
> > called almost at the same time.
> >
> > 06-Feb-2020 13:38:04.676 SEVERE *[https-openssl-apr-443-exec-9]*
> > org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service()
> > for servlet [uploadServlet] in context with path [] threw exception
> >
> > org.apache.commons.fileupload.MultipartStream$MalformedStreamException:
> > Stream ended unexpectedly
> > 06-Feb-2020 13:38:04.999 SEVERE *[https-openssl-apr-443-exec-2]*
> > org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service()
> > for servlet [uploadServlet] in context with path [] threw exception
> >
> > org.apache.commons.fileupload.MultipartStream$MalformedStreamException:
> > Stream ended unexpectedly
> >
>
> Ok, so your problem seems to be about HTTP/2 rather than the rewrite valve:
> HTTP/2 is usually not used without TLS and ALPN. You should continue to
> post more details. Something you can try is use the NIO connector (with
> OpenSSL or JSSE) rather than APR, it would be a more common configuration.
>
> Rémy
>
> >
> >
> > Best regards,
> >
> > Hua
>

Re: RewriteValve does not work on HTTPS

[Rémy Maucherat]

On Thu, Feb 6, 2020 at 2:56 PM Hua Zhang  wrote:

> Thank you for the response. I am finally able to confirm the issue.
>
> When I put the following line in comment, everything works fine. I mean as
> expected.
>
> **
>
>
> If the above line UpgradeProtocol is activated, I observe now at least two
> weird situations.
>
> 1) As mentioned before, RewriteValve does not work as expected.
> 2) Besides it, I observed that serviet behaviors weird. According to the
> log file it seems that a servlet is sometimes called *twice by one
> request*.
>
> This is a snapshot of my log files. You can see that two https-443-exec are
> called almost at the same time.
>
> 06-Feb-2020 13:38:04.676 SEVERE *[https-openssl-apr-443-exec-9]*
> org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service()
> for servlet [uploadServlet] in context with path [] threw exception
>
> org.apache.commons.fileupload.MultipartStream$MalformedStreamException:
> Stream ended unexpectedly
> 06-Feb-2020 13:38:04.999 SEVERE *[https-openssl-apr-443-exec-2]*
> org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service()
> for servlet [uploadServlet] in context with path [] threw exception
>
> org.apache.commons.fileupload.MultipartStream$MalformedStreamException:
> Stream ended unexpectedly
>

Ok, so your problem seems to be about HTTP/2 rather than the rewrite valve:
HTTP/2 is usually not used without TLS and ALPN. You should continue to
post more details. Something you can try is use the NIO connector (with
OpenSSL or JSSE) rather than APR, it would be a more common configuration.

Rémy

>
>
> Best regards,
>
> Hua
>
>
> On Wed, Feb 5, 2020 at 2:15 PM Felix Schumacher <
> felix.schumac...@internetallee.de> wrote:
>
> > Am 04.02.2020 22:16, schrieb Hua Zhang:
> > > What I mean with word 'works' is: the RewriteRule has been executed.
> > >
> > > That is not the case by HTTPS. The rule has not been executed while the
> > > RewriteCond is fulfilled.
> >
> > Can you give us more information on your setup? Is there any
> > Proxy/Loadbalancer in front of your tomcat? If so, can you show us
> > details on that setup?
> > What is the value of the host request header in both cases?
> >
> > Felix
> > >
> > > Olaf Kock  于 2020年2月4日周二 下午9:06写道：
> > >
> > >>
> > >> On 04.02.20 20:31, Hua Zhang wrote:
> > >> > Best tomcat team,
> > >> >
> > >> > Hereby I have a question about an issue I found by using
> RewriteValve
> > >> > on tomcat 9.30
> > >> >
> > >> > The rewrite.config is very simple:
> > >> >
> > >> > /RewriteCond %{HTTP_HOST} =youkoop.com <http://youkoop.com>
> > >> > RewriteRule ^.*$ https://www.youkoop.com [R=301,L]
> > >> > /
> > >> >
> > >> > All I want is just redirect a naked root domain to a www domain with
> > >> > HTTPS.
> > >> >
> > >> > The redirection works on HTTP but not HTTPS.
> > >> >
> > >> > http://youkoop.com => https://www.youkoop.com *works*
> > >> >
> > >> Note: Images don't get through in this mailing list. I can imagine
> > >> what
> > >> "works" means, but for your next example: Please elaborate what "does
> > >> not work" means.
> > >> >
> > >> > *https*://youkoop.com <http://youkoop.com> =>
> > >> > https://www.youkoop.com *does not work*
> > >>
> > >> First thing to test: Does https://youkoop.com work without the
> > >> redirect,
> > >> then with the "wrong" host name? Otherwise it might be as simple as a
> > >> misconfigured TLS host that's never invoked because of a certificate
> > >> mismatch.
> > >>
> > >> Olaf
> > >>
> > >>
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >
>

Re: RewriteValve does not work on HTTPS

[Hua Zhang]

Thank you for the response. I am finally able to confirm the issue.

When I put the following line in comment, everything works fine. I mean as
expected.

**


If the above line UpgradeProtocol is activated, I observe now at least two
weird situations.

1) As mentioned before, RewriteValve does not work as expected.
2) Besides it, I observed that serviet behaviors weird. According to the
log file it seems that a servlet is sometimes called *twice by one request*.

This is a snapshot of my log files. You can see that two https-443-exec are
called almost at the same time.

06-Feb-2020 13:38:04.676 SEVERE *[https-openssl-apr-443-exec-9]*
org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service()
for servlet [uploadServlet] in context with path [] threw exception
org.apache.commons.fileupload.MultipartStream$MalformedStreamException:
Stream ended unexpectedly
06-Feb-2020 13:38:04.999 SEVERE *[https-openssl-apr-443-exec-2]*
org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service()
for servlet [uploadServlet] in context with path [] threw exception
org.apache.commons.fileupload.MultipartStream$MalformedStreamException:
Stream ended unexpectedly


Best regards,

Hua


On Wed, Feb 5, 2020 at 2:15 PM Felix Schumacher <
felix.schumac...@internetallee.de> wrote:

> Am 04.02.2020 22:16, schrieb Hua Zhang:
> > What I mean with word 'works' is: the RewriteRule has been executed.
> >
> > That is not the case by HTTPS. The rule has not been executed while the
> > RewriteCond is fulfilled.
>
> Can you give us more information on your setup? Is there any
> Proxy/Loadbalancer in front of your tomcat? If so, can you show us
> details on that setup?
> What is the value of the host request header in both cases?
>
> Felix
> >
> > Olaf Kock  于 2020年2月4日周二 下午9:06写道：
> >
> >>
> >> On 04.02.20 20:31, Hua Zhang wrote:
> >> > Best tomcat team,
> >> >
> >> > Hereby I have a question about an issue I found by using RewriteValve
> >> > on tomcat 9.30
> >> >
> >> > The rewrite.config is very simple:
> >> >
> >> > /RewriteCond %{HTTP_HOST} =youkoop.com <http://youkoop.com>
> >> > RewriteRule ^.*$ https://www.youkoop.com [R=301,L]
> >> > /
> >> >
> >> > All I want is just redirect a naked root domain to a www domain with
> >> > HTTPS.
> >> >
> >> > The redirection works on HTTP but not HTTPS.
> >> >
> >> > http://youkoop.com => https://www.youkoop.com *works*
> >> >
> >> Note: Images don't get through in this mailing list. I can imagine
> >> what
> >> "works" means, but for your next example: Please elaborate what "does
> >> not work" means.
> >> >
> >> > *https*://youkoop.com <http://youkoop.com> =>
> >> > https://www.youkoop.com *does not work*
> >>
> >> First thing to test: Does https://youkoop.com work without the
> >> redirect,
> >> then with the "wrong" host name? Otherwise it might be as simple as a
> >> misconfigured TLS host that's never invoked because of a certificate
> >> mismatch.
> >>
> >> Olaf
> >>
> >>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: RewriteValve does not work on HTTPS

[Felix Schumacher]

Am 04.02.2020 22:16, schrieb Hua Zhang:

What I mean with word 'works' is: the RewriteRule has been executed.

That is not the case by HTTPS. The rule has not been executed while the
RewriteCond is fulfilled.


Can you give us more information on your setup? Is there any 
Proxy/Loadbalancer in front of your tomcat? If so, can you show us 
details on that setup?

What is the value of the host request header in both cases?

Felix


Olaf Kock  于 2020年2月4日周二 下午9:06写道：



On 04.02.20 20:31, Hua Zhang wrote:
> Best tomcat team,
>
> Hereby I have a question about an issue I found by using RewriteValve
> on tomcat 9.30
>
> The rewrite.config is very simple:
>
> /RewriteCond %{HTTP_HOST} =youkoop.com <http://youkoop.com>
> RewriteRule ^.*$ https://www.youkoop.com [R=301,L]
> /
>
> All I want is just redirect a naked root domain to a www domain with
> HTTPS.
>
> The redirection works on HTTP but not HTTPS.
>
> http://youkoop.com => https://www.youkoop.com *works*
>
Note: Images don't get through in this mailing list. I can imagine 
what

"works" means, but for your next example: Please elaborate what "does
not work" means.
>
> *https*://youkoop.com <http://youkoop.com> =>
> https://www.youkoop.com *does not work*

First thing to test: Does https://youkoop.com work without the 
redirect,

then with the "wrong" host name? Otherwise it might be as simple as a
misconfigured TLS host that's never invoked because of a certificate
mismatch.

Olaf




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: RewriteValve does not work on HTTPS

[Hua Zhang]

What I mean with word 'works' is: the RewriteRule has been executed.

That is not the case by HTTPS. The rule has not been executed while the
RewriteCond is fulfilled.

Olaf Kock  于 2020年2月4日周二 下午9:06写道：

>
> On 04.02.20 20:31, Hua Zhang wrote:
> > Best tomcat team,
> >
> > Hereby I have a question about an issue I found by using RewriteValve
> > on tomcat 9.30
> >
> > The rewrite.config is very simple:
> >
> > /RewriteCond %{HTTP_HOST} =youkoop.com <http://youkoop.com>
> > RewriteRule ^.*$ https://www.youkoop.com [R=301,L]
> > /
> >
> > All I want is just redirect a naked root domain to a www domain with
> > HTTPS.
> >
> > The redirection works on HTTP but not HTTPS.
> >
> > http://youkoop.com => https://www.youkoop.com *works*
> >
> Note: Images don't get through in this mailing list. I can imagine what
> "works" means, but for your next example: Please elaborate what "does
> not work" means.
> >
> > *https*://youkoop.com <http://youkoop.com> =>
> > https://www.youkoop.com *does not work*
>
> First thing to test: Does https://youkoop.com work without the redirect,
> then with the "wrong" host name? Otherwise it might be as simple as a
> misconfigured TLS host that's never invoked because of a certificate
> mismatch.
>
> Olaf
>
>

Re: RewriteValve does not work on HTTPS

[Olaf Kock]

On 04.02.20 20:31, Hua Zhang wrote:
> Best tomcat team,
>
> Hereby I have a question about an issue I found by using RewriteValve
> on tomcat 9.30
>
> The rewrite.config is very simple:
>
> /RewriteCond %{HTTP_HOST} =youkoop.com <http://youkoop.com>
> RewriteRule ^.*$ https://www.youkoop.com [R=301,L]
> /
>
> All I want is just redirect a naked root domain to a www domain with
> HTTPS.
>
> The redirection works on HTTP but not HTTPS.
>
> http://youkoop.com => https://www.youkoop.com *works*
>
Note: Images don't get through in this mailing list. I can imagine what
"works" means, but for your next example: Please elaborate what "does
not work" means.
>
> *https*://youkoop.com <http://youkoop.com> =>
> https://www.youkoop.com *does not work*

First thing to test: Does https://youkoop.com work without the redirect,
then with the "wrong" host name? Otherwise it might be as simple as a
misconfigured TLS host that's never invoked because of a certificate
mismatch.

Olaf

RewriteValve does not work on HTTPS

[Hua Zhang]

Best tomcat team,

Hereby I have a question about an issue I found by using RewriteValve on
tomcat 9.30

The rewrite.config is very simple:



*RewriteCond %{HTTP_HOST} =youkoop.com <http://youkoop.com>RewriteRule ^.*$
https://www.youkoop.com <https://www.youkoop.com> [R=301,L]*

All I want is just redirect a naked root domain to a www domain with HTTPS.

The redirection works on HTTP but not HTTPS.

http://youkoop.com => https://www.youkoop.com *works*

[image: image.png]

*https*://youkoop.com => https://www.youkoop.com *does not work*
[image: image.png]


I believe that there is something wrong with RewriteValve, or probably
related to he new sslhostconfig element, which is introduced from 8.5,
because the same rule works before on tomcat 8.0.


Best regards,

Hua


P.S. I originally make a bug report here:
https://bz.apache.org/bugzilla/show_bug.cgi?id=64112

Re: Path parameters with RewriteValve

[Mark Thomas]

On 17/09/2019 19:00, Alain Sellerin wrote:
> On Mon, Sep 16, 2019 at 1:49 PM Mark Thomas  wrote:



> Hi Mark,
> 
> Thank you for your analysis. It is really helping me. I have the
> confirmation that it is an expected behavior and that there is a
> rational behind it.
> 
> For curiosity, what is the non-spec API to obtain path parameters?

It only gets a value for a name. It doesn't provide access to which
segment, it doesn't handle multiple instances of the same parameter, etc.

http://tomcat.apache.org/tomcat-9.0-doc/api/org/apache/coyote/Request.html#getPathParameter-java.lang.String-

> Unfortunately I can't use it in my context, I'm not the owner of the
> underlying webapp and I can't modify its code.
> Actually we have a fix for the problem but it's not clean and I wanted
> to check if there is a better solution (in our solution, there is an
> nginx proxy in front of tomcat that replace all semicolon of the url
> with an unique sequence of character and in the RewriteValve there is
> the opposite operation).

That is as good as anything I can come up with off the top of my head.

> About all the questions about path param position, I think it is
> application specific and no assumption can be made. The implementer of
> rewrite.config have to handle all cases.

I agree. Where things get "interesting" is when the number of path
segments change or a segment with a parameter is re-written.

> For example, in my case I
> know path param cannot be in the first position, and I also know that
> semicolon can only be used for path param.
> 
> All that being said, I think it would be an interesting feature to
> have some "insecure mode" or "power user mode"  where the raw url is
> available in RewriteValve. At least in our case it would have help,
> but it's probably not a sufficiently widespread scenario in order to
> bother with it  :)

The risk with that is generally issues with /../ sequences, %nn encoding
etc. It tends to be very easy to bypass the rewrite rule.

I don't think there is an easy solution to this.

Mark


> For example in Nginx, there is a parameter $uri which is the uri after
> normalisation and $request_uri which is the uri as requested by the
> client. Both are available and there is no limitation for rewriting
> uri.
> 
> Alain
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Path parameters with RewriteValve

[Alain Sellerin]

On Mon, Sep 16, 2019 at 1:49 PM Mark Thomas  wrote:
>
> > Alain,
> > On 9/13/19 13:37, Alain Sellerin wrote:
> >>>> Tomcat version: 8.5 OS: Win10, Linux
>
> 
>
> >>>> I'm facing an issue with an application that is using path
> >>>> parameters in conjunction with a RewriteValve.
>
> 
>
> >>>> If the request is :
> >>>> http://127.0.0.1:8080/foo/subpath;pathparam1=123/hello.jsp The
> >>>> servlet response is: Request URI: /sample/subpath/hello.jsp
> >>>>
> >>>> In this case, Tomcat stripped the path param. I was expecting it to
> >>>> be maintained after the rewriting of the URL.
> >>>>
> >>>> I would like to know if there is a way to preserve path parameters
> >>>> from the URL after a rewrite or if it is a bug that I could report
> >>>> to Bugzilla.
> >>>>
> >>>> Feel free to ask me any question if it is not clear enough.
>
> 
>
> > Thank you for your return. As suggested I made a few test with
> > different parameters
> >
> > If the request is :
> > http://127.0.0.1:8080/foo/subpath;pathparam1=123/hello.jsp
> > The servlet response is: Request URI: /sample/subpath/hello.jsp
> >
> > If the request is :
> > http://127.0.0.1:8080/foo/subpath;pathparam=123/hello.jsp
> > The servlet response is: Request URI: /sample/subpath/hello.jsp
> >
> > If the request is :
> > http://127.0.0.1:8080/foo/subpath;pathparam=123/hello.jsp
> > The servlet response is: Request URI: /sample/subpath/hello.jsp
> >
> > If the request is :
> > http://127.0.0.1:8080/foo/subpath;xyz/hello.jsp
> > The servlet response is: Request URI: /sample/subpath/hello.jsp
> >
> > In all cases, path param is stripped.
>
> This is (sort of) by design.
>
> The only mention the Servlet spec makes of path parameters is that:
>
> 
> Path parameters that are part of a GET request (as defined by HTTP 1.1)
> are not exposed by these APIs. They must be parsed from the String
> values returned by the getRequestURI method or the getPathInfo method.
> 
>
> The issue is that Tomcat needs to remove the path parameters (and a
> bunch of other stuff) before mapping requests to security constraints,
> Filters and Servlets else you open up a bunch of security
> vulnerabilities around security constraint bypass and/or path traversal.
>
> For similar reasons the RewriteValve also works with the version of the
> URI that has had path parameters removed.
>
> Tomcat provides a very simple non-spec API to obtain path parameters. I
> am sure it is possible to retain (it would have to be "re-insert" rather
> than "retain") the path parameters as a request passes through the
> RewriteValve. However, there are lots of edge cases and it could get
> rather messy, very quickly. I am not sure it is practical.
>
> There are also questions of expected behaviour.
>
> If "/foo" is rewritten to "/bar" is "/foo;a=b" rewritten to "/bar;a=b" ?
>
> If "/foo/*" is rewritten to "/bar/too/*" is "/foo/xxx;a=b" rewritten to
> "/bar/too;a=b/xxx" or "/bar/too/xxx;a=b", or... ?
>
> i.e. does the path parameter retain its position in the nth URI segment,
> does it stay with the segment it was originally defined on or does it do
> something else?
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

Hi Mark,

Thank you for your analysis. It is really helping me. I have the
confirmation that it is an expected behavior and that there is a
rational behind it.

For curiosity, what is the non-spec API to obtain path parameters?
Unfortunately I can't use it in my context, I'm not the owner of the
underlying webapp and I can't modify its code.
Actually we have a fix for the problem but it's not clean and I wanted
to check if there is a better solution (in our solution, there is an
nginx proxy in front of tomcat that replace all semicolon of the url
with an unique sequence of character and in the RewriteValve there is
the opposite operation).

About all the questions about path param position, I think it is
application specific and no assumption can be made. The implementer of
rewrite.config have to handle all cases. For example, in my case I
know path param cannot be in the first position, and I also know that
semicolon can only be used for path param.

All that being said, I think it would be an interesting feature to
have some "insecure mode" or "power user mode"  where the raw url is
available in RewriteValve. At least in our case it would have help,
but it's probably not a sufficiently widespread scenario in order to
bother with it  :)
For example in Nginx, there is a parameter $uri which is the uri after
normalisation and $request_uri which is the uri as requested by the
client. Both are available and there is no limitation for rewriting
uri.

Alain

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Path parameters with RewriteValve

[Mark Thomas]

> Alain,
> On 9/13/19 13:37, Alain Sellerin wrote:
>>>> Tomcat version: 8.5 OS: Win10, Linux



>>>> I'm facing an issue with an application that is using path
>>>> parameters in conjunction with a RewriteValve.



>>>> If the request is :
>>>> http://127.0.0.1:8080/foo/subpath;pathparam1=123/hello.jsp The
>>>> servlet response is: Request URI: /sample/subpath/hello.jsp
>>>>
>>>> In this case, Tomcat stripped the path param. I was expecting it to
>>>> be maintained after the rewriting of the URL.
>>>>
>>>> I would like to know if there is a way to preserve path parameters
>>>> from the URL after a rewrite or if it is a bug that I could report
>>>> to Bugzilla.
>>>>
>>>> Feel free to ask me any question if it is not clear enough.



> Thank you for your return. As suggested I made a few test with
> different parameters
> 
> If the request is :
> http://127.0.0.1:8080/foo/subpath;pathparam1=123/hello.jsp
> The servlet response is: Request URI: /sample/subpath/hello.jsp
> 
> If the request is :
> http://127.0.0.1:8080/foo/subpath;pathparam=123/hello.jsp
> The servlet response is: Request URI: /sample/subpath/hello.jsp
> 
> If the request is :
> http://127.0.0.1:8080/foo/subpath;pathparam=123/hello.jsp
> The servlet response is: Request URI: /sample/subpath/hello.jsp
> 
> If the request is :
> http://127.0.0.1:8080/foo/subpath;xyz/hello.jsp
> The servlet response is: Request URI: /sample/subpath/hello.jsp
> 
> In all cases, path param is stripped.

This is (sort of) by design.

The only mention the Servlet spec makes of path parameters is that:


Path parameters that are part of a GET request (as defined by HTTP 1.1)
are not exposed by these APIs. They must be parsed from the String
values returned by the getRequestURI method or the getPathInfo method.


The issue is that Tomcat needs to remove the path parameters (and a
bunch of other stuff) before mapping requests to security constraints,
Filters and Servlets else you open up a bunch of security
vulnerabilities around security constraint bypass and/or path traversal.

For similar reasons the RewriteValve also works with the version of the
URI that has had path parameters removed.

Tomcat provides a very simple non-spec API to obtain path parameters. I
am sure it is possible to retain (it would have to be "re-insert" rather
than "retain") the path parameters as a request passes through the
RewriteValve. However, there are lots of edge cases and it could get
rather messy, very quickly. I am not sure it is practical.

There are also questions of expected behaviour.

If "/foo" is rewritten to "/bar" is "/foo;a=b" rewritten to "/bar;a=b" ?

If "/foo/*" is rewritten to "/bar/too/*" is "/foo/xxx;a=b" rewritten to
"/bar/too;a=b/xxx" or "/bar/too/xxx;a=b", or... ?

i.e. does the path parameter retain its position in the nth URI segment,
does it stay with the segment it was originally defined on or does it do
something else?

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Path parameters with RewriteValve

[Alain Sellerin]

On Sat, Sep 14, 2019 at 5:42 PM Christopher Schultz
 wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Alain,
>
> On 9/13/19 13:37, Alain Sellerin wrote:
> > Tomcat version: 8.5 OS: Win10, Linux
> >
> > Hi,
> >
> > I'm facing an issue with an application that is using path
> > parameters in conjunction with a RewriteValve.
> >
> > I narrowed down the problem by using the sample application
> > available here:
> > https://tomcat.apache.org/tomcat-8.5-doc/appdev/sample/
> >
> > Context ==
> >
> > 1) I modified the webapp sample.war by creating a sub directory
> > "subpath" where I copied the file hello.jsp
> >
> > The servlet URL is :
> > http://127.0.0.1:8080/sample/subpath/hello.jsp
> >
> > 2) I modified the servlet with the following code
> >
> > Request URI:  <%= request.getRequestURI() %>
> >
> > 3) I added a RewriteValve by making 2 changes in ROOT webapp a)
> > create context.xml in webapps\ROOT\META-INF with the following
> > content
> >
> >   > path="/" reloadable="true" crossContext="true">  > className="org.apache.catalina.valves.rewrite.RewriteValve"/>
> > 
> >
> > b) create rewrite.config in  webapps\ROOT\WEB-INF with the
> > following content
> >
> > RewriteRule ^/foo/(.*) /sample/$1 [L]
> >
> > NB: The base of the url is rewritten to "sample" when it is equals
> > to "foo"
> >
> >
> > Description of the problem 
> >
> > If the request is : http://127.0.0.1:8080/sample/subpath/hello.jsp
> > The servlet response is: Request URI: /sample/subpath/hello.jsp
> >
> > It is as expected. So far no problem.
> >
> > If the request is :
> > http://127.0.0.1:8080/sample/subpath;pathparam=123/hello.jsp The
> > servlet response is: Request URI:
> > /sample/subpath;pathparam=123/hello.jsp
> >
> > It is also as expected. Path params are displayed.
> >
> > If the request is :
> > http://127.0.0.1:8080/foo/subpath;pathparam1=123/hello.jsp The
> > servlet response is: Request URI: /sample/subpath/hello.jsp
> >
> > In this case, Tomcat stripped the path param. I was expecting it to
> > be maintained after the rewriting of the URL.
> >
> > I would like to know if there is a way to preserve path parameters
> > from the URL after a rewrite or if it is a bug that I could report
> > to Bugzilla.
> >
> > Feel free to ask me any question if it is not clear enough.
>
> This sounds like a bug to me.
>
> Can you play with the path parameter a little bit to see what might be
> triggering it? You tried with "pathparam" as the name and all was
> well. Then you tried "pathparam1" and it failed. What about
> "pathparamX" where X is a random character from your keyboard.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl19CkoACgkQHPApP6U8
> pFi9mxAAlzxiDeYqP5qlRI4PKhrNFmGhqVXfi6SBv5P2lbydMSEDi5MG/t+54eH1
> TY/IgnaocZJWEeiOG4W3lESmk+++UHKK+BvnlWaZrbujTZZLSkoHleGPMQ5DW+sy
> Y1dTOSVe8kvwtfckrK42Jhi20/CNydyjb0JpdD+jXnf+qas7yEC78tWUbcTXYNsr
> lMOY7yXP7Y5dKE907nzrX44FYkNdyoNYRM3fGkRlsKB40TFn1tNPgn6Y0x4zGaOO
> ii2DGYMGxIetflvFwvZU3nfjp+L6u0e7uLGD9twsuyhgsL8oImhUssne6XEXMRzE
> 4xlb/vK8Aao9YbZuVl9RnaYhTEB6pz6ytdEhOdY9ci0xkCRJVMLEFf8Tt2y4qVmm
> pBl7vQtrpK3Mj6JCNXKra9N7A029B8/684HS+kfeUC5Q8fEHxbXJZX3kHJFXQRAd
> q7rhe5QrX0TCQumnsoil+NKGtI5HrrM3EjkRl0sXK6JYmItJMcjchh02Y+3xit43
> vp63EOJhjnGjU+mvQDjH2cqRBOXYc5kR2a7eBAkaswhDjiNY5nhJaowBpGsYruy0
> f3537ufE97PIEH+przQAVEJb37W56idGkTKrJq1XOvZNNsIjl/1AGwiFM4eZVl1d
> qI43T790I36VOg6C+rJIzY7SE0E217tiUp0/48SBn/5ORhi7/28=
> =iPM6
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

Hi Chris,

Thank you for your return. As suggested I made a few test with
different parameters

If the request is :
http://127.0.0.1:8080/foo/subpath;pathparam1=123/hello.jsp
The servlet response is: Request URI: /sample/subpath/hello.jsp

If the request is :
http://127.0.0.1:8080/foo/subpath;pathparam=123/hello.jsp
The servlet response is: Request URI: /sample/subpath/hello.jsp

If the request is :
http://127.0.0.1:8080/foo/subpath;pathparam=123/hello.jsp
The servlet response is: Request URI: /sample/subpath/hello.jsp

If the request is :
http://127.0.0.1:8080/foo/subpath;xyz/hello.jsp
The servlet response is: Request URI: /sample/subpath/hello.jsp

In all cases, path param is stripped.

Alain

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Path parameters with RewriteValve

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Alain,

On 9/13/19 13:37, Alain Sellerin wrote:
> Tomcat version: 8.5 OS: Win10, Linux
> 
> Hi,
> 
> I'm facing an issue with an application that is using path
> parameters in conjunction with a RewriteValve.
> 
> I narrowed down the problem by using the sample application
> available here:
> https://tomcat.apache.org/tomcat-8.5-doc/appdev/sample/
> 
> Context ==
> 
> 1) I modified the webapp sample.war by creating a sub directory 
> "subpath" where I copied the file hello.jsp
> 
> The servlet URL is :
> http://127.0.0.1:8080/sample/subpath/hello.jsp
> 
> 2) I modified the servlet with the following code
> 
> Request URI:  <%= request.getRequestURI() %>
> 
> 3) I added a RewriteValve by making 2 changes in ROOT webapp a)
> create context.xml in webapps\ROOT\META-INF with the following
> content
> 
>   path="/" reloadable="true" crossContext="true">  className="org.apache.catalina.valves.rewrite.RewriteValve"/> 
> 
> 
> b) create rewrite.config in  webapps\ROOT\WEB-INF with the
> following content
> 
> RewriteRule ^/foo/(.*) /sample/$1 [L]
> 
> NB: The base of the url is rewritten to "sample" when it is equals
> to "foo"
> 
> 
> Description of the problem 
> 
> If the request is : http://127.0.0.1:8080/sample/subpath/hello.jsp 
> The servlet response is: Request URI: /sample/subpath/hello.jsp
> 
> It is as expected. So far no problem.
> 
> If the request is : 
> http://127.0.0.1:8080/sample/subpath;pathparam=123/hello.jsp The
> servlet response is: Request URI:
> /sample/subpath;pathparam=123/hello.jsp
> 
> It is also as expected. Path params are displayed.
> 
> If the request is :
> http://127.0.0.1:8080/foo/subpath;pathparam1=123/hello.jsp The
> servlet response is: Request URI: /sample/subpath/hello.jsp
> 
> In this case, Tomcat stripped the path param. I was expecting it to
> be maintained after the rewriting of the URL.
> 
> I would like to know if there is a way to preserve path parameters 
> from the URL after a rewrite or if it is a bug that I could report
> to Bugzilla.
> 
> Feel free to ask me any question if it is not clear enough.

This sounds like a bug to me.

Can you play with the path parameter a little bit to see what might be
triggering it? You tried with "pathparam" as the name and all was
well. Then you tried "pathparam1" and it failed. What about
"pathparamX" where X is a random character from your keyboard.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl19CkoACgkQHPApP6U8
pFi9mxAAlzxiDeYqP5qlRI4PKhrNFmGhqVXfi6SBv5P2lbydMSEDi5MG/t+54eH1
TY/IgnaocZJWEeiOG4W3lESmk+++UHKK+BvnlWaZrbujTZZLSkoHleGPMQ5DW+sy
Y1dTOSVe8kvwtfckrK42Jhi20/CNydyjb0JpdD+jXnf+qas7yEC78tWUbcTXYNsr
lMOY7yXP7Y5dKE907nzrX44FYkNdyoNYRM3fGkRlsKB40TFn1tNPgn6Y0x4zGaOO
ii2DGYMGxIetflvFwvZU3nfjp+L6u0e7uLGD9twsuyhgsL8oImhUssne6XEXMRzE
4xlb/vK8Aao9YbZuVl9RnaYhTEB6pz6ytdEhOdY9ci0xkCRJVMLEFf8Tt2y4qVmm
pBl7vQtrpK3Mj6JCNXKra9N7A029B8/684HS+kfeUC5Q8fEHxbXJZX3kHJFXQRAd
q7rhe5QrX0TCQumnsoil+NKGtI5HrrM3EjkRl0sXK6JYmItJMcjchh02Y+3xit43
vp63EOJhjnGjU+mvQDjH2cqRBOXYc5kR2a7eBAkaswhDjiNY5nhJaowBpGsYruy0
f3537ufE97PIEH+przQAVEJb37W56idGkTKrJq1XOvZNNsIjl/1AGwiFM4eZVl1d
qI43T790I36VOg6C+rJIzY7SE0E217tiUp0/48SBn/5ORhi7/28=
=iPM6
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Path parameters with RewriteValve

[Alain Sellerin]

Tomcat version: 8.5
OS: Win10, Linux

Hi,

I'm facing an issue with an application that is using path parameters
in conjunction with a RewriteValve.

I narrowed down the problem by using the sample application available
here:  https://tomcat.apache.org/tomcat-8.5-doc/appdev/sample/

Context
==

1) I modified the webapp sample.war by creating a sub directory
"subpath" where I copied the file hello.jsp

The servlet URL is :  http://127.0.0.1:8080/sample/subpath/hello.jsp

2) I modified the servlet with the following code

Request URI:  <%= request.getRequestURI() %>

3) I added a RewriteValve by making 2 changes in ROOT webapp
a) create context.xml in webapps\ROOT\META-INF with the following content






b) create rewrite.config in  webapps\ROOT\WEB-INF with the following content

RewriteRule ^/foo/(.*) /sample/$1 [L]

NB: The base of the url is rewritten to "sample" when it is equals to "foo"


Description of the problem


If the request is : http://127.0.0.1:8080/sample/subpath/hello.jsp
The servlet response is:
Request URI: /sample/subpath/hello.jsp

It is as expected. So far no problem.

If the request is :
http://127.0.0.1:8080/sample/subpath;pathparam=123/hello.jsp
The servlet response is:
Request URI: /sample/subpath;pathparam=123/hello.jsp

It is also as expected. Path params are displayed.

If the request is : http://127.0.0.1:8080/foo/subpath;pathparam1=123/hello.jsp
The servlet response is:
Request URI: /sample/subpath/hello.jsp

In this case, Tomcat stripped the path param. I was expecting it to be
maintained after the rewriting of the URL.

I would like to know if there is a way to preserve path parameters
from the URL after a rewrite or if it is a bug that I could report to
Bugzilla.

Feel free to ask me any question if it is not clear enough.

Thank you for your help.

Best regards
Alain

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

rewritevalve logging

[Chris Cheshire]

I am trying to convert some url rewriting rules from tuckey rewrite
filter to tomcat's rewrite valve.

In my context.xml I have



In my WEB-INF directory I have a rewrite.config file with a couple of rules.

In tomcat's logging.properties I have

org.apache.catalina.core.ContainerBase.[Catalina].[hostname].level = FINEST

in catalina.out I see

21-Jan-2019 19:28:36.969 FINE [main]
org.apache.catalina.valves.rewrite.RewriteValve.startInternal Read
configuration from: /WEB-INF/rewrite.config
21-Jan-2019 19:28:36.971 FINE [main]
org.apache.catalina.valves.rewrite.RewriteValve.parse Add rule with
pattern ^(.*)\.[0-9]{13}\.(css|js)$ and substitution $1.$

(plus other lines for other rules)

on startup but this is all I see.

The few rules I have in there work, but I would like to debug as I go
when adding more rules. Does the valve not log anything as it is
processing rules?

Chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RewriteValve and REQUEST_FILENAME not working

[Norbert Harrer]

Hi.

I use Tomcat 8.5.23. My context.xml looks like this:

    
    
        className="org.apache.catalina.valves.rewrite.RewriteValve" />

WEB-INF/rewrite.config
    


My rewrite.config looks like this:

    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule (.*) /index.html [L]


I was hoping it would redirect any url to /index.html except if the url 
is matching an existing file. Instead I get this exception with any url:


java.lang.IllegalArgumentException: The resource path [null] is not valid

org.apache.catalina.webresources.StandardRoot.validate(StandardRoot.java:251)

org.apache.catalina.webresources.StandardRoot.getResource(StandardRoot.java:212)

org.apache.catalina.webresources.StandardRoot.getResource(StandardRoot.java:206)

org.apache.catalina.valves.rewrite.ResolverImpl.resolveResource(ResolverImpl.java:156)

org.apache.catalina.valves.rewrite.RewriteCond$ResourceCondition.evaluate(RewriteCond.java:81)

org.apache.catalina.valves.rewrite.RewriteCond.evaluate(RewriteCond.java:233)

org.apache.catalina.valves.rewrite.RewriteRule.evaluate(RewriteRule.java:107)

org.apache.catalina.valves.rewrite.RewriteValve.invoke(RewriteValve.java:313)

org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81)

org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:650)

org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:342)

org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:803)

org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)

org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868)

org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1459)

org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)

java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
java.lang.Thread.run(Thread.java:745)


I debugged a little bit into 
org.apache.catalina.valves.rewrite.ResolverImpl. In resolve() it 
recognizes REQUEST_FILENAME and then calls request.getPathTranslated() 
which returns null however. Stepping into getPathTranslated(), it turns 
out that request.getPathInfo() is null altogether, which should contain 
the url information. It almost seems like it isn't initialized at that 
time.


Is this a bug or am I doing something wrong?

Regards,
Norbert

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: RewriteValve and the ROOT webapp

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 8/30/17 5:03 PM, Mark Thomas wrote:
> On 30/08/17 21:46, Dan Rabe wrote:
>> I’m using Tomcat 8.5.20, trying to use the rewrite valve to
>> rewrite a root-level URL (/foo) to a URL in my webapp
>> (/mywebapp/bar).
>> 
>> I added the rewrite valve to my server.xml, and I put my
>> rewrite.config in conf/Catalina/localhost.
>> 
>> This all works great IF I create an empty “ROOT” directory in
>> webapps. If I remove the ROOT directory, though, accessing /foo
>> just gives me a 404.
>> 
>> Questions:
>> 
>> 1.  Is this by design, or is this a bug? (If it’s by design, then
>> some additional notes in the documentation would be helpful).
> 
> It is by design. See section 12.1 of the Servlet 3.1
> specification. Particularly the first paragraph.
> 
> The Tomcat docs deliberately try to avoid repeating information
> that is in the Servlet specification.
> 
>> 2.  If in fact I do need to have the ROOT webapp, what security
>> precautions should I take? Security guides such as
>> https://www.owasp.org/index.php/Securing_tomcat recommend
>> removing the ROOT webapp, but without providing reasons or
>> rationale.
> 
> Yes, it would help if OWASP explained their rationale.

I believe the OWASP rationale is that Tomcat ships with a ("welcome to
Tomcat") ROOT web app that is simply unnecessary, and unnecessary
things should be removed from production systems.

They obviously aren't explaining that there is nothing wrong with
having *a* ROOT webapp... it's just that the *default* ROOT webapp
should be removed for production.

> The simplest, and safest, approach would be to deploy your own, 
> completely empty ROOT web application (just a dir named "ROOT" in 
> webapps will be fine). Tomcat will handle the 404 for you in that
> case.

Our production builds always include a generated ROOT webapp that
includes absolutely nothing other than a trivial WEB-INF/web.xml. This
allows Tomcat to return a 404 response instead of a "400 Bad Request"
for any requests that don't map to a valid context path.

(Aside: I think it's probably not appropriate for Tomcat to return 400
in these cases... if the URL can't be mapped to a context, that should
be a 404 response, not a 400, since the request itself was valid.)

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJZqC8SAAoJEBzwKT+lPKRYfjsP/ik3k5Y7U0b1uLaTQQkjoyxt
3Dpg95p8wQTGelVrw3PFmQZMdnhyMFkro3W0XN4B4EHedZIl61NMyapoLki9IgQA
JLf+xcMIL9Fxi9ELw7jpxnA86dR56bLD0SQZ+gyg8oQ2uSNQvADYFRU2G+MsCBq3
WXykSDAyOc7IzUI4jGkVkYCYLTu4Qz3UljeKyYz8X10Hxw6ooNdps/vrOYSebhyX
mVcASlrRBaWJ/AVyUCIcrZaCAbx73kEzCVJrp5qjBdePY9see6dlQk3wRx+kuRoZ
YWO/6sPm9zVW2iKBxx44lQ5yGRrFIfO9vQ0yGHtKbPxYQ8ZLPjsJeQqMHHPsBoIR
OglGNZ0XI7vxVuElIRS2dekgSalxtu0WZ/RY/SaADC+uShVdETwO23y96L60L+QX
r4HU+iBK9U2JWvUqrn+xZCZ7VMzm1LyUXd29Ve5YG+hGg1UQLJT5dTNg4kBe0R96
oowErlvnG70PLmk0pKHBSjZiwhsyuz+lxpxOHyc13orm+hWTQZwGm8hNca6MWSmk
lIwp88C6Q6DHwmVeyQq5lUcEI+SYsRGI0zU/k9aDkY6RYcU1ansq9LafJIQGWPRi
h6eaTtDq2lSkvt27vrZM0mVDYPi8VIK2mSbcu/oYRlzg262eMicQIOpCwLiLcuhx
dZh1L4FBOSyYZ/ISGRW8
=Zsxc
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: RewriteValve and the ROOT webapp

[tomcat]

On 30.08.2017 22:46, Dan Rabe wrote:

I’m using Tomcat 8.5.20, trying to use the rewrite valve to rewrite a 
root-level URL (/foo) to a URL in my webapp (/mywebapp/bar).

I added the rewrite valve to my server.xml, and I put my rewrite.config in 
conf/Catalina/localhost.

This all works great IF I create an empty “ROOT” directory in webapps. If I 
remove the ROOT directory, though, accessing /foo just gives me a 404.

Questions:

   1.  Is this by design, or is this a bug? (If it’s by design, then some 
additional notes in the documentation would be helpful).
   2.  If in fact I do need to have the ROOT webapp, what security precautions 
should I take?


The same as you take with any other webapp.  There is nothing really special about the 
ROOT webapp, except that it responds to the URI "/", but is located under 
(catalina_base)/webapps/ROOT/.
You can replace this easily with your own application, which will then respond to a 
request for "/". See :

https://wiki.apache.org/tomcat/HowTo#How_do_I_make_my_web_application_be_the_Tomcat_default_application.3F

Security guides such as https://www.owasp.org/index.php/Securing_tomcat recommend removing 
the ROOT webapp, but without providing reasons or rationale.


Indeed there is no particular reason (in terms of security). The only "reason" which I can 
think of, is that the standard distribution of tomcat (from https://tomcat.apache.org) 
includes a default ROOT webapp with some information page and a few links, and you 
probably don't want to provide /this/ application as the default application on a 
productive website (you would probably want yours instead).  But I would imagine that the 
tomcat developers do not provide there by default, an application which has (known) 
security issues.


Mmm, I just realised that I am in fact just repeating what a small section of this page is 
already saying :

https://tomcat.apache.org/tomcat-8.0-doc/security-howto.html#ROOT
(and by the way, that same page provides a whole series of tips regarding tomcat security, 
and it does provides reasons for each such tip).



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: RewriteValve and the ROOT webapp

[Mark Thomas]

On 30/08/17 21:46, Dan Rabe wrote:
> I’m using Tomcat 8.5.20, trying to use the rewrite valve to rewrite a 
> root-level URL (/foo) to a URL in my webapp (/mywebapp/bar).
> 
> I added the rewrite valve to my server.xml, and I put my rewrite.config in 
> conf/Catalina/localhost.
> 
> This all works great IF I create an empty “ROOT” directory in webapps. If I 
> remove the ROOT directory, though, accessing /foo just gives me a 404.
> 
> Questions:
> 
>   1.  Is this by design, or is this a bug? (If it’s by design, then some 
> additional notes in the documentation would be helpful).

It is by design. See section 12.1 of the Servlet 3.1 specification.
Particularly the first paragraph.

The Tomcat docs deliberately try to avoid repeating information that is
in the Servlet specification.

>   2.  If in fact I do need to have the ROOT webapp, what security precautions 
> should I take? Security guides such as 
> https://www.owasp.org/index.php/Securing_tomcat recommend removing the ROOT 
> webapp, but without providing reasons or rationale.

Yes, it would help if OWASP explained their rationale.

The simplest, and safest, approach would be to deploy your own,
completely empty ROOT web application (just a dir named "ROOT" in
webapps will be fine). Tomcat will handle the 404 for you in that case.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RewriteValve and the ROOT webapp

[Dan Rabe]

I’m using Tomcat 8.5.20, trying to use the rewrite valve to rewrite a 
root-level URL (/foo) to a URL in my webapp (/mywebapp/bar).

I added the rewrite valve to my server.xml, and I put my rewrite.config in 
conf/Catalina/localhost.

This all works great IF I create an empty “ROOT” directory in webapps. If I 
remove the ROOT directory, though, accessing /foo just gives me a 404.

Questions:

  1.  Is this by design, or is this a bug? (If it’s by design, then some 
additional notes in the documentation would be helpful).
  2.  If in fact I do need to have the ROOT webapp, what security precautions 
should I take? Security guides such as 
https://www.owasp.org/index.php/Securing_tomcat recommend removing the ROOT 
webapp, but without providing reasons or rationale.

Thank you!
--Dan Rabe

Re: Issue between RewriteValve and DefaultServlet

[Jérémie Barthés]

"That behaviour is expected."

I really didn't expect that. it took me two weeks, two years ago to understand 
why i had a redirect and not a forward if my URI last char isn't a '/'
---
"The way to handle this is to wrap the response and intercept
the call that sets the location header and modify the value before
calling the wrapped response."

we have other service using redirection to work. It's tricky to wrap response 
then change location headers without disturbing our 302 redirections.

May this method be protected in following versions ?
"Unlikely at this point."

it would really help in our case. We'll study for other solutions anyway


Thanks

Jeremie


Le 26/06/2017 à 14:52, Mark Thomas a écrit :

On 26/06/17 11:22, Jérémie Barthés wrote:

Thank for your  fast answer

I would like to extend DefaultServlet to override doDirectoryRedirect
but the method is private,
private void doDirectoryRedirect(HttpServletRequest request,
HttpServletResponse response)

May this method be protected in following versions ?

Unlikely at this point.


i can't change a header on the way out, after server started to answer,
can i ?

Correct. The way to handle this is to wrap the response and intercept
the call that sets the location header and modify the value before
calling the wrapped response.

Mark



Regard

Jeremie

PS : i added a custom valve just to put non-rewritten URI in a request
attribute, so i can use it if present when doDirectoryRedirect occurs


Le 26/06/2017 à 12:01, Mark Thomas a écrit :

On 26/06/17 10:55, Jérémie Barthés wrote:

Hi,

I have an issue between org.apache.catalina.valves.rewrite.RewriteValve
and org.apache.catalina.servlets.DefaultServlets

If my request is forwarded by the RewriteValve and then pass into
doDirectoryRedirect in DefaultServlets to be redirected. The hidden
rewritten URI is displayed in the browser.

To test it, try the following example (any tomcat 8, 8.5 or 9)

add RewriteValve in conf/server.xml


add rewriteRule in conf/Catalina/localhost/rewrite.config
RewriteRule ^/iWantThisVisible/(.*) $/examples/$1/

start tomcat

go to following URLs (any internet browser) :
http://localhost:8080/iWantThisVisible/servlets
http://localhost:8080/iWantThisVisible/servlets/

That behaviour is expected.

If you want to stick with the RewriteValve you'll need to write a custom
Valve or Filter to modify the HTTP headers on the way out.

You might be better off writing a custom Servlet that does a forward.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Issue between RewriteValve and DefaultServlet

[Mark Thomas]

On 26/06/17 11:22, Jérémie Barthés wrote:
> Thank for your  fast answer
> 
> I would like to extend DefaultServlet to override doDirectoryRedirect
> but the method is private,
> private void doDirectoryRedirect(HttpServletRequest request,
> HttpServletResponse response)
> 
> May this method be protected in following versions ?

Unlikely at this point.

> i can't change a header on the way out, after server started to answer,
> can i ?

Correct. The way to handle this is to wrap the response and intercept
the call that sets the location header and modify the value before
calling the wrapped response.

Mark


> 
> Regard
> 
> Jeremie
> 
> PS : i added a custom valve just to put non-rewritten URI in a request
> attribute, so i can use it if present when doDirectoryRedirect occurs
> 
> 
> Le 26/06/2017 à 12:01, Mark Thomas a écrit :
>> On 26/06/17 10:55, Jérémie Barthés wrote:
>>> Hi,
>>>
>>> I have an issue between org.apache.catalina.valves.rewrite.RewriteValve
>>> and org.apache.catalina.servlets.DefaultServlets
>>>
>>> If my request is forwarded by the RewriteValve and then pass into
>>> doDirectoryRedirect in DefaultServlets to be redirected. The hidden
>>> rewritten URI is displayed in the browser.
>>>
>>> To test it, try the following example (any tomcat 8, 8.5 or 9)
>>>
>>> add RewriteValve in conf/server.xml
>>> 
>>>
>>> add rewriteRule in conf/Catalina/localhost/rewrite.config
>>> RewriteRule ^/iWantThisVisible/(.*) $/examples/$1/
>>>
>>> start tomcat
>>>
>>> go to following URLs (any internet browser) :
>>> http://localhost:8080/iWantThisVisible/servlets
>>> http://localhost:8080/iWantThisVisible/servlets/
>> That behaviour is expected.
>>
>> If you want to stick with the RewriteValve you'll need to write a custom
>> Valve or Filter to modify the HTTP headers on the way out.
>>
>> You might be better off writing a custom Servlet that does a forward.
>>
>> Mark
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Issue between RewriteValve and DefaultServlet

[Jérémie Barthés]

Thank for your  fast answer

I would like to extend DefaultServlet to override doDirectoryRedirect 
but the method is private,
private void doDirectoryRedirect(HttpServletRequest request, 
HttpServletResponse response)


May this method be protected in following versions ?

i can't change a header on the way out, after server started to answer, 
can i ?


Regard

Jeremie

PS : i added a custom valve just to put non-rewritten URI in a request 
attribute, so i can use it if present when doDirectoryRedirect occurs



Le 26/06/2017 à 12:01, Mark Thomas a écrit :

On 26/06/17 10:55, Jérémie Barthés wrote:

Hi,

I have an issue between org.apache.catalina.valves.rewrite.RewriteValve
and org.apache.catalina.servlets.DefaultServlets

If my request is forwarded by the RewriteValve and then pass into
doDirectoryRedirect in DefaultServlets to be redirected. The hidden
rewritten URI is displayed in the browser.

To test it, try the following example (any tomcat 8, 8.5 or 9)

add RewriteValve in conf/server.xml


add rewriteRule in conf/Catalina/localhost/rewrite.config
RewriteRule ^/iWantThisVisible/(.*) $/examples/$1/

start tomcat

go to following URLs (any internet browser) :
http://localhost:8080/iWantThisVisible/servlets
http://localhost:8080/iWantThisVisible/servlets/

That behaviour is expected.

If you want to stick with the RewriteValve you'll need to write a custom
Valve or Filter to modify the HTTP headers on the way out.

You might be better off writing a custom Servlet that does a forward.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Issue between RewriteValve and DefaultServlet

[Mark Thomas]

On 26/06/17 10:55, Jérémie Barthés wrote:
> Hi,
> 
> I have an issue between org.apache.catalina.valves.rewrite.RewriteValve
> and org.apache.catalina.servlets.DefaultServlets
> 
> If my request is forwarded by the RewriteValve and then pass into
> doDirectoryRedirect in DefaultServlets to be redirected. The hidden
> rewritten URI is displayed in the browser.
> 
> To test it, try the following example (any tomcat 8, 8.5 or 9)
> 
> add RewriteValve in conf/server.xml
> 
> 
> add rewriteRule in conf/Catalina/localhost/rewrite.config
> RewriteRule ^/iWantThisVisible/(.*) $/examples/$1/
> 
> start tomcat
> 
> go to following URLs (any internet browser) :
> http://localhost:8080/iWantThisVisible/servlets
> http://localhost:8080/iWantThisVisible/servlets/

That behaviour is expected.

If you want to stick with the RewriteValve you'll need to write a custom
Valve or Filter to modify the HTTP headers on the way out.

You might be better off writing a custom Servlet that does a forward.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Issue between RewriteValve and DefaultServlet

[Jérémie Barthés]

Hi,

I have an issue between org.apache.catalina.valves.rewrite.RewriteValve
and org.apache.catalina.servlets.DefaultServlets

If my request is forwarded by the RewriteValve and then pass into
doDirectoryRedirect in DefaultServlets to be redirected. The hidden
rewritten URI is displayed in the browser.

To test it, try the following example (any tomcat 8, 8.5 or 9)

add RewriteValve in conf/server.xml


add rewriteRule in conf/Catalina/localhost/rewrite.config
RewriteRule ^/iWantThisVisible/(.*)$/examples/$1/

start tomcat

go to following URLs (any internet browser) :
http://localhost:8080/iWantThisVisible/servlets
http://localhost:8080/iWantThisVisible/servlets/

Regards

Jeremie

Re: RewriteValve forward or redirect ?

[Jérémie Barthés]

May you please test RewriteValve with any tomcat after version 8 with 
following conditions :


add RewriteValve in conf/server.xml


add rewriteRule in conf/Catalina/localhost/rewrite.config
RewriteRule ^/IWantThisVisible/(.*)$ /examples/$1/

start tomcat

go to following URL (any internet browser) :
http://localhost:8080/IWantThisVisible/servlets
http://localhost:8080/IWantThisVisible/servlets/

Thanks for you help

Jeremie


Le 20/06/2017 à 18:50, Jérémie Barthés a écrit :

RewriteRule ^/visibleURL/(.*)$ /examples/$1/
(missing space between ^/visibleURL/(.*)$ and /examples/$1/)

Le 20/06/2017 à 18:31, Jérémie Barthés a écrit :

please test what i put in my mail :

install a brand new tomcat 9 from archive (last version)

put a RewriteValve in server.xml



in the file /conf/Catalina/localhost/rewrite.config add
RewriteRule ^/visibleURL/(.*)$/examples/$1/

now start tomcat and go to /visibleURL/servlets/
then go to /visibleURL/servlets

you'll see what i'm talking about

Thanks

Jeremie



Le 20/06/2017 à 18:08, Christopher Schultz a écrit :

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jérémie,

On 6/20/17 9:32 AM, Jérémie Barthés wrote:

http://192.168.1.1:8080/visibleURL/servlets/ URL displayed =
http://192.168.1.1:8080/visibleURL/servlets/ page displayed =
http://192.168.1.1:8080/examples/servlets/

http://192.168.1.1:8080/visibleURL/servlets URL displayed =
http://192.168.1.1:8080/examples/servlets/ page displayed =
http://192.168.1.1:8080/examples/servlets/

i don't want http://192.168.1.1:8080/examples/servlets/ to be
displayed !

What do you mean "URL displayed" and "page displayed"? It sounds like
you want the URL to look exactly as it does look.

- -chris


Le 20/06/2017 à 15:26, Jérémie Barthés a écrit :

Hi,

I have some issues with my brand new tomcat 9.0.0.M21

I just unzipped *windows-64 core*

Then i added the *RewriteValve *in *conf/server.xml* / // //  // //
//
//  /

Then i added a rewriteRule in
*/conf/Catalina/localhost/rewrite.config* file : /RewriteRule
^/visibleURL/(.*)$  /examples/$1/

Then i started tomcat with startup.bat (my IP is 192.168.1.1)

in Firefox, i go to
_*http://192.168.1.1:8080/visibleURL/servlets/ *_ The URL
displayed by firefox
is/**//http://192.168.1.1:8080/visibleURL/servlets// and the
page displayed is /http://192.168.1.1:8080/examples/servlets/ /

now i go to *_http://192.168.1.1:8080/visibleURL/servlet__s_ *The
URL displayed by firefox is
/http://192.168.1.1:8080/examples/servlets//**and the page
displayed is /http://192.168.1.1:8080/examples/servlets/ /* *

I really want my users to see "visibleURL" in the URL displayed
by firefox even if they forget to type a "/". I don't want them
to see "examples" Where did i go wrong ?

Please Help

Thanks a lot

Jeremie




-



To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org

For additional commands, e-mail: users-h...@tomcat.apache.org


-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAllJSJQACgkQHPApP6U8
pFhITA/+OeOSADj+aeTCoCZC2q1n8+uzen6pYGNjI22Kk7iZnf529WueXfNaH9U7
6TqF+mfYf5H2gkHQR9Ht+8zDmUzzJsBLK+fKHyBplxU8o1jeC+QmhxC++OgEBVsI
DwEzqHKexGqsqkY2ua37gZm0EVra5HaQbbrPGP2RLqT3JWbx2rMAdEWlsz+mYn81
RBmLWnT3hr4r3xhE799dP/f2IP5uz0akdh68B+4rEnmsMvy3rHfalGt3Jv2yOClr
ompHO+C4ThRdcH8Zn0Y7MOwjvdkAZ1u9DLh84xpz2a33gHJnzz0I+p7cMtbpQVPf
8Z7S+692z4TD2GD0MSedUnNy3ryNvFG8UQZXBJ/pg83ZjmGNHe2orKnqMKgaTGhk
lplXZp1R6wqe2lLdJfyTsK2Lv75/oj+8FbNClfms4blcodmVPKcQq5c23tOx7QBe
RLZpTarNtzWK+3zEgOOSMlkkuuqXvuPNmgkZ7efachk6Lr+gp4nJ9uPbwMrTrVE/
F/ZHhV8nkE2r13fpoi9g2P32VCl9GSqBtJGeOYC4YHHwmmz6SjtT5XbU14XMj28m
lBMyuRmHeP5OsP6yvuaYUa64tMqaUP95/Rhry1Ne7e6R4LRMSqPR7nwKmZxn0kVu
JpCTkf/p9PRmB/S9752JxgwDeKBfcubajRSNI65sXLB5tljhDSE=
=nU9X
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org







-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: RewriteValve forward or redirect ?

[Jérémie Barthés]

RewriteRule ^/visibleURL/(.*)$ /examples/$1/
(missing space between ^/visibleURL/(.*)$ and /examples/$1/)

Le 20/06/2017 à 18:31, Jérémie Barthés a écrit :

please test what i put in my mail :

install a brand new tomcat 9 from archive (last version)

put a RewriteValve in server.xml



in the file /conf/Catalina/localhost/rewrite.config add
RewriteRule ^/visibleURL/(.*)$/examples/$1/

now start tomcat and go to /visibleURL/servlets/
then go to /visibleURL/servlets

you'll see what i'm talking about

Thanks

Jeremie



Le 20/06/2017 à 18:08, Christopher Schultz a écrit :

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jérémie,

On 6/20/17 9:32 AM, Jérémie Barthés wrote:

http://192.168.1.1:8080/visibleURL/servlets/ URL displayed =
http://192.168.1.1:8080/visibleURL/servlets/ page displayed =
http://192.168.1.1:8080/examples/servlets/

http://192.168.1.1:8080/visibleURL/servlets URL displayed =
http://192.168.1.1:8080/examples/servlets/ page displayed =
http://192.168.1.1:8080/examples/servlets/

i don't want http://192.168.1.1:8080/examples/servlets/ to be
displayed !

What do you mean "URL displayed" and "page displayed"? It sounds like
you want the URL to look exactly as it does look.

- -chris


Le 20/06/2017 à 15:26, Jérémie Barthés a écrit :

Hi,

I have some issues with my brand new tomcat 9.0.0.M21

I just unzipped *windows-64 core*

Then i added the *RewriteValve *in *conf/server.xml* / // //  // //
//
//  /

Then i added a rewriteRule in
*/conf/Catalina/localhost/rewrite.config* file : /RewriteRule
^/visibleURL/(.*)$  /examples/$1/

Then i started tomcat with startup.bat (my IP is 192.168.1.1)

in Firefox, i go to
_*http://192.168.1.1:8080/visibleURL/servlets/ *_ The URL
displayed by firefox
is/**//http://192.168.1.1:8080/visibleURL/servlets// and the
page displayed is /http://192.168.1.1:8080/examples/servlets/ /

now i go to *_http://192.168.1.1:8080/visibleURL/servlet__s_ *The
URL displayed by firefox is
/http://192.168.1.1:8080/examples/servlets//**and the page
displayed is /http://192.168.1.1:8080/examples/servlets/ /* *

I really want my users to see "visibleURL" in the URL displayed
by firefox even if they forget to type a "/". I don't want them
to see "examples" Where did i go wrong ?

Please Help

Thanks a lot

Jeremie




-



To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org

For additional commands, e-mail: users-h...@tomcat.apache.org


-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAllJSJQACgkQHPApP6U8
pFhITA/+OeOSADj+aeTCoCZC2q1n8+uzen6pYGNjI22Kk7iZnf529WueXfNaH9U7
6TqF+mfYf5H2gkHQR9Ht+8zDmUzzJsBLK+fKHyBplxU8o1jeC+QmhxC++OgEBVsI
DwEzqHKexGqsqkY2ua37gZm0EVra5HaQbbrPGP2RLqT3JWbx2rMAdEWlsz+mYn81
RBmLWnT3hr4r3xhE799dP/f2IP5uz0akdh68B+4rEnmsMvy3rHfalGt3Jv2yOClr
ompHO+C4ThRdcH8Zn0Y7MOwjvdkAZ1u9DLh84xpz2a33gHJnzz0I+p7cMtbpQVPf
8Z7S+692z4TD2GD0MSedUnNy3ryNvFG8UQZXBJ/pg83ZjmGNHe2orKnqMKgaTGhk
lplXZp1R6wqe2lLdJfyTsK2Lv75/oj+8FbNClfms4blcodmVPKcQq5c23tOx7QBe
RLZpTarNtzWK+3zEgOOSMlkkuuqXvuPNmgkZ7efachk6Lr+gp4nJ9uPbwMrTrVE/
F/ZHhV8nkE2r13fpoi9g2P32VCl9GSqBtJGeOYC4YHHwmmz6SjtT5XbU14XMj28m
lBMyuRmHeP5OsP6yvuaYUa64tMqaUP95/Rhry1Ne7e6R4LRMSqPR7nwKmZxn0kVu
JpCTkf/p9PRmB/S9752JxgwDeKBfcubajRSNI65sXLB5tljhDSE=
=nU9X
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org







-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: RewriteValve forward or redirect ?

[Jérémie Barthés]

please test what i put in my mail :

install a brand new tomcat 9 from archive (last version)

put a RewriteValve in server.xml



in the file /conf/Catalina/localhost/rewrite.config add
RewriteRule ^/visibleURL/(.*)$/examples/$1/

now start tomcat and go to /visibleURL/servlets/
then go to /visibleURL/servlets

you'll see what i'm talking about

Thanks

Jeremie



Le 20/06/2017 à 18:08, Christopher Schultz a écrit :

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jérémie,

On 6/20/17 9:32 AM, Jérémie Barthés wrote:

http://192.168.1.1:8080/visibleURL/servlets/ URL displayed =
http://192.168.1.1:8080/visibleURL/servlets/ page displayed =
http://192.168.1.1:8080/examples/servlets/

http://192.168.1.1:8080/visibleURL/servlets URL displayed =
http://192.168.1.1:8080/examples/servlets/ page displayed =
http://192.168.1.1:8080/examples/servlets/

i don't want http://192.168.1.1:8080/examples/servlets/ to be
displayed !

What do you mean "URL displayed" and "page displayed"? It sounds like
you want the URL to look exactly as it does look.

- -chris


Le 20/06/2017 à 15:26, Jérémie Barthés a écrit :

Hi,

I have some issues with my brand new tomcat 9.0.0.M21

I just unzipped *windows-64 core*

Then i added the *RewriteValve *in *conf/server.xml* /  // //  // //
//
//  /

Then i added a rewriteRule in
*/conf/Catalina/localhost/rewrite.config* file : /RewriteRule
^/visibleURL/(.*)$  /examples/$1/

Then i started tomcat with startup.bat (my IP is 192.168.1.1)

in Firefox, i go to
_*http://192.168.1.1:8080/visibleURL/servlets/ *_ The URL
displayed by firefox
is/**//http://192.168.1.1:8080/visibleURL/servlets// and the
page displayed is /http://192.168.1.1:8080/examples/servlets/ /

now i go to *_http://192.168.1.1:8080/visibleURL/servlet__s_ *The
URL displayed by firefox is
/http://192.168.1.1:8080/examples/servlets//**and the page
displayed is /http://192.168.1.1:8080/examples/servlets/ /* *

I really want my users to see "visibleURL" in the URL displayed
by firefox even if they forget to type a "/". I don't want them
to see "examples" Where did i go wrong ?

Please Help

Thanks a lot

Jeremie




-



To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org

For additional commands, e-mail: users-h...@tomcat.apache.org


-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAllJSJQACgkQHPApP6U8
pFhITA/+OeOSADj+aeTCoCZC2q1n8+uzen6pYGNjI22Kk7iZnf529WueXfNaH9U7
6TqF+mfYf5H2gkHQR9Ht+8zDmUzzJsBLK+fKHyBplxU8o1jeC+QmhxC++OgEBVsI
DwEzqHKexGqsqkY2ua37gZm0EVra5HaQbbrPGP2RLqT3JWbx2rMAdEWlsz+mYn81
RBmLWnT3hr4r3xhE799dP/f2IP5uz0akdh68B+4rEnmsMvy3rHfalGt3Jv2yOClr
ompHO+C4ThRdcH8Zn0Y7MOwjvdkAZ1u9DLh84xpz2a33gHJnzz0I+p7cMtbpQVPf
8Z7S+692z4TD2GD0MSedUnNy3ryNvFG8UQZXBJ/pg83ZjmGNHe2orKnqMKgaTGhk
lplXZp1R6wqe2lLdJfyTsK2Lv75/oj+8FbNClfms4blcodmVPKcQq5c23tOx7QBe
RLZpTarNtzWK+3zEgOOSMlkkuuqXvuPNmgkZ7efachk6Lr+gp4nJ9uPbwMrTrVE/
F/ZHhV8nkE2r13fpoi9g2P32VCl9GSqBtJGeOYC4YHHwmmz6SjtT5XbU14XMj28m
lBMyuRmHeP5OsP6yvuaYUa64tMqaUP95/Rhry1Ne7e6R4LRMSqPR7nwKmZxn0kVu
JpCTkf/p9PRmB/S9752JxgwDeKBfcubajRSNI65sXLB5tljhDSE=
=nU9X
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: RewriteValve forward or redirect ?

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jérémie,

On 6/20/17 9:32 AM, Jérémie Barthés wrote:
> http://192.168.1.1:8080/visibleURL/servlets/ URL displayed =
> http://192.168.1.1:8080/visibleURL/servlets/ page displayed =
> http://192.168.1.1:8080/examples/servlets/
> 
> http://192.168.1.1:8080/visibleURL/servlets URL displayed =
> http://192.168.1.1:8080/examples/servlets/ page displayed =
> http://192.168.1.1:8080/examples/servlets/
> 
> i don't want http://192.168.1.1:8080/examples/servlets/ to be
> displayed !

What do you mean "URL displayed" and "page displayed"? It sounds like
you want the URL to look exactly as it does look.

- -chris

> Le 20/06/2017 à 15:26, Jérémie Barthés a écrit :
>> Hi,
>> 
>> I have some issues with my brand new tomcat 9.0.0.M21
>> 
>> I just unzipped *windows-64 core*
>> 
>> Then i added the *RewriteValve *in *conf/server.xml* /  > name="localhost" appBase="webapps" unpackWARs="true" 
>> autoDeploy="true">// //  // //
>> > className="org.apache.catalina.valves.rewrite.RewriteValve"/>// 
>> //  /
>> 
>> Then i added a rewriteRule in 
>> */conf/Catalina/localhost/rewrite.config* file : /RewriteRule
>> ^/visibleURL/(.*)$  /examples/$1/
>> 
>> Then i started tomcat with startup.bat (my IP is 192.168.1.1)
>> 
>> in Firefox, i go to
>> _*http://192.168.1.1:8080/visibleURL/servlets/ *_ The URL
>> displayed by firefox 
>> is/**//http://192.168.1.1:8080/visibleURL/servlets// and the
>> page displayed is /http://192.168.1.1:8080/examples/servlets/ /
>> 
>> now i go to *_http://192.168.1.1:8080/visibleURL/servlet__s_ *The
>> URL displayed by firefox is 
>> /http://192.168.1.1:8080/examples/servlets//**and the page
>> displayed is /http://192.168.1.1:8080/examples/servlets/ /* *
>> 
>> I really want my users to see "visibleURL" in the URL displayed
>> by firefox even if they forget to type a "/". I don't want them
>> to see "examples" Where did i go wrong ?
>> 
>> Please Help
>> 
>> Thanks a lot
>> 
>> Jeremie
>> 
>> 
> 
> 
> -
>
> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAllJSJQACgkQHPApP6U8
pFhITA/+OeOSADj+aeTCoCZC2q1n8+uzen6pYGNjI22Kk7iZnf529WueXfNaH9U7
6TqF+mfYf5H2gkHQR9Ht+8zDmUzzJsBLK+fKHyBplxU8o1jeC+QmhxC++OgEBVsI
DwEzqHKexGqsqkY2ua37gZm0EVra5HaQbbrPGP2RLqT3JWbx2rMAdEWlsz+mYn81
RBmLWnT3hr4r3xhE799dP/f2IP5uz0akdh68B+4rEnmsMvy3rHfalGt3Jv2yOClr
ompHO+C4ThRdcH8Zn0Y7MOwjvdkAZ1u9DLh84xpz2a33gHJnzz0I+p7cMtbpQVPf
8Z7S+692z4TD2GD0MSedUnNy3ryNvFG8UQZXBJ/pg83ZjmGNHe2orKnqMKgaTGhk
lplXZp1R6wqe2lLdJfyTsK2Lv75/oj+8FbNClfms4blcodmVPKcQq5c23tOx7QBe
RLZpTarNtzWK+3zEgOOSMlkkuuqXvuPNmgkZ7efachk6Lr+gp4nJ9uPbwMrTrVE/
F/ZHhV8nkE2r13fpoi9g2P32VCl9GSqBtJGeOYC4YHHwmmz6SjtT5XbU14XMj28m
lBMyuRmHeP5OsP6yvuaYUa64tMqaUP95/Rhry1Ne7e6R4LRMSqPR7nwKmZxn0kVu
JpCTkf/p9PRmB/S9752JxgwDeKBfcubajRSNI65sXLB5tljhDSE=
=nU9X
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: RewriteValve forward or redirect ?

[Jérémie Barthés]

http://192.168.1.1:8080/visibleURL/servlets/
URL displayed = http://192.168.1.1:8080/visibleURL/servlets/
page displayed = http://192.168.1.1:8080/examples/servlets/

http://192.168.1.1:8080/visibleURL/servlets
URL displayed = http://192.168.1.1:8080/examples/servlets/
page displayed = http://192.168.1.1:8080/examples/servlets/

i don't want http://192.168.1.1:8080/examples/servlets/ to be displayed !

Le 20/06/2017 à 15:26, Jérémie Barthés a écrit :

Hi,

I have some issues with my brand new tomcat 9.0.0.M21

I just unzipped *windows-64 core*

Then i added the *RewriteValve *in *conf/server.xml*
/  autoDeploy="true">//

//  //
//className="org.apache.catalina.valves.rewrite.RewriteValve"/>//

//  /

Then i added a rewriteRule in 
*/conf/Catalina/localhost/rewrite.config* file :

/RewriteRule ^/visibleURL/(.*)$  /examples/$1/

Then i started tomcat with startup.bat (my IP is 192.168.1.1)

in Firefox, i go to _*http://192.168.1.1:8080/visibleURL/servlets/ *_
The URL displayed by firefox 
is/**//http://192.168.1.1:8080/visibleURL/servlets// and the page 
displayed is /http://192.168.1.1:8080/examples/servlets/ /


now i go to *_http://192.168.1.1:8080/visibleURL/servlet__s_
*The URL displayed by firefox is 
/http://192.168.1.1:8080/examples/servlets//**and the page displayed 
is /http://192.168.1.1:8080/examples/servlets/ /*

*

I really want my users to see "visibleURL" in the URL displayed by 
firefox even if they forget to type a "/". I don't want them to see 
"examples"

Where did i go wrong ?

Please Help

Thanks a lot

Jeremie





-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RewriteValve forward or redirect ?

[Jérémie Barthés]

Hi,

I have some issues with my brand new tomcat 9.0.0.M21

I just unzipped *windows-64 core*

Then i added the *RewriteValve *in *conf/server.xml*
/  autoDeploy="true">//

//  //
//className="org.apache.catalina.valves.rewrite.RewriteValve"/>//

//  /

Then i added a rewriteRule in */conf/Catalina/localhost/rewrite.config* 
file :

/RewriteRule ^/visibleURL/(.*)$  /examples/$1/

Then i started tomcat with startup.bat (my IP is 192.168.1.1)

in Firefox, i go to _*http://192.168.1.1:8080/visibleURL/servlets/ *_
The URL displayed by firefox 
is/**//http://192.168.1.1:8080/visibleURL/servlets// and the page 
displayed is /http://192.168.1.1:8080/examples/servlets/ /


now i go to *_http://192.168.1.1:8080/visibleURL/servlet__s_
*The URL displayed by firefox is 
/http://192.168.1.1:8080/examples/servlets//**and the page displayed is 
/http://192.168.1.1:8080/examples/servlets/ /*

*

I really want my users to see "visibleURL" in the URL displayed by 
firefox even if they forget to type a "/". I don't want them to see 
"examples"

Where did i go wrong ?

Please Help

Thanks a lot

Jeremie

RewriteValve escaping $ to %24

[Sunil Shah]

Hi,

I've been struggling with this bug for a little while now and was hoping
you might provide some insight.

We're running Jenkins inside Tomcat and using the RewriteValve to rewrite
incoming URLs on / to /service/jenkins/.

We notice that for requests for /$stapler/render..., the $ is escaped to
%24 to give us /%24stapler/render Jenkins isn't able to parse the
escaped URL and returns a 404 error.

Here
<https://github.com/mesosphere/jenkins-mesos/commit/5f68dafeef61f0ba68461e705b18812815f13087>
is our rewrite.config plus related files. So far I've tried:
- Adding the *NE* flag to the RewriteRule
- Creating a custom RewriteMap

Both approaches have been unsuccessful.

Any suggestions would be greatly appreciated!

Cheers,

Sunil

Re: Issue with RewriteValve and folders (tomcat 8.0.15)

[Jérémie Barthés]

Hi,

I send you the patch from 8.0.15
Tell me if it doesn't match with what you expected
Kind regards,

Jérémie


Index: RewriteValve.java
===
--- RewriteValve.java(revision 1661627)
+++ RewriteValve.java(working copy)
@@ -45,6 +45,11 @@
 import org.apache.catalina.connector.Response;
 import org.apache.catalina.util.LifecycleSupport;
 import org.apache.catalina.valves.ValveBase;
+import org.apache.catalina.valves.rewrite.Resolver;
+import org.apache.catalina.valves.rewrite.ResolverImpl;
+import org.apache.catalina.valves.rewrite.RewriteCond;
+import org.apache.catalina.valves.rewrite.RewriteMap;
+import org.apache.catalina.valves.rewrite.RewriteRule;
 import org.apache.tomcat.util.buf.CharChunk;
 import org.apache.tomcat.util.buf.MessageBytes;
 import org.apache.tomcat.util.net.URL;
@@ -472,11 +477,31 @@
 chunk.append(host.toString());
request.getCoyoteRequest().serverName().toChars();
 }
+
+boolean folderRedirect = false;
+try{
+request.getMappingData().recycle();
+ 
request.getConnector().getService().getMapper().map(request.getCoyoteRequest().serverName(), 
request.getCoyoteRequest().requestURI(),

+null, request.getMappingData());
+ if(request.getMappingData().redirectPath.toString()!=null){
+folderRedirect = true;
+}
+} catch (Exception e){
+//ignore
+}
+
 request.getMappingData().recycle();
 // Reinvoke the whole request recursively
 try {
request.getConnector().getProtocolHandler().getAdapter().service
 (request.getCoyoteRequest(), 
response.getCoyoteResponse());

+
+if(folderRedirect && 
response.getCoyoteResponse().getStatus() == 302){
+ 
if(!request.getCoyoteRequest().requestURI().getByteChunk().toString().endsWith("/")){
+String requestParam = 
request.getQueryString() == null ? "" : '?' + request.getQueryString();
+response.setHeader("Location", 
request.getCoyoteRequest().requestURI().getByteChunk().toString() + '/' 
+ requestParam);

+}
+}
 } catch (Exception e) {
 // This doesn't actually happen in the 
Catalina adapter implementation

 }



Le 20/02/2015 18:03, Konstantin Kolinko a écrit :

2015-02-20 19:41 GMT+03:00 Christopher Schultz :

Jérémie,

On 2/20/15 4:48 AM, Jérémie Barthés wrote:

"instead of just a snippet of "fixed" code"

Sorry Chris,i didn't read this.

How do you want me to provide the patch ?

Presumably, you have a copy of the source code. If you checked-out
from svn, just do this:

/path/to/tomcat-8.0.15 $ svn diff > patch.file

and post the patch file.

If you just downloaded the source in e.g. ZIP, tarball, etc., re-fetch
a pristine copy of the file and then do:

/path/to/tomcat-8.0.15 $ diff path/to/original/RewriteValve.java \
java/org/apache/catalina/valves/rewrite/RewriteValve.java \
> patch.file

The above command shall use "diff -u" to generate Unified Diff format.

Documentation:
http://tomcat.apache.org/bugreport.html#How_to_submit_patches_and_enhancement_requests

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Index: RewriteValve.java
===
--- RewriteValve.java   (revision 1661627)
+++ RewriteValve.java   (working copy)
@@ -45,6 +45,11 @@
 import org.apache.catalina.connector.Response;
 import org.apache.catalina.util.LifecycleSupport;
 import org.apache.catalina.valves.ValveBase;
+import org.apache.catalina.valves.rewrite.Resolver;
+import org.apache.catalina.valves.rewrite.ResolverImpl;
+import org.apache.catalina.valves.rewrite.RewriteCond;
+import org.apache.catalina.valves.rewrite.RewriteMap;
+import org.apache.catalina.valves.rewrite.RewriteRule;
 import org.apache.tomcat.util.buf.CharChunk;
 import org.apache.tomcat.util.buf.MessageBytes;
 import org.apache.tomcat.util.net.URL;
@@ -472,11 +477,31 @@
 chunk.append(host.toString());
 request.getCoyoteRequest().serverName().toChars();
 }
+
+boolean folderRedirect = false;
+try{
+   request.getMappingData().recycle();
+   
request.getConnector().getService().getMapper().map(request.getCoyoteRequest().serverName(),
 request.getCoyoteRequest().requestURI(),
+

Re: Issue with RewriteValve and folders (tomcat 8.0.15)

[Konstantin Kolinko]

2015-02-20 19:41 GMT+03:00 Christopher Schultz :
>
> Jérémie,
>
> On 2/20/15 4:48 AM, Jérémie Barthés wrote:
>> "instead of just a snippet of "fixed" code"
>>
>> Sorry Chris,i didn't read this.
>>
>> How do you want me to provide the patch ?
>
> Presumably, you have a copy of the source code. If you checked-out
> from svn, just do this:
>
> /path/to/tomcat-8.0.15 $ svn diff > patch.file
>
> and post the patch file.
>
> If you just downloaded the source in e.g. ZIP, tarball, etc., re-fetch
> a pristine copy of the file and then do:
>
> /path/to/tomcat-8.0.15 $ diff path/to/original/RewriteValve.java \
>java/org/apache/catalina/valves/rewrite/RewriteValve.java \
>> patch.file

The above command shall use "diff -u" to generate Unified Diff format.

Documentation:
http://tomcat.apache.org/bugreport.html#How_to_submit_patches_and_enhancement_requests

Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Issue with RewriteValve and folders (tomcat 8.0.15)

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jérémie,

On 2/20/15 4:48 AM, Jérémie Barthés wrote:
> "instead of just a snippet of "fixed" code"
> 
> Sorry Chris,i didn't read this.
> 
> How do you want me to provide the patch ?

Presumably, you have a copy of the source code. If you checked-out
from svn, just do this:

/path/to/tomcat-8.0.15 $ svn diff > patch.file

and post the patch file.

If you just downloaded the source in e.g. ZIP, tarball, etc., re-fetch
a pristine copy of the file and then do:

/path/to/tomcat-8.0.15 $ diff path/to/original/RewriteValve.java \
   java/org/apache/catalina/valves/rewrite/RewriteValve.java \
   > patch.file

- -chris

> Le 20/02/2015 10:31, Jérémie Barthés a écrit :
>> I send you the patch i did to fix my issue with the RewriteValve
>> (it was for the 8.0.15), The goal of that patch is to block the
>> RewriteValve if a 302 automatic folder '/' redirection occurs.
>> The RewriteValve will rewrite the redirected URL.
>> 
>> first step : http://localhost:8080/mypath/async => rewritten to 
>> http://localhost:8080/examples/jsp/async, 302 redirection
>> occurs, rollback and redirect to
>> http://localhost:8080/mypath/async/ second step : now the server
>> receive http://localhost:8080/mypath/async/ => forward to
>> http://localhost:8080/examples/jsp/async/ mission complete
>> 
>> The patch may be a little bit dirty since it the first time i add
>> code into tomcat and i don't understand all of this.
>> 
>> It starts at the line 481 of the RewriteValve.java
>> 
>> //boolean to know if the rewritten resource is a folder and need
>> a redirection boolean folderRedirect = false; try{ 
>> request.getMappingData().recycle(); 
>> request.getConnector().getService().getMapper().map(request.getCoyoteRequest().serverName(),
>>
>> 
request.getCoyoteRequest().requestURI(),
>> null, request.getMappingData()); 
>> if(request.getMappingData().redirectPath.toString()!=null){ 
>> folderRedirect = true; } } catch (Exception e){ //ignore }
>> 
>> request.getMappingData().recycle(); // Reinvoke the whole request
>> recursively try { 
>> request.getConnector().getProtocolHandler().getAdapter().service 
>> (request.getCoyoteRequest(), response.getCoyoteResponse());
>> 
>> if(folderRedirect && response.getCoyoteResponse().getStatus() ==
>> 302){ 
>> if(!request.getCoyoteRequest().requestURI().getByteChunk().toString().endsWith("/")){
>>
>>
>> 
String requestParam =
>> request.getQueryString() == null ? "" : '?' +
>> request.getQueryString(); response.setHeader("Location", 
>> request.getCoyoteRequest().requestURI().getByteChunk().toString()
>> + '/' + requestParam); } } } catch (Exception e) { // This
>> doesn't actually happen in the Catalina adapter implementation }
>> 
>> 
>> Le 20/02/2015 09:34, Felix Schumacher a écrit :
>>> Am 20.02.2015 08:49, schrieb Rainer Jung:
>>>> Am 19.02.2015 um 22:13 schrieb Felix Schumacher:
>>>>> Am 19.02.2015 um 21:41 schrieb André Warnier:
>>>>>> Jérémie Barthés wrote: ...
>>>>>> 
>>>>>>> 
>>>>>>> Make a file rewrite.config in conf/Catalina/localhost/
>>>>>>> that contains : RewriteRule^/mypath/(.*)$
>>>>>>> /examples/jsp/$1
>>>>>>> 
>>>>>>> copy the line >>>>>> className="org.apache.catalina.valves.rewrite.RewriteValve"
>>>>>>> /> in the conf/server.xml file, line 131
>>>>>>> 
>>>>>> 
>>>>>> Since this is a Valve, it will run before Tomcat attempts
>>>>>> to match the URL to an actual directory or webapp.
>>>>>> 
>>>>>>> 
>>>>>>> try the followings URLs :
>>>>>>> 
>>>>>> 
>>>>>> 1) http://localhost:8080/mypath/async
>>>>>> 
>>>>>> This matches the rewrite rule, so it will be rewritten to
>>>>>> URL
>>>>>> 
>>>>>> /examples/jsp/async
>>>>>> 
>>>>>> Then Tomcat will attempt to match this to a directory or
>>>>>> webapp, and find that
>>>>>> (catalina_base)/webapps/examples/jsp/async is a
>>>>>> directory. It will thus respond to the browser with a 302
>>>>>> re-direct to
>>>>>> 
>>&

Re: Issue with RewriteValve and folders (tomcat 8.0.15)

[Jérémie Barthés]

Le 20/02/2015 11:22, Rémy Maucherat a écrit :

2015-02-20 10:31 GMT+01:00 Jérémie Barthés :


I send you the patch i did to fix my issue with the RewriteValve (it was
for the 8.0.15),
The goal of that patch is to block the RewriteValve if a 302 automatic
folder '/' redirection occurs. The RewriteValve will rewrite the redirected
URL.


I think the current behavior is 100% correct, so no patch should be
integrated to "fix" this IMO. The redirection could be useful to avoid
relative paths issues.

Rémy



Weird way to think code. My function ramdomly redirect or forward is 
100% correct behavior troll. I had to spend many days of work to find why
http://localhost:8080/mypath/async => 
http://localhost:8080/examples/jsp/async/

http://localhost:8080/mypath/async/ => http://localhost:8080/mypath/async/
And always think that users will consider first it fails because they 
didn't did configure well rewrite.config or made mistakes in server.xml 
or any else. Not because there's a 100% correct behavior conflict 
between RewriteValve and coyote's Adapter mapper redirection if some of 
your resources are folders.







-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Issue with RewriteValve and folders (tomcat 8.0.15)

[Rémy Maucherat]

2015-02-20 10:31 GMT+01:00 Jérémie Barthés :

> I send you the patch i did to fix my issue with the RewriteValve (it was
> for the 8.0.15),
> The goal of that patch is to block the RewriteValve if a 302 automatic
> folder '/' redirection occurs. The RewriteValve will rewrite the redirected
> URL.
>

I think the current behavior is 100% correct, so no patch should be
integrated to "fix" this IMO. The redirection could be useful to avoid
relative paths issues.

Rémy

Re: Issue with RewriteValve and folders (tomcat 8.0.15)

[Jérémie Barthés]

"instead of just a snippet of "fixed" code"

Sorry Chris,i didn't read this.

How do you want me to provide the patch ?

Jérémie

Le 20/02/2015 10:31, Jérémie Barthés a écrit :
I send you the patch i did to fix my issue with the RewriteValve (it 
was for the 8.0.15),
The goal of that patch is to block the RewriteValve if a 302 automatic 
folder '/' redirection occurs. The RewriteValve will rewrite the 
redirected URL.


first step :
http://localhost:8080/mypath/async => rewritten to 
http://localhost:8080/examples/jsp/async, 302 redirection occurs, 
rollback and redirect to http://localhost:8080/mypath/async/

second step :
now the server receive http://localhost:8080/mypath/async/ => forward 
to http://localhost:8080/examples/jsp/async/

mission complete

The patch may be a little bit dirty since it the first time i add code 
into tomcat and i don't understand all of this.


It starts at the line 481 of the RewriteValve.java

//boolean to know if the rewritten resource is a 
folder and need a redirection

boolean folderRedirect = false;
try{
request.getMappingData().recycle();
request.getConnector().getService().getMapper().map(request.getCoyoteRequest().serverName(), 
request.getCoyoteRequest().requestURI(),

null, request.getMappingData());
if(request.getMappingData().redirectPath.toString()!=null){
folderRedirect = true;
}
} catch (Exception e){
//ignore
}

request.getMappingData().recycle();
// Reinvoke the whole request recursively
try {
request.getConnector().getProtocolHandler().getAdapter().service
(request.getCoyoteRequest(), 
response.getCoyoteResponse());


if(folderRedirect && 
response.getCoyoteResponse().getStatus() == 302){
if(!request.getCoyoteRequest().requestURI().getByteChunk().toString().endsWith("/")){ 

String requestParam = 
request.getQueryString() == null ? "" : '?' + request.getQueryString();
response.setHeader("Location", 
request.getCoyoteRequest().requestURI().getByteChunk().toString() + 
'/' + requestParam);

}
}
} catch (Exception e) {
// This doesn't actually happen in the 
Catalina adapter implementation

}


Le 20/02/2015 09:34, Felix Schumacher a écrit :

Am 20.02.2015 08:49, schrieb Rainer Jung:

Am 19.02.2015 um 22:13 schrieb Felix Schumacher:

Am 19.02.2015 um 21:41 schrieb André Warnier:

Jérémie Barthés wrote:
...



Make a file rewrite.config in conf/Catalina/localhost/ that 
contains :

RewriteRule^/mypath/(.*)$/examples/jsp/$1

copy the line

in the conf/server.xml file, line 131



Since this is a Valve, it will run before Tomcat attempts to match 
the

URL to an actual directory or webapp.



try the followings URLs :



1) http://localhost:8080/mypath/async

This matches the rewrite rule, so it will be rewritten to URL

  /examples/jsp/async

Then Tomcat will attempt to match this to a directory or webapp, and
find that (catalina_base)/webapps/examples/jsp/async is a directory.
It will thus respond to the browser with a 302 re-direct to

   http://localhost:8080/examples/jsp/async/

which is actually the "correct" URL.
And this is what will be shown in the browser URL bar. This, in my
view, is expected behaviour.  The server does that, so that when an
actual response is generated (for the correct URL
http://localhost:8080/examples/jsp/async/), the browser can cache 
this

response under the correct URL.

Then the browser re-issues a request for

   http://localhost:8080/examples/jsp/async/

and that is when Tomcat will actually generate a "real" response,
because this time it is a correct URL. So the response appears to the
browser, as coming from

   http://localhost:8080/examples/jsp/async/

which is correct.

2) http://localhost:8080/mypath/async/

This also matches the rewrite rule, so it gets rewritten to

http://localhost:8080/examples/jsp/async/

which is a correct URL.
Thus Tomcat will immediately generate a real response (without an
intermediate 302 redirect), which will be appear in the browser URL
bar as a response to

http://localhost:8080/mypath/async/

This is also expected behaviour.

I believe that if you do not want to see the first redirect URL

   http://localhost:8080/examples/jsp/async/

in the browser, you have to modify your rewrite rules, perhaps by
using a RewriteCond with the -d flag, to check first if the URL 
points

to an existing directory, and if yes add the terminating &quo

Re: Issue with RewriteValve and folders (tomcat 8.0.15)

[Jérémie Barthés]

I send you the patch i did to fix my issue with the RewriteValve (it was 
for the 8.0.15),
The goal of that patch is to block the RewriteValve if a 302 automatic 
folder '/' redirection occurs. The RewriteValve will rewrite the 
redirected URL.


first step :
http://localhost:8080/mypath/async => rewritten to 
http://localhost:8080/examples/jsp/async, 302 redirection occurs, 
rollback and redirect to http://localhost:8080/mypath/async/

second step :
now the server receive http://localhost:8080/mypath/async/ => forward to 
http://localhost:8080/examples/jsp/async/

mission complete

The patch may be a little bit dirty since it the first time i add code 
into tomcat and i don't understand all of this.


It starts at the line 481 of the RewriteValve.java

//boolean to know if the rewritten resource is a 
folder and need a redirection

boolean folderRedirect = false;
try{
request.getMappingData().recycle();
request.getConnector().getService().getMapper().map(request.getCoyoteRequest().serverName(), 
request.getCoyoteRequest().requestURI(),

null, request.getMappingData());
if(request.getMappingData().redirectPath.toString()!=null){
folderRedirect = true;
}
} catch (Exception e){
//ignore
}

request.getMappingData().recycle();
// Reinvoke the whole request recursively
try {
request.getConnector().getProtocolHandler().getAdapter().service
(request.getCoyoteRequest(), 
response.getCoyoteResponse());


if(folderRedirect && 
response.getCoyoteResponse().getStatus() == 302){

if(!request.getCoyoteRequest().requestURI().getByteChunk().toString().endsWith("/")){
String requestParam = 
request.getQueryString() == null ? "" : '?' + request.getQueryString();
response.setHeader("Location", 
request.getCoyoteRequest().requestURI().getByteChunk().toString() + '/' 
+ requestParam);

}
}
} catch (Exception e) {
// This doesn't actually happen in the Catalina 
adapter implementation

}


Le 20/02/2015 09:34, Felix Schumacher a écrit :

Am 20.02.2015 08:49, schrieb Rainer Jung:

Am 19.02.2015 um 22:13 schrieb Felix Schumacher:

Am 19.02.2015 um 21:41 schrieb André Warnier:

Jérémie Barthés wrote:
...



Make a file rewrite.config in conf/Catalina/localhost/ that 
contains :

RewriteRule^/mypath/(.*)$/examples/jsp/$1

copy the line

in the conf/server.xml file, line 131



Since this is a Valve, it will run before Tomcat attempts to match the
URL to an actual directory or webapp.



try the followings URLs :



1) http://localhost:8080/mypath/async

This matches the rewrite rule, so it will be rewritten to URL

  /examples/jsp/async

Then Tomcat will attempt to match this to a directory or webapp, and
find that (catalina_base)/webapps/examples/jsp/async is a directory.
It will thus respond to the browser with a 302 re-direct to

   http://localhost:8080/examples/jsp/async/

which is actually the "correct" URL.
And this is what will be shown in the browser URL bar. This, in my
view, is expected behaviour.  The server does that, so that when an
actual response is generated (for the correct URL
http://localhost:8080/examples/jsp/async/), the browser can cache this
response under the correct URL.

Then the browser re-issues a request for

   http://localhost:8080/examples/jsp/async/

and that is when Tomcat will actually generate a "real" response,
because this time it is a correct URL. So the response appears to the
browser, as coming from

   http://localhost:8080/examples/jsp/async/

which is correct.

2) http://localhost:8080/mypath/async/

This also matches the rewrite rule, so it gets rewritten to

http://localhost:8080/examples/jsp/async/

which is a correct URL.
Thus Tomcat will immediately generate a real response (without an
intermediate 302 redirect), which will be appear in the browser URL
bar as a response to

http://localhost:8080/mypath/async/

This is also expected behaviour.

I believe that if you do not want to see the first redirect URL

   http://localhost:8080/examples/jsp/async/

in the browser, you have to modify your rewrite rules, perhaps by
using a RewriteCond with the -d flag, to check first if the URL points
to an existing directory, and if yes add the terminating "/" yourself
(with a RewriteRule) before other rewrite tests/rules take place.

This rewrite.config


...


will do the trick. I think -d will not work, since /mypath/async is not
existant, it only "

Re: Issue with RewriteValve and folders (tomcat 8.0.15)

[Felix Schumacher]

Am 20.02.2015 08:49, schrieb Rainer Jung:

Am 19.02.2015 um 22:13 schrieb Felix Schumacher:

Am 19.02.2015 um 21:41 schrieb André Warnier:

Jérémie Barthés wrote:
...



Make a file rewrite.config in conf/Catalina/localhost/ that contains 
:

RewriteRule^/mypath/(.*)$/examples/jsp/$1

copy the line

in the conf/server.xml file, line 131



Since this is a Valve, it will run before Tomcat attempts to match 
the

URL to an actual directory or webapp.



try the followings URLs :



1) http://localhost:8080/mypath/async

This matches the rewrite rule, so it will be rewritten to URL

  /examples/jsp/async

Then Tomcat will attempt to match this to a directory or webapp, and
find that (catalina_base)/webapps/examples/jsp/async is a directory.
It will thus respond to the browser with a 302 re-direct to

   http://localhost:8080/examples/jsp/async/

which is actually the "correct" URL.
And this is what will be shown in the browser URL bar.  This, in my
view, is expected behaviour.  The server does that, so that when an
actual response is generated (for the correct URL
http://localhost:8080/examples/jsp/async/), the browser can cache 
this

response under the correct URL.

Then the browser re-issues a request for

   http://localhost:8080/examples/jsp/async/

and that is when Tomcat will actually generate a "real" response,
because this time it is a correct URL. So the response appears to the
browser, as coming from

   http://localhost:8080/examples/jsp/async/

which is correct.

2) http://localhost:8080/mypath/async/

This also matches the rewrite rule, so it gets rewritten to

http://localhost:8080/examples/jsp/async/

which is a correct URL.
Thus Tomcat will immediately generate a real response (without an
intermediate 302 redirect), which will be appear in the browser URL
bar as a response to

http://localhost:8080/mypath/async/

This is also expected behaviour.

I believe that if you do not want to see the first redirect URL

   http://localhost:8080/examples/jsp/async/

in the browser, you have to modify your rewrite rules, perhaps by
using a RewriteCond with the -d flag, to check first if the URL 
points

to an existing directory, and if yes add the terminating "/" yourself
(with a RewriteRule) before other rewrite tests/rules take place.

This rewrite.config


...

will do the trick. I think -d will not work, since /mypath/async is 
not

existant, it only "feels" like a directory.


Not clear: the implementation for "-d" is (case 0 below, from file
ResolverImpl.java):

148 @Override
149 public boolean resolveResource(int type, String name) {
150 WebResourceRoot resources = 
request.getContext().getResources();

151 WebResource resource = resources.getResource(name);
152 if (!resource.exists()) {
153 return false;
154 } else {
155 switch (type) {
156 case 0:
157 return (resource.isDirectory());
158 case 1:
159 return (resource.isFile());
160 case 2:
161 return (resource.isFile() &&
resource.getContentLength() > 0);
162 default:
163 return false;
164 }
165 }
166 }

Since it checks resources and the OP was actually talking about a path
that is a folder in his webapp, "-d" could work.


Right, but given the examples and instructions from the op, it seems to 
me, that async (source) is not a directory.


I think the op wants to mimic [P] behaviour, which is not implemented 
and wants to point out that
the valve behaves differently when operating on a directory like url and 
one that is not. In the
former it will do an internal forward in the latter an external 
redirect.


As proxy mode is not supported and documented, I tend to say, that it is 
a mildly annoying

inconsitency, but not a bug per se.

Regards
 Felix



Regards,

Rainer

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Issue with RewriteValve and folders (tomcat 8.0.15)

[Rainer Jung]

Am 19.02.2015 um 22:13 schrieb Felix Schumacher:

Am 19.02.2015 um 21:41 schrieb André Warnier:

Jérémie Barthés wrote:
...



Make a file rewrite.config in conf/Catalina/localhost/ that contains :
RewriteRule^/mypath/(.*)$/examples/jsp/$1

copy the line

in the conf/server.xml file, line 131



Since this is a Valve, it will run before Tomcat attempts to match the
URL to an actual directory or webapp.



try the followings URLs :



1) http://localhost:8080/mypath/async

This matches the rewrite rule, so it will be rewritten to URL

  /examples/jsp/async

Then Tomcat will attempt to match this to a directory or webapp, and
find that (catalina_base)/webapps/examples/jsp/async is a directory.
It will thus respond to the browser with a 302 re-direct to

   http://localhost:8080/examples/jsp/async/

which is actually the "correct" URL.
And this is what will be shown in the browser URL bar.  This, in my
view, is expected behaviour.  The server does that, so that when an
actual response is generated (for the correct URL
http://localhost:8080/examples/jsp/async/), the browser can cache this
response under the correct URL.

Then the browser re-issues a request for

   http://localhost:8080/examples/jsp/async/

and that is when Tomcat will actually generate a "real" response,
because this time it is a correct URL. So the response appears to the
browser, as coming from

   http://localhost:8080/examples/jsp/async/

which is correct.

2) http://localhost:8080/mypath/async/

This also matches the rewrite rule, so it gets rewritten to

http://localhost:8080/examples/jsp/async/

which is a correct URL.
Thus Tomcat will immediately generate a real response (without an
intermediate 302 redirect), which will be appear in the browser URL
bar as a response to

http://localhost:8080/mypath/async/

This is also expected behaviour.

I believe that if you do not want to see the first redirect URL

   http://localhost:8080/examples/jsp/async/

in the browser, you have to modify your rewrite rules, perhaps by
using a RewriteCond with the -d flag, to check first if the URL points
to an existing directory, and if yes add the terminating "/" yourself
(with a RewriteRule) before other rewrite tests/rules take place.

This rewrite.config


...


will do the trick. I think -d will not work, since /mypath/async is not
existant, it only "feels" like a directory.


Not clear: the implementation for "-d" is (case 0 below, from file 
ResolverImpl.java):


148 @Override
149 public boolean resolveResource(int type, String name) {
150 WebResourceRoot resources = request.getContext().getResources();
151 WebResource resource = resources.getResource(name);
152 if (!resource.exists()) {
153 return false;
154 } else {
155 switch (type) {
156 case 0:
157 return (resource.isDirectory());
158 case 1:
159 return (resource.isFile());
160 case 2:
161 return (resource.isFile() && 
resource.getContentLength() > 0);

162 default:
163 return false;
164 }
165 }
166 }

Since it checks resources and the OP was actually talking about a path 
that is a folder in his webapp, "-d" could work.


Regards,

Rainer

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Issue with RewriteValve and folders (tomcat 8.0.15)

[Felix Schumacher]

Am 20. Februar 2015 00:43:40 MEZ, schrieb "André Warnier" :
>André Warnier wrote:
>> Felix Schumacher wrote:
>>> Am 19.02.2015 um 21:41 schrieb André Warnier:
 Jérémie Barthés wrote:
 ...
>...
>

 in the browser, you have to modify your rewrite rules, perhaps by 
 using a RewriteCond with the -d flag, to check first if the URL 
 points to an existing directory, and if yes add the terminating "/"
>
 yourself (with a RewriteRule) before other rewrite tests/rules take
>
 place.
>>> This rewrite.config
>>>
>>> # if path doesn't end with a slash redirect it to an url with  an 
>>> ending slash
>>> RewriteCond%{REQUEST_URI} !^.*/$
>>> RewriteRule^/mypath/(.*)$/mypath/$1/ [R]
>>>
>>> # every path ending on a slash forward to /examples/...
>>> RewriteRule^/mypath/(.*/)$/examples/jsp/$1
>>>
>>> will do the trick. I think -d will not work, since /mypath/async is 
>>> not existant, it only "feels" like a directory.
>> 
>> Aaah yes, correct.  Good catch.  Maybe that is why I sub-consciously 
>> inserted the word "perhaps" above.. ;-)
>>
>
>Actually, upon further examination, I don't think that the rules above
>will work 
>correctly. Because
>
> >> RewriteCond%{REQUEST_URI} !^.*/$
> >> RewriteRule^/mypath/(.*)$/mypath/$1/ [R]
>
>would also rewrite
>
>/mypath/my-nifty.jsp
>
>to
>
>/mypath/my-nifty.jsp/
>
>which is probably not what is intended.
>Back to the drawing board..

You are right. It was too simple.

>
>Maybe adding a prior
>
>RewriteCond  %{REQUEST_URI} !\.(html|jpg|gif|jsp)$
>and then
>RewriteCond%{REQUEST_URI} !^.*/$
>RewriteRule^/mypath/(.*)$/mypath/$1/ [R]
>
>RewriteRule^/mypath/(.*)$/examples/jsp/$1
>
>would do it ?

That will only be done correctly by the one who knows the correct and allowed 
urls. Maybe they have URLs to .exe, .pdf, .jpeg, etc.

I think we should stop here as it seems to turn really quick into a mess. 

Regards
Felix 
>
>
>-
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: users-h...@tomcat.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Issue with RewriteValve and folders (tomcat 8.0.15)

[André Warnier]

André Warnier wrote:

Felix Schumacher wrote:

Am 19.02.2015 um 21:41 schrieb André Warnier:

Jérémie Barthés wrote:
...

...



in the browser, you have to modify your rewrite rules, perhaps by 
using a RewriteCond with the -d flag, to check first if the URL 
points to an existing directory, and if yes add the terminating "/" 
yourself (with a RewriteRule) before other rewrite tests/rules take 
place.

This rewrite.config

# if path doesn't end with a slash redirect it to an url with  an 
ending slash

RewriteCond%{REQUEST_URI} !^.*/$
RewriteRule^/mypath/(.*)$/mypath/$1/ [R]

# every path ending on a slash forward to /examples/...
RewriteRule^/mypath/(.*/)$/examples/jsp/$1

will do the trick. I think -d will not work, since /mypath/async is 
not existant, it only "feels" like a directory.


Aaah yes, correct.  Good catch.  Maybe that is why I sub-consciously 
inserted the word "perhaps" above.. ;-)




Actually, upon further examination, I don't think that the rules above will work 
correctly. Because


>> RewriteCond%{REQUEST_URI} !^.*/$
>> RewriteRule^/mypath/(.*)$/mypath/$1/ [R]

would also rewrite

   /mypath/my-nifty.jsp

to

   /mypath/my-nifty.jsp/

which is probably not what is intended.
Back to the drawing board..

Maybe adding a prior

RewriteCond  %{REQUEST_URI} !\.(html|jpg|gif|jsp)$
and then
RewriteCond%{REQUEST_URI} !^.*/$
RewriteRule^/mypath/(.*)$/mypath/$1/ [R]

RewriteRule^/mypath/(.*)$/examples/jsp/$1

would do it ?


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Issue with RewriteValve and folders (tomcat 8.0.15)

[André Warnier]

Felix Schumacher wrote:

Am 19.02.2015 um 21:41 schrieb André Warnier:

Jérémie Barthés wrote:
...



Make a file rewrite.config in conf/Catalina/localhost/ that contains :
RewriteRule^/mypath/(.*)$/examples/jsp/$1

copy the line
className="org.apache.catalina.valves.rewrite.RewriteValve" />

in the conf/server.xml file, line 131



Since this is a Valve, it will run before Tomcat attempts to match the 
URL to an actual directory or webapp.




try the followings URLs :



1) http://localhost:8080/mypath/async

This matches the rewrite rule, so it will be rewritten to URL

  /examples/jsp/async

Then Tomcat will attempt to match this to a directory or webapp, and 
find that (catalina_base)/webapps/examples/jsp/async is a directory.

It will thus respond to the browser with a 302 re-direct to

   http://localhost:8080/examples/jsp/async/

which is actually the "correct" URL.
And this is what will be shown in the browser URL bar.  This, in my 
view, is expected behaviour.  The server does that, so that when an 
actual response is generated (for the correct URL 
http://localhost:8080/examples/jsp/async/), the browser can cache this 
response under the correct URL.


Then the browser re-issues a request for

   http://localhost:8080/examples/jsp/async/

and that is when Tomcat will actually generate a "real" response, 
because this time it is a correct URL. So the response appears to the 
browser, as coming from


   http://localhost:8080/examples/jsp/async/

which is correct.

2) http://localhost:8080/mypath/async/

This also matches the rewrite rule, so it gets rewritten to

http://localhost:8080/examples/jsp/async/

which is a correct URL.
Thus Tomcat will immediately generate a real response (without an 
intermediate 302 redirect), which will be appear in the browser URL 
bar as a response to


http://localhost:8080/mypath/async/

This is also expected behaviour.

I believe that if you do not want to see the first redirect URL

   http://localhost:8080/examples/jsp/async/

in the browser, you have to modify your rewrite rules, perhaps by 
using a RewriteCond with the -d flag, to check first if the URL points 
to an existing directory, and if yes add the terminating "/" yourself 
(with a RewriteRule) before other rewrite tests/rules take place.

This rewrite.config

# if path doesn't end with a slash redirect it to an url with  an ending 
slash

RewriteCond%{REQUEST_URI} !^.*/$
RewriteRule^/mypath/(.*)$/mypath/$1/ [R]

# every path ending on a slash forward to /examples/...
RewriteRule^/mypath/(.*/)$/examples/jsp/$1

will do the trick. I think -d will not work, since /mypath/async is not 
existant, it only "feels" like a directory.


Aaah yes, correct.  Good catch.  Maybe that is why I sub-consciously inserted the word 
"perhaps" above.. ;-)


Incidentally, in the original Apache httpd 2.4 mod_rewrite documentation, there is a 
beautiful schema of how this actually works (in httpd).

Here : http://httpd.apache.org/docs/2.4/rewrite/tech.html
(in "Ruleset Processing").
Could almost have been drawn by Miro..



Felix


But I personally think that there is no need for a patch here.



the result i have is :
http://localhost:8080/mypath/async => 
http://localhost:8080/examples/jsp/async/ (visible rewrite)


no, it is the *redirect* which is visible, after the rewrite (to 
http://localhost:8080/examples/jsp/async) has taken place and Tomcat 
finds that this is a directory.


http://localhost:8080/mypath/async/ => 
http://localhost:8080/mypath/async/




no redirect, so the browser doesn't know, and believes that the 
response has actually come from the URL 
http://localhost:8080/mypath/async/.





-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org





-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Issue with RewriteValve and folders (tomcat 8.0.15)

[Felix Schumacher]

Am 19.02.2015 um 21:41 schrieb André Warnier:

Jérémie Barthés wrote:
...



Make a file rewrite.config in conf/Catalina/localhost/ that contains :
RewriteRule^/mypath/(.*)$/examples/jsp/$1

copy the line
className="org.apache.catalina.valves.rewrite.RewriteValve" />

in the conf/server.xml file, line 131



Since this is a Valve, it will run before Tomcat attempts to match the 
URL to an actual directory or webapp.




try the followings URLs :



1) http://localhost:8080/mypath/async

This matches the rewrite rule, so it will be rewritten to URL

  /examples/jsp/async

Then Tomcat will attempt to match this to a directory or webapp, and 
find that (catalina_base)/webapps/examples/jsp/async is a directory.

It will thus respond to the browser with a 302 re-direct to

   http://localhost:8080/examples/jsp/async/

which is actually the "correct" URL.
And this is what will be shown in the browser URL bar.  This, in my 
view, is expected behaviour.  The server does that, so that when an 
actual response is generated (for the correct URL 
http://localhost:8080/examples/jsp/async/), the browser can cache this 
response under the correct URL.


Then the browser re-issues a request for

   http://localhost:8080/examples/jsp/async/

and that is when Tomcat will actually generate a "real" response, 
because this time it is a correct URL. So the response appears to the 
browser, as coming from


   http://localhost:8080/examples/jsp/async/

which is correct.

2) http://localhost:8080/mypath/async/

This also matches the rewrite rule, so it gets rewritten to

http://localhost:8080/examples/jsp/async/

which is a correct URL.
Thus Tomcat will immediately generate a real response (without an 
intermediate 302 redirect), which will be appear in the browser URL 
bar as a response to


http://localhost:8080/mypath/async/

This is also expected behaviour.

I believe that if you do not want to see the first redirect URL

   http://localhost:8080/examples/jsp/async/

in the browser, you have to modify your rewrite rules, perhaps by 
using a RewriteCond with the -d flag, to check first if the URL points 
to an existing directory, and if yes add the terminating "/" yourself 
(with a RewriteRule) before other rewrite tests/rules take place.

This rewrite.config

# if path doesn't end with a slash redirect it to an url with  an ending 
slash

RewriteCond%{REQUEST_URI} !^.*/$
RewriteRule^/mypath/(.*)$/mypath/$1/ [R]

# every path ending on a slash forward to /examples/...
RewriteRule^/mypath/(.*/)$/examples/jsp/$1

will do the trick. I think -d will not work, since /mypath/async is not 
existant, it only "feels" like a directory.


Felix


But I personally think that there is no need for a patch here.



the result i have is :
http://localhost:8080/mypath/async => 
http://localhost:8080/examples/jsp/async/ (visible rewrite)


no, it is the *redirect* which is visible, after the rewrite (to 
http://localhost:8080/examples/jsp/async) has taken place and Tomcat 
finds that this is a directory.


http://localhost:8080/mypath/async/ => 
http://localhost:8080/mypath/async/




no redirect, so the browser doesn't know, and believes that the 
response has actually come from the URL 
http://localhost:8080/mypath/async/.





-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Issue with RewriteValve and folders (tomcat 8.0.15)

[André Warnier]

Jérémie Barthés wrote:
...



Make a file rewrite.config in conf/Catalina/localhost/ that contains :
RewriteRule^/mypath/(.*)$/examples/jsp/$1

copy the line
className="org.apache.catalina.valves.rewrite.RewriteValve" />

in the conf/server.xml file, line 131



Since this is a Valve, it will run before Tomcat attempts to match the URL to an actual 
directory or webapp.




try the followings URLs :



1) http://localhost:8080/mypath/async

This matches the rewrite rule, so it will be rewritten to URL

  /examples/jsp/async

Then Tomcat will attempt to match this to a directory or webapp, and find that 
(catalina_base)/webapps/examples/jsp/async is a directory.

It will thus respond to the browser with a 302 re-direct to

   http://localhost:8080/examples/jsp/async/

which is actually the "correct" URL.
And this is what will be shown in the browser URL bar.  This, in my view, is expected 
behaviour.  The server does that, so that when an actual response is generated (for the 
correct URL http://localhost:8080/examples/jsp/async/), the browser can cache this 
response under the correct URL.


Then the browser re-issues a request for

   http://localhost:8080/examples/jsp/async/

and that is when Tomcat will actually generate a "real" response, because this time it is 
a correct URL. So the response appears to the browser, as coming from


   http://localhost:8080/examples/jsp/async/

which is correct.

2) http://localhost:8080/mypath/async/

This also matches the rewrite rule, so it gets rewritten to

http://localhost:8080/examples/jsp/async/

which is a correct URL.
Thus Tomcat will immediately generate a real response (without an intermediate 302 
redirect), which will be appear in the browser URL bar as a response to


http://localhost:8080/mypath/async/

This is also expected behaviour.

I believe that if you do not want to see the first redirect URL

   http://localhost:8080/examples/jsp/async/

in the browser, you have to modify your rewrite rules, perhaps by using a RewriteCond with 
the -d flag, to check first if the URL points to an existing directory, and if yes add the 
terminating "/" yourself (with a RewriteRule) before other rewrite tests/rules take place.


But I personally think that there is no need for a patch here.



the result i have is :
http://localhost:8080/mypath/async => 
http://localhost:8080/examples/jsp/async/ (visible rewrite)


no, it is the *redirect* which is visible, after the rewrite (to 
http://localhost:8080/examples/jsp/async) has taken place and Tomcat finds that this is a 
directory.



http://localhost:8080/mypath/async/ => http://localhost:8080/mypath/async/



no redirect, so the browser doesn't know, and believes that the response has actually come 
from the URL http://localhost:8080/mypath/async/.





-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Issue with RewriteValve and folders (tomcat 8.0.15)

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jérémie,

On 2/19/15 10:05 AM, Jérémie Barthés wrote:
> I made a scenario to make the issue happens :
> 
> Use a tomcat 8.0.18
> 
> Make a file rewrite.config in conf/Catalina/localhost/ that
> contains : RewriteRule^/mypath/(.*)$/examples/jsp/$1
> 
> copy the line  className="org.apache.catalina.valves.rewrite.RewriteValve" /> in
> the conf/server.xml file, line 131
> 
> launch the server
> 
> try the followings URLs : http://localhost:8080/mypath/async 
> http://localhost:8080/mypath/async/
> 
> the result i have is : http://localhost:8080/mypath/async => 
> http://localhost:8080/examples/jsp/async/ (visible rewrite) 
> http://localhost:8080/mypath/async/ =>
> http://localhost:8080/mypath/async/

That's exactly the behavior I'd expect, since you have mapped
/mypath/async to /examples/jsp/async, which is a directory. The
DefaultServlet tries to serve that "directory" and redirects the user
to the same URL with a "/" on the end.

This isn't necessarily a problem with the RewriteValve, but with a
perhaps unexpected result of those two components together.

Can you provide a patch to RewriteValve? I'd prefer to see what you
actually changed, instead of just a snippet of "fixed" code.

- -chris

> Le 19/02/2015 15:25, Jérémie Barthés a écrit :
>> Tell me what you need about my configuration :
>> 
>> rewrite.config file : RewriteRule^/jamfiles/(.*)$
>> /newapp/jamfiles/$1 RewriteRule^/workspace/(.*)$
>> /newapp/htdocuments/workspace/$1 RewriteRule
>> ^/([a-zA-Z0-9]+)(\.jsp|\.html|\.txt)$ /newapp/htdocuments/$1$2
>> 
>> tomcat version : 8.0.15 (tried on 8.0.18 too)
>> 
>> Operating System : tried on windows 7 and unix
>> 
>> Le 19/02/2015 15:15, Christopher Schultz a écrit :
> Jérémie,
> 
> On 2/19/15 4:54 AM, Jérémie Barthés wrote:
>>>>> When an URL target a folder on the server, tomcat
>>>>> automaticly add a "/" at the end of the URL if missing :
>>>>> myHost.com/myFolder => myHost.com/myFolder/ (automatic
>>>>> tomcat 302 redirection)
>>>>> 
>>>>> If you use a rewriteValve to forward "myHost.com/myFolder"
>>>>> to "myHost.com/rewriteTrick/myFolder", the rewriteValve
>>>>> will forward simultaneous with the automatic tomcat
>>>>> redirection. Then the client's browser will catch the
>>>>> rewritten URL (you don't want the rewritten URL to be
>>>>> visible for the client's browser). myHost.com/myFolder
>>>>> redirect to myHost.com/rewriteTrick/myFolder/ (visible)
>>>>> 
>>>>> So i made a patch to block the RewriteValve if an automatic
>>>>> 302 tomcat redirection is applied. Then the RewriteValve
>>>>> forward in a second time and the rewritten URL is not
>>>>> visible for the client's Browser : myHost.com/myFolder
>>>>> redirect to myHost.com/myFolder/ forward to
>>>>> myHost/rewriteTrick/myFolder/ (not visible)
>>>>> 
>>>>> It may be a configuration mistake of my part. I tried many 
>>>>> different configurations to avoid it but i wasn't able
>>>>> without coding a patch.
> It /may/ be a configuration problem. We won't know until you post
> your configuration.
> 
> -chris
>>> 
>>> -
>>>
>>> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>> 
>> 
>> 
>> -
>>
>> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 
> 
> 
> -
>
> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJU5iJ/AAoJEBzwKT+lPKRYJO8QALg30zvUh0LBMjnQ0bHpNcVh
xWJcwbEQMF1L3js1PRJFDLwhW6wARuHHmkg2mUTVkjXzI8B+UFdzK64tef+OuxIe
Q5JGGHTHhmoRbqlc5daVgiRjBz3PT2gx4uB87/Ub6qAsVKF1zKqOiz9d6kxRFmu/
t/kcAHaoy+N3cNULn/kpjt47DgNh10eSFrjEfXoBQUIWA9up39kfAfLFabitJcCp
QSDtUUD/YODlj2g6jGcIaKvZ0gfAwRCi1wF9ZXVEj9kCHuHWDxStQF8atPB5Rqtx
0wt4dnZvOaEkE2P26T+8K66Tn430bvQFCJl39PD4Hkq6zlWibpLoe4XZmVnzNMRu
xDy7IpHaBa2nwVJCFzSk42/uHRt3XzxqR0RTZmF3+tUyK9H30H5HanCeE66yA7kR
Blfxyln6I6M1klgBkKB2eFaw9BUzI4Ad2T3k87hzoxgVJnQjr+J0HrphNHu/YbLC
n6H9Hjhqdlc2pemaQWal7inh9T1G+juphwQwo27l9ozU5MrZrZjXEm13ILLginV4
dYf9Fo7ZMpA7DFyRgdtRtP2GmtTnw3FP8ovdleruzNgf+F+ZV5tzn6R1/7gzFtBA
Eqvq7+qRzScP/zGdbRO8HrIJ9zQsDN/ltal/PfEJAUm2zM3gAsUG8vzF0cHdLArx
OfdCrrVkm4sUBrl9YAOX
=kGdG
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Issue with RewriteValve and folders (tomcat 8.0.15)

[Jérémie Barthés]

Hi,

I made a scenario to make the issue happens :

Use a tomcat 8.0.18

Make a file rewrite.config in conf/Catalina/localhost/ that contains :
RewriteRule^/mypath/(.*)$/examples/jsp/$1

copy the line
className="org.apache.catalina.valves.rewrite.RewriteValve" />

in the conf/server.xml file, line 131

launch the server

try the followings URLs :
http://localhost:8080/mypath/async
http://localhost:8080/mypath/async/

the result i have is :
http://localhost:8080/mypath/async => 
http://localhost:8080/examples/jsp/async/ (visible rewrite)

http://localhost:8080/mypath/async/ => http://localhost:8080/mypath/async/

Jérémie



Le 19/02/2015 15:25, Jérémie Barthés a écrit :

Tell me what you need about my configuration :

rewrite.config file :
RewriteRule^/jamfiles/(.*)$/newapp/jamfiles/$1
RewriteRule^/workspace/(.*)$ /newapp/htdocuments/workspace/$1
RewriteRule ^/([a-zA-Z0-9]+)(\.jsp|\.html|\.txt)$ 
/newapp/htdocuments/$1$2


tomcat version : 8.0.15 (tried on 8.0.18 too)

Operating System : tried on windows 7 and unix

Le 19/02/2015 15:15, Christopher Schultz a écrit :

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jérémie,

On 2/19/15 4:54 AM, Jérémie Barthés wrote:

When an URL target a folder on the server, tomcat automaticly add a
"/" at the end of the URL if missing : myHost.com/myFolder =>
myHost.com/myFolder/ (automatic tomcat 302 redirection)

If you use a rewriteValve to forward "myHost.com/myFolder" to
"myHost.com/rewriteTrick/myFolder", the rewriteValve will forward
simultaneous with the automatic tomcat redirection. Then the
client's browser will catch the rewritten URL (you don't want the
rewritten URL to be visible for the client's browser).
myHost.com/myFolder redirect to myHost.com/rewriteTrick/myFolder/
(visible)

So i made a patch to block the RewriteValve if an automatic 302
tomcat redirection is applied. Then the RewriteValve forward in a
second time and the rewritten URL is not visible for the client's
Browser : myHost.com/myFolder redirect to myHost.com/myFolder/
forward to myHost/rewriteTrick/myFolder/ (not visible)

It may be a configuration mistake of my part. I tried many
different configurations to avoid it but i wasn't able without
coding a patch.

It /may/ be a configuration problem. We won't know until you post your
configuration.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJU5e/qAAoJEBzwKT+lPKRYPaAP/jtr2XC2ZViVzUDK44Fqcl+P
q1LRRKO112Hzv+p35kUAPFQn2YyvJamqH7dnl6rVnBIY5YviBCNqJdpn48fpe78E
B/T5nr9WOfdMxg9fBgMG78L+ihJzKgiZpXGgVvR68RLuYgeWPhnur2I3Xcj4rLRc
Nd9aWX/vHX3aLoh3ThTUKIWVmaiK8a5JP240W/5g65OE07Tnc/albiBHvTdGbEBQ
LoLKmp315mZLDkzzNIsu7Lbbz8DtDrJo+Oaos1Fm3CUBM5ULO0hwcFr1IyxL2Tvk
1S8ZGHaDvFQF0II0pf9P8MgpDfK1st1rGp86k1B3e1KMt7gWFytOZwPgJLwCDqVe
VAfgE4VpnJ8aBtVAKc1vTpNpP4X4xuFuKl93OtAbaFa9mBhdfetbeCo7OLogeSB+
UZj3PQnM7rLoyllXtEx4hGSDy+AU3o/S7JqXrJdbHMqt1v/BmEd/ZsdAYCOa+lmb
JEkxPUG+EPTMxyiCrw498KjY2q5Z9naA/IecIHdPGa7u2TwIlkMCJazCtBEmSu8d
VfDQyxR1f+eExsTa3i8eIjdw+z/hTsgMJYi0qiI2slkWOp99N9xWNdH/W5UdHKWf
Qb8fefesWyKQof0voqWPbOXOFdgcJqXs26K1gxRM9rZSzfV990Ooizohg/DfGYjG
Y2AZNcubxOPam0aEVct9
=ClXj
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Issue with RewriteValve and folders (tomcat 8.0.15)

[Jérémie Barthés]

Tell me what you need about my configuration :

rewrite.config file :
RewriteRule^/jamfiles/(.*)$/newapp/jamfiles/$1
RewriteRule^/workspace/(.*)$ /newapp/htdocuments/workspace/$1
RewriteRule ^/([a-zA-Z0-9]+)(\.jsp|\.html|\.txt)$ /newapp/htdocuments/$1$2

tomcat version : 8.0.15 (tried on 8.0.18 too)

Operating System : tried on windows 7 and unix

Le 19/02/2015 15:15, Christopher Schultz a écrit :

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jérémie,

On 2/19/15 4:54 AM, Jérémie Barthés wrote:

When an URL target a folder on the server, tomcat automaticly add a
"/" at the end of the URL if missing : myHost.com/myFolder =>
myHost.com/myFolder/ (automatic tomcat 302 redirection)

If you use a rewriteValve to forward "myHost.com/myFolder" to
"myHost.com/rewriteTrick/myFolder", the rewriteValve will forward
simultaneous with the automatic tomcat redirection. Then the
client's browser will catch the rewritten URL (you don't want the
rewritten URL to be visible for the client's browser).
myHost.com/myFolder redirect to myHost.com/rewriteTrick/myFolder/
(visible)

So i made a patch to block the RewriteValve if an automatic 302
tomcat redirection is applied. Then the RewriteValve forward in a
second time and the rewritten URL is not visible for the client's
Browser : myHost.com/myFolder redirect to myHost.com/myFolder/
forward to myHost/rewriteTrick/myFolder/ (not visible)

It may be a configuration mistake of my part. I tried many
different configurations to avoid it but i wasn't able without
coding a patch.

It /may/ be a configuration problem. We won't know until you post your
configuration.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJU5e/qAAoJEBzwKT+lPKRYPaAP/jtr2XC2ZViVzUDK44Fqcl+P
q1LRRKO112Hzv+p35kUAPFQn2YyvJamqH7dnl6rVnBIY5YviBCNqJdpn48fpe78E
B/T5nr9WOfdMxg9fBgMG78L+ihJzKgiZpXGgVvR68RLuYgeWPhnur2I3Xcj4rLRc
Nd9aWX/vHX3aLoh3ThTUKIWVmaiK8a5JP240W/5g65OE07Tnc/albiBHvTdGbEBQ
LoLKmp315mZLDkzzNIsu7Lbbz8DtDrJo+Oaos1Fm3CUBM5ULO0hwcFr1IyxL2Tvk
1S8ZGHaDvFQF0II0pf9P8MgpDfK1st1rGp86k1B3e1KMt7gWFytOZwPgJLwCDqVe
VAfgE4VpnJ8aBtVAKc1vTpNpP4X4xuFuKl93OtAbaFa9mBhdfetbeCo7OLogeSB+
UZj3PQnM7rLoyllXtEx4hGSDy+AU3o/S7JqXrJdbHMqt1v/BmEd/ZsdAYCOa+lmb
JEkxPUG+EPTMxyiCrw498KjY2q5Z9naA/IecIHdPGa7u2TwIlkMCJazCtBEmSu8d
VfDQyxR1f+eExsTa3i8eIjdw+z/hTsgMJYi0qiI2slkWOp99N9xWNdH/W5UdHKWf
Qb8fefesWyKQof0voqWPbOXOFdgcJqXs26K1gxRM9rZSzfV990Ooizohg/DfGYjG
Y2AZNcubxOPam0aEVct9
=ClXj
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Issue with RewriteValve and folders (tomcat 8.0.15)

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jérémie,

On 2/19/15 4:54 AM, Jérémie Barthés wrote:
> When an URL target a folder on the server, tomcat automaticly add a
> "/" at the end of the URL if missing : myHost.com/myFolder =>
> myHost.com/myFolder/ (automatic tomcat 302 redirection)
> 
> If you use a rewriteValve to forward "myHost.com/myFolder" to 
> "myHost.com/rewriteTrick/myFolder", the rewriteValve will forward
> simultaneous with the automatic tomcat redirection. Then the
> client's browser will catch the rewritten URL (you don't want the
> rewritten URL to be visible for the client's browser). 
> myHost.com/myFolder redirect to myHost.com/rewriteTrick/myFolder/
> (visible)
> 
> So i made a patch to block the RewriteValve if an automatic 302
> tomcat redirection is applied. Then the RewriteValve forward in a
> second time and the rewritten URL is not visible for the client's
> Browser : myHost.com/myFolder redirect to myHost.com/myFolder/ 
> forward to myHost/rewriteTrick/myFolder/ (not visible)
> 
> It may be a configuration mistake of my part. I tried many
> different configurations to avoid it but i wasn't able without
> coding a patch.

It /may/ be a configuration problem. We won't know until you post your
configuration.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJU5e/qAAoJEBzwKT+lPKRYPaAP/jtr2XC2ZViVzUDK44Fqcl+P
q1LRRKO112Hzv+p35kUAPFQn2YyvJamqH7dnl6rVnBIY5YviBCNqJdpn48fpe78E
B/T5nr9WOfdMxg9fBgMG78L+ihJzKgiZpXGgVvR68RLuYgeWPhnur2I3Xcj4rLRc
Nd9aWX/vHX3aLoh3ThTUKIWVmaiK8a5JP240W/5g65OE07Tnc/albiBHvTdGbEBQ
LoLKmp315mZLDkzzNIsu7Lbbz8DtDrJo+Oaos1Fm3CUBM5ULO0hwcFr1IyxL2Tvk
1S8ZGHaDvFQF0II0pf9P8MgpDfK1st1rGp86k1B3e1KMt7gWFytOZwPgJLwCDqVe
VAfgE4VpnJ8aBtVAKc1vTpNpP4X4xuFuKl93OtAbaFa9mBhdfetbeCo7OLogeSB+
UZj3PQnM7rLoyllXtEx4hGSDy+AU3o/S7JqXrJdbHMqt1v/BmEd/ZsdAYCOa+lmb
JEkxPUG+EPTMxyiCrw498KjY2q5Z9naA/IecIHdPGa7u2TwIlkMCJazCtBEmSu8d
VfDQyxR1f+eExsTa3i8eIjdw+z/hTsgMJYi0qiI2slkWOp99N9xWNdH/W5UdHKWf
Qb8fefesWyKQof0voqWPbOXOFdgcJqXs26K1gxRM9rZSzfV990Ooizohg/DfGYjG
Y2AZNcubxOPam0aEVct9
=ClXj
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Issue with RewriteValve and folders (tomcat 8.0.15)

[Jérémie Barthés]

Hi Chris,

When an URL target a folder on the server, tomcat automaticly add a "/" 
at the end of the URL if missing :
myHost.com/myFolder => myHost.com/myFolder/ (automatic tomcat 302 
redirection)


If you use a rewriteValve to forward "myHost.com/myFolder" to 
"myHost.com/rewriteTrick/myFolder",
the rewriteValve will forward simultaneous with the automatic tomcat 
redirection. Then the client's browser will catch the rewritten URL (you 
don't want

the rewritten URL to be visible for the client's browser).
myHost.com/myFolder
redirect to
myHost.com/rewriteTrick/myFolder/ (visible)

So i made a patch to block the RewriteValve if an automatic 302 tomcat 
redirection is applied. Then the RewriteValve forward in a second time 
and the rewritten URL is not visible for the client's Browser :

myHost.com/myFolder
redirect to
myHost.com/myFolder/
forward to
myHost/rewriteTrick/myFolder/ (not visible)

It may be a configuration mistake of my part. I tried many different 
configurations to avoid it but i wasn't able without coding a patch.


Regards

Jérémie




Le 17/02/2015 19:39, Christopher Schultz a écrit :

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jérémie,

On 2/17/15 10:47 AM, Jérémie Barthés wrote:

I don't have more to say than :

"There is a bug using the RewriteValve :If you are targeting a
folder and there is no "/" at the end of the URI,

The end of which URI? The one in the rewrite rule? Or the one the
client sends in the URL?


the rewritten URI is visible for the client browser (302
redirection). Example : http://myhost.com/myFolder =>
http://myhost.com/rewriteTrick/myFolder/ instead of
http://myhost.com/myFolder => http://myhost.com/myFolder/";

It looks like in this case, the rewrite rule isn't matching, and the
DefaultServlet is performing redirection instead. This sounds like a
configuration mistake on your part, not a bug in the rewrite valve.


The bug is solved for me. I just wanted to tell developers about
it.

- -chris


Le 17/02/2015 15:34, Christopher Schultz a écrit : Jérémie,

On 2/17/15 6:20 AM, Jérémie Barthés wrote:

I just installed tomcat 8 and used the RewriteValve to
forward some old URLs on my new tomcat8 webapp. I had an
issue for URIs targeting a folder: If there is no "/" at the
end of the URI, the rewritten URI is visible for the client
browser (302 redirection). Example :
http://myhost.com/myFolder =>
http://myhost.com/rewriteTrick/myFolder/ instead of
http://myhost.com/myFolder => http://myhost.com/myFolder/

I made a custom patch on RewriteValve to solve it. I would
like to know if it'll be corrected on next releases. (i tried
on 8.0.18 but there is still the issue)

Regards,

Jeremie Barthes Oodrive France



Between lines 480 and 500 :

boolean folderRedirect = false; try{
request.getMappingData().recycle();

request.getConnector().getService().getMapper().map(request.getCoyoteRequest().serverName(),




request.getCoyoteRequest().requestURI(),

null, request.getMappingData());

if(request.getMappingData().redirectPath.toString()!=null){
folderRedirect = true; } } catch (Exception e){ //ignore }

request.getMappingData().recycle(); // Reinvoke the whole
request recursively try {

request.getConnector().getProtocolHandler().getAdapter().service



(request.getCoyoteRequest(), response.getCoyoteResponse());

if(folderRedirect && response.getCoyoteResponse().getStatus()
== 302){

if(!request.getCoyoteRequest().requestURI().getByteChunk().toString().endsWith("/")){





String requestParam = request.getQueryString() == null ? "" : '?'

+ request.getQueryString(); response.setHeader("Location",
request.getCoyoteRequest().requestURI().getByteChunk().toString()
+ '/' + requestParam); } } } catch (Exception e) { // This
doesn't actually happen in the Catalina adapter
implementation }

The best practice would be to file an enhancement request in
Bugzilla, write and attach a test case that demonstrates the
problem (or describe it in very great detail... from the above, I
don't know what you have changed and why), and attach your changes
(as a patch, using "svn diff" or something similar) to the Bugzilla
issue.

-chris

-



To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org

For additional commands, e-mail: users-h...@tomcat.apache.org



-



To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org

For additional commands, e-mail: users-h...@tomcat.apache.org


-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJU44rQAAoJEBzwKT+lPKRYLwEQAJgAdh33TnTRbkRtBfugTc5D
8VwtHftAfL6ykdbGTYllInSfhxZkWH3fA7gxqBb18TaICqw0sxAVg1TaKIjtEwYb
TQzxryNJQsg1fJ97L56EauRJyKikO0OTE7XUT8S5TIr/Z0YuhfQz

Re: Issue with RewriteValve and folders (tomcat 8.0.15)

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jérémie,

On 2/17/15 10:47 AM, Jérémie Barthés wrote:
> I don't have more to say than :
> 
> "There is a bug using the RewriteValve :If you are targeting a
> folder and there is no "/" at the end of the URI,

The end of which URI? The one in the rewrite rule? Or the one the
client sends in the URL?

> the rewritten URI is visible for the client browser (302
> redirection). Example : http://myhost.com/myFolder =>
> http://myhost.com/rewriteTrick/myFolder/ instead of 
> http://myhost.com/myFolder => http://myhost.com/myFolder/";

It looks like in this case, the rewrite rule isn't matching, and the
DefaultServlet is performing redirection instead. This sounds like a
configuration mistake on your part, not a bug in the rewrite valve.

> The bug is solved for me. I just wanted to tell developers about
> it.

- -chris

> Le 17/02/2015 15:34, Christopher Schultz a écrit : Jérémie,
> 
> On 2/17/15 6:20 AM, Jérémie Barthés wrote:
>>>> I just installed tomcat 8 and used the RewriteValve to
>>>> forward some old URLs on my new tomcat8 webapp. I had an
>>>> issue for URIs targeting a folder: If there is no "/" at the
>>>> end of the URI, the rewritten URI is visible for the client
>>>> browser (302 redirection). Example :
>>>> http://myhost.com/myFolder => 
>>>> http://myhost.com/rewriteTrick/myFolder/ instead of 
>>>> http://myhost.com/myFolder => http://myhost.com/myFolder/
>>>> 
>>>> I made a custom patch on RewriteValve to solve it. I would
>>>> like to know if it'll be corrected on next releases. (i tried
>>>> on 8.0.18 but there is still the issue)
>>>> 
>>>> Regards,
>>>> 
>>>> Jeremie Barthes Oodrive France
>>>> 
>>>> 
>>>> 
>>>> Between lines 480 and 500 :
>>>> 
>>>> boolean folderRedirect = false; try{ 
>>>> request.getMappingData().recycle();
>>>> 
>>>> request.getConnector().getService().getMapper().map(request.getCoyoteRequest().serverName(),
>>>>
>>>>
>>>>
>
>>>> 
request.getCoyoteRequest().requestURI(),
>>>> null, request.getMappingData());
>>>> 
>>>> if(request.getMappingData().redirectPath.toString()!=null){ 
>>>> folderRedirect = true; } } catch (Exception e){ //ignore }
>>>> 
>>>> request.getMappingData().recycle(); // Reinvoke the whole
>>>> request recursively try {
>>>> 
>>>> request.getConnector().getProtocolHandler().getAdapter().service
>>>>
>>>> 
(request.getCoyoteRequest(), response.getCoyoteResponse());
>>>> if(folderRedirect && response.getCoyoteResponse().getStatus()
>>>> == 302){
>>>> 
>>>> if(!request.getCoyoteRequest().requestURI().getByteChunk().toString().endsWith("/")){
>>>>
>>>>
>>>>
>>>> 
String requestParam = request.getQueryString() == null ? "" : '?'
>>>> + request.getQueryString(); response.setHeader("Location", 
>>>> request.getCoyoteRequest().requestURI().getByteChunk().toString()
>>>> + '/' + requestParam); } } } catch (Exception e) { // This
>>>> doesn't actually happen in the Catalina adapter
>>>> implementation }
> The best practice would be to file an enhancement request in
> Bugzilla, write and attach a test case that demonstrates the
> problem (or describe it in very great detail... from the above, I
> don't know what you have changed and why), and attach your changes
> (as a patch, using "svn diff" or something similar) to the Bugzilla
> issue.
> 
> -chris
>> 
>> -
>>
>> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 
> 
> 
> -
>
> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJU44rQAAoJEBzwKT+lPKRYLwEQAJgAdh33TnTRbkRtBfugTc5D
8VwtHftAfL6ykdbGTYllInSfhxZkWH3fA7gxqBb18TaICqw0sxAVg1TaKIjtEwYb
TQzxryNJQsg1fJ97L56EauRJyKikO0OTE7XUT8S5TIr/Z0YuhfQzIOKA+KvzyiUE
rDbJ4N4TA41fvgA7aCdeQluDGJ/sOnFVotq5sSp6j41XSCAfWXrg8r+FlVegPJm8
fblHS3E19PTvv/IuJaNDPefafpdLoyiMYnfPgC8MKYbfipUCJLyl30ZTjiBw2Jmi
9SGqPFkk9y2Yk72R5ihL1dExb332nBwV7xZIVJsyDysKWW2OYI/XY7BYwSW8rguA
05hdEetI1UFgWavh6imqzWoDpOV35Pi+crYB+ZUDeDHfHCxjhvyxlXhXFtp6QkB+
yODHW4qXA4QPjsSNG+I6letaDA2lvxDNlzjip/iSsjEfwOMj6E6vnqkW7oD92YxF
lcNaqI9weDDJwaJZUrra3dxqR4VYj0WcmHsUY/+uqQhh083KKPhpJ6r54xL9Dv4N
1vFdJIRelhX2YxlXTUS5Jx/vhEHGS5P95un92tdP46WyOS9s3Jkutigt5E4I9AaG
v9AdGlDZwah9q8sJ00U1tqGdkMwRdY12KHtY9loWRY1T7Gn3pAzPIcNSvvCR8OE2
uCigdMtsLsOMvqIPz5Mh
=xqs9
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Issue with RewriteValve and folders (tomcat 8.0.15)

[Jérémie Barthés]

Hi,

I don't have more to say than :

"There is a bug using the RewriteValve :If you are targeting a folder and there is no 
"/" at the end of the URI,
the rewritten URI is visible for the client browser (302 redirection).
Example :
http://myhost.com/myFolder => http://myhost.com/rewriteTrick/myFolder/
instead of
http://myhost.com/myFolder => http://myhost.com/myFolder/";


The bug is solved for me.
I just wanted to tell developpers about it.

Regards

Jérémie


Le 17/02/2015 15:34, Christopher Schultz a écrit :

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jérémie,

On 2/17/15 6:20 AM, Jérémie Barthés wrote:

I just installed tomcat 8 and used the RewriteValve to forward some
old URLs on my new tomcat8 webapp. I had an issue for URIs
targeting a folder: If there is no "/" at the end of the URI, the
rewritten URI is visible for the client browser (302 redirection).
Example : http://myhost.com/myFolder =>
http://myhost.com/rewriteTrick/myFolder/ instead of
http://myhost.com/myFolder => http://myhost.com/myFolder/

I made a custom patch on RewriteValve to solve it. I would like to
know if it'll be corrected on next releases. (i tried on 8.0.18 but
there is still the issue)

Regards,

Jeremie Barthes Oodrive France



Between lines 480 and 500 :

boolean folderRedirect = false; try{
request.getMappingData().recycle();

request.getConnector().getService().getMapper().map(request.getCoyoteRequest().serverName(),



request.getCoyoteRequest().requestURI(),

null, request.getMappingData());

if(request.getMappingData().redirectPath.toString()!=null){
folderRedirect = true; } } catch (Exception e){ //ignore }

request.getMappingData().recycle(); // Reinvoke the whole request
recursively try {

request.getConnector().getProtocolHandler().getAdapter().service
(request.getCoyoteRequest(), response.getCoyoteResponse());
if(folderRedirect && response.getCoyoteResponse().getStatus() ==
302){

if(!request.getCoyoteRequest().requestURI().getByteChunk().toString().endsWith("/")){

  String requestParam = request.getQueryString() == null ? "" : '?'
+ request.getQueryString(); response.setHeader("Location",
request.getCoyoteRequest().requestURI().getByteChunk().toString() +
'/' + requestParam); } } } catch (Exception e) { // This doesn't
actually happen in the Catalina adapter implementation }

The best practice would be to file an enhancement request in Bugzilla,
write and attach a test case that demonstrates the problem (or
describe it in very great detail... from the above, I don't know what
you have changed and why), and attach your changes (as a patch, using
"svn diff" or something similar) to the Bugzilla issue.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJU41FiAAoJEBzwKT+lPKRYJVwP/0txV+MSHwzl4FQjRWd2gaOS
V+l0b7CIXI77lHr+xuC6A/OqqpJHNPZjYWIqtCaeDvq/eFc8eVXczV8C6CV1NWN5
b9dQdBTw4/+bC/JNg2XlWkwlbeW08eNqeX77F1zXhSoBEUuZrRcmy/sZXsa4g9x8
XusQqrjpjc5KvZOkUqJbazbKO86o7kRrOuVNVXR0MHtpmBMOkCI0WKht+RpsA3DN
fH0Qd+eo0xtmU0YNSMURr6Z8y+yi3v/pNx4tBQ5ijEAHXB8f9SolfObt63OrcTh3
I347ZIEESfkeqxqBqImJkeRsqvlx2pv2ChF0fm638vgiYFXU+a4xYLP45ovR0wg6
c4P0GYK3mE2yieQjio3zAj/Z9Qc4DW39FJNIeU1zYY+73yzkn28CprW6nn9eaRvf
cz+vaU2IamD/e4vJgHpiB5vewwaZSx1a81OkpDn8O7xWyO4azp4eViA2K5jwM2Cf
LL7/fztfJoapob+polncNECb3Bi3aT/yKeI9tbunb7x8jCHqIBWtGrvKJ0U5q25U
XzH1Wk6EZCtYhiYXQvyPoktKmXfDuayMiq+IexdMBic+I/Uqv5scQuFrjEZVlFj+
hSNd9OpPQwXKL7ScFAyznw6R4h5yzPZyW01KtO1jVek1oOOdIRI7PxLRgJReh6j0
78GINeUMF8NCRkYY4/sf
=zX1T
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Issue with RewriteValve and folders (tomcat 8.0.15)

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jérémie,

On 2/17/15 6:20 AM, Jérémie Barthés wrote:
> I just installed tomcat 8 and used the RewriteValve to forward some
> old URLs on my new tomcat8 webapp. I had an issue for URIs
> targeting a folder: If there is no "/" at the end of the URI, the
> rewritten URI is visible for the client browser (302 redirection). 
> Example : http://myhost.com/myFolder =>
> http://myhost.com/rewriteTrick/myFolder/ instead of 
> http://myhost.com/myFolder => http://myhost.com/myFolder/
> 
> I made a custom patch on RewriteValve to solve it. I would like to
> know if it'll be corrected on next releases. (i tried on 8.0.18 but
> there is still the issue)
> 
> Regards,
> 
> Jeremie Barthes Oodrive France
> 
> 
> 
> Between lines 480 and 500 :
> 
> boolean folderRedirect = false; try{ 
> request.getMappingData().recycle();
> 
> request.getConnector().getService().getMapper().map(request.getCoyoteRequest().serverName(),
>
> 
request.getCoyoteRequest().requestURI(),
> null, request.getMappingData());
> 
> if(request.getMappingData().redirectPath.toString()!=null){ 
> folderRedirect = true; } } catch (Exception e){ //ignore }
> 
> request.getMappingData().recycle(); // Reinvoke the whole request
> recursively try {
> 
> request.getConnector().getProtocolHandler().getAdapter().service 
> (request.getCoyoteRequest(), response.getCoyoteResponse()); 
> if(folderRedirect && response.getCoyoteResponse().getStatus() ==
> 302){
> 
> if(!request.getCoyoteRequest().requestURI().getByteChunk().toString().endsWith("/")){
>
>  String requestParam = request.getQueryString() == null ? "" : '?'
> + request.getQueryString(); response.setHeader("Location", 
> request.getCoyoteRequest().requestURI().getByteChunk().toString() +
> '/' + requestParam); } } } catch (Exception e) { // This doesn't
> actually happen in the Catalina adapter implementation }

The best practice would be to file an enhancement request in Bugzilla,
write and attach a test case that demonstrates the problem (or
describe it in very great detail... from the above, I don't know what
you have changed and why), and attach your changes (as a patch, using
"svn diff" or something similar) to the Bugzilla issue.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJU41FiAAoJEBzwKT+lPKRYJVwP/0txV+MSHwzl4FQjRWd2gaOS
V+l0b7CIXI77lHr+xuC6A/OqqpJHNPZjYWIqtCaeDvq/eFc8eVXczV8C6CV1NWN5
b9dQdBTw4/+bC/JNg2XlWkwlbeW08eNqeX77F1zXhSoBEUuZrRcmy/sZXsa4g9x8
XusQqrjpjc5KvZOkUqJbazbKO86o7kRrOuVNVXR0MHtpmBMOkCI0WKht+RpsA3DN
fH0Qd+eo0xtmU0YNSMURr6Z8y+yi3v/pNx4tBQ5ijEAHXB8f9SolfObt63OrcTh3
I347ZIEESfkeqxqBqImJkeRsqvlx2pv2ChF0fm638vgiYFXU+a4xYLP45ovR0wg6
c4P0GYK3mE2yieQjio3zAj/Z9Qc4DW39FJNIeU1zYY+73yzkn28CprW6nn9eaRvf
cz+vaU2IamD/e4vJgHpiB5vewwaZSx1a81OkpDn8O7xWyO4azp4eViA2K5jwM2Cf
LL7/fztfJoapob+polncNECb3Bi3aT/yKeI9tbunb7x8jCHqIBWtGrvKJ0U5q25U
XzH1Wk6EZCtYhiYXQvyPoktKmXfDuayMiq+IexdMBic+I/Uqv5scQuFrjEZVlFj+
hSNd9OpPQwXKL7ScFAyznw6R4h5yzPZyW01KtO1jVek1oOOdIRI7PxLRgJReh6j0
78GINeUMF8NCRkYY4/sf
=zX1T
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Issue with RewriteValve and folders (tomcat 8.0.15)

[Jérémie Barthés]

Hi,

I just installed tomcat 8 and used the RewriteValve to forward some old
URLs on my new tomcat8 webapp. I had an issue for URIs targeting a
folder: If there is no "/" at the end of the URI, the rewritten URI is
visible for the client browser (302 redirection).
Example :
http://myhost.com/myFolder => http://myhost.com/rewriteTrick/myFolder/
instead of
http://myhost.com/myFolder => http://myhost.com/myFolder/

I made a custom patch on RewriteValve to solve it. I would like to know if 
it'll be corrected on next releases. (i tried on 8.0.18 but there is still the 
issue)

Regards,

Jeremie Barthes
Oodrive France



Between lines 480 and 500 :

  boolean folderRedirect = false;
try{
request.getMappingData().recycle();

request.getConnector().getService().getMapper().map(request.getCoyoteRequest().serverName(),
 request.getCoyoteRequest().requestURI(),
null, request.getMappingData());

if(request.getMappingData().redirectPath.toString()!=null){
folderRedirect = true;
}
} catch (Exception e){
//ignore
}

request.getMappingData().recycle();
// Reinvoke the whole request recursively
try {

request.getConnector().getProtocolHandler().getAdapter().service
(request.getCoyoteRequest(), 
response.getCoyoteResponse());

if(folderRedirect && response.getCoyoteResponse().getStatus() == 302){


if(!request.getCoyoteRequest().requestURI().getByteChunk().toString().endsWith("/")){
String requestParam = request.getQueryString() == 
null ? "" : '?' + request.getQueryString();
response.setHeader("Location", 
request.getCoyoteRequest().requestURI().getByteChunk().toString() + '/' + requestParam);
}
}
} catch (Exception e) {
// This doesn't actually happen in the Catalina adapter 
implementation
}

 







-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org