You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Jérémie Barthés <j....@oodrive.fr> on 2015/02/17 12:20:15 UTC
Issue with RewriteValve and folders (tomcat 8.0.15)
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Issue with RewriteValve and folders (tomcat 8.0.15)
Posted by Jérémie Barthés <j....@oodrive.fr>.
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 <ch...@christopherschultz.net>:
>> 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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: Issue with RewriteValve and folders (tomcat 8.0.15)
Posted by Konstantin Kolinko <kn...@gmail.com>.
2015-02-20 19:41 GMT+03:00 Christopher Schultz <ch...@christopherschultz.net>:
>
> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Issue with RewriteValve and folders (tomcat 8.0.15)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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 <Valve
>>>>>>> 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
>>>>
>>>> ...
>>>>
>>>>> 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-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail:
>>>> users-help@tomcat.apache.org
>>>
>>>
>>> ---------------------------------------------------------------------
>>>
>>>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>>
>>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJU52OrAAoJEBzwKT+lPKRYEMIP/i+iITuiZovejOUkx6dMB2AZ
nj61DU2MQOx2vOHObP3oyyKwvhK2/X26D/C7X9M0zhv5XvI8pEe/taD5JtsXeMFy
dSC7AsLts1Rd3raADT6d5c4QTvaoXhqoHVC8VfyBWk8s1VloMdzVj4sLNzoX6c59
xkPj7rlNyRIqiK02wDdkr1ApW1FtYjwIT2tdciE4JJzjSVZ4U0C81XDDfIsFLEZR
C8lHl/vQFohcTeh/xmM/7fDYwO2bqUi7pYN6pal7pijjzdZ1lQg+HietyD6no3ta
4HNTfu2Exz+beEvGwY3h0+wrAFwBlwleKdahHitW+Yi/6TMZiKfp9HpjAMcWJpcH
B1iKty8C64lmiwcqMKnU43D2rtUnu9sfGRXDcScl+85m2SYc/W7WUkrjN7hhldoe
B3u4FJ7fD28oWtHsNnAmQ9jdyCFvHWIumawuS5w+wg9OwcQbiUBs1R7p1CK5jxMw
IZnjZdSdtIWHBhNksHbfEsAcWsx6ZGF8Z55U1BllHaGQ6aLh0OacE+6qf87gDPVO
+TZRJA0mWOjxZ6I1SG8kuXjPQ7NfQwkmyLq3QrO77NF5USsD0z9fb+Y2w1rW4VJl
gw5BGdup7SuIkLqR/y6/J8KqvgDYXARZAUbuuTg87nzLBH/DgU+fQxY4O8T+pc62
mvHseJIiMJBmXZNfxE2G
=um4m
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Issue with RewriteValve and folders (tomcat 8.0.15)
Posted by Jérémie Barthés <j....@oodrive.fr>.
"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
>>>>>> <Valve
>>>>>> 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
>>>
>>> ...
>>>
>>>> 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-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Issue with RewriteValve and folders (tomcat 8.0.15)
Posted by Jérémie Barthés <j....@oodrive.fr>.
Le 20/02/2015 11:22, Rémy Maucherat a écrit :
> 2015-02-20 10:31 GMT+01:00 Jérémie Barthés <j....@oodrive.fr>:
>
>> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Issue with RewriteValve and folders (tomcat 8.0.15)
Posted by Rémy Maucherat <re...@apache.org>.
2015-02-20 10:31 GMT+01:00 Jérémie Barthés <j....@oodrive.fr>:
> 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)
Posted by Jérémie Barthés <j....@oodrive.fr>.
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
>>>>> <Valve
>>>>> 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
>>
>> ...
>>
>>> 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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Issue with RewriteValve and folders (tomcat 8.0.15)
Posted by Felix Schumacher <fe...@internetallee.de>.
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
>>>> <Valve
>>>> 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
>
> ...
>
>> 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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Issue with RewriteValve and folders (tomcat 8.0.15)
Posted by Rainer Jung <ra...@kippdata.de>.
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
>>> <Valve
>>> 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
...
> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Issue with RewriteValve and folders (tomcat 8.0.15)
Posted by Felix Schumacher <fe...@internetallee.de>.
Am 20. Februar 2015 00:43:40 MEZ, schrieb "André Warnier" <aw...@ice-sa.com>:
>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-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Issue with RewriteValve and folders (tomcat 8.0.15)
Posted by André Warnier <aw...@ice-sa.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Issue with RewriteValve and folders (tomcat 8.0.15)
Posted by André Warnier <aw...@ice-sa.com>.
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
>>> <Valve
>>> 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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Issue with RewriteValve and folders (tomcat 8.0.15)
Posted by Felix Schumacher <fe...@internetallee.de>.
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
>> <Valve
>> 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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Issue with RewriteValve and folders (tomcat 8.0.15)
Posted by André Warnier <aw...@ice-sa.com>.
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
> <Valve
> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Issue with RewriteValve and folders (tomcat 8.0.15)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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 <Valve
> 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-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>>
>>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Issue with RewriteValve and folders (tomcat 8.0.15)
Posted by Jérémie Barthés <j....@oodrive.fr>.
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
<Valve
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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Issue with RewriteValve and folders (tomcat 8.0.15)
Posted by Jérémie Barthés <j....@oodrive.fr>.
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Issue with RewriteValve and folders (tomcat 8.0.15)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Issue with RewriteValve and folders (tomcat 8.0.15)
Posted by Jérémie Barthés <j....@oodrive.fr>.
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-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>>
>>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Issue with RewriteValve and folders (tomcat 8.0.15)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Issue with RewriteValve and folders (tomcat 8.0.15)
Posted by Jérémie Barthés <j....@oodrive.fr>.
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Issue with RewriteValve and folders (tomcat 8.0.15)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org