Why do you think, that
/myapp/%252e%252e/otherapp/danger
is equivalent to
/myapp/../otherapp/danger ?
Because it is on the Tomcat side and it ends up
as /otherapp/danger.
No it is not. If you send
/myapp/%252e%252e/otherapp/danger
to Tomcat, it will map the URL into the /myapp context (wh
Bill Barker wrote:
Now the reverse proxy should have the ability to modify the URI (in the
sense of mod_rewrite). If we accept, that mod_rewrite in httpd 1.3-2.2 is
only able to operate on the decoded URI, we have no chance of making this
interoperable with forwarding the original undecoded U
Rainer Jung wrote:
Before I answer, let me first ask a question: What's wrong withg my
suggestion? Or even better: use the encoding done with mod_proxy_ajp?
Because it doesn't solve the real problem.
Original URI:
/myapp/%252e%252e/otherapp/danger
JkMount /myapp/*
Apache httpd will corr
"Rainer Jung" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Jean-Frederic wrote:
>> On Sun, 2007-05-20 at 18:17 +0200, Rainer Jung wrote:
>>> Before I answer, let me first ask a question: What's wrong withg my
>>> suggestion?
>>
>> Well thinking to it I am not very happy with the
Jean-Frederic wrote:
On Sun, 2007-05-20 at 18:17 +0200, Rainer Jung wrote:
Before I answer, let me first ask a question: What's wrong withg my
suggestion?
Well thinking to it I am not very happy with the change:
+++
-#define JK_OPT_FWDURIDEFAULTJK_OPT_FWDURICOMPATUNPARSED
+#define JK_O
Well thinking to it I am not very happy with the change:
+++
-#define JK_OPT_FWDURIDEFAULTJK_OPT_FWDURICOMPATUNPARSED
+#define JK_OPT_FWDURIDEFAULTJK_OPT_FWDURIESCAPEDMINIMAL
+++
Because that is what the SPEC's says.
I doubt, that the SPEC is very relevant for the reverse proxy s
On Sun, 2007-05-20 at 18:17 +0200, Rainer Jung wrote:
> Before I answer, let me first ask a question: What's wrong withg my
> suggestion?
Well thinking to it I am not very happy with the change:
+++
-#define JK_OPT_FWDURIDEFAULTJK_OPT_FWDURICOMPATUNPARSED
+#define JK_OPT_FWDURIDEFAULT
Jean-Frederic wrote:
On Sun, 2007-05-20 at 18:17 +0200, Rainer Jung wrote:
Before I answer, let me first ask a question: What's wrong withg my
suggestion? Or even better: use the encoding done with mod_proxy_ajp?
For me there is nothing wrong except it adds 2 JKoptions or 3 :-)
If we think t
On Sun, 2007-05-20 at 18:17 +0200, Rainer Jung wrote:
> Before I answer, let me first ask a question: What's wrong withg my
> suggestion? Or even better: use the encoding done with mod_proxy_ajp?
For me there is nothing wrong except it adds 2 JKoptions or 3 :-)
We know that Tomcat is going to no
Before I answer, let me first ask a question: What's wrong withg my
suggestion? Or even better: use the encoding done with mod_proxy_ajp?
Original URI:
/myapp/%252e%252e/otherapp/danger
JkMount /myapp/*
Apache httpd will correctly decode the URI to
/myapp/%2e%2e/otherapp/danger
mod_jk does
Rainer Jung wrote:
Mladen Turk wrote:
Can you write a simple example of the uris that make the problem
and why we would need to encode the %.
How it is passed now, and how it would be passed with your
proposal.
Original URI:
/myapp/%252e%252e/otherapp/danger
JkMount /myapp/*
Apache httpd
Maybe that helps: mod_proxy_ajp (httpd 2.2.4) does something very similar.
In mod_proxy_ajp.c function proxy_ajp_canon() calls ap_proxy_canonenc().
This function for a reverse proxy request does encode a couple of chars
in the already decoded URI before forwarding it. It encodes all chars
exce
Mladen Turk wrote:
Rainer Jung wrote:
OK Mladen, I understand that, but I think it's not correct.
Might be.
But: none of the existing options does the right thing. That's why I
suggested another way of handling the forward. I think my sugeggested
variant "forward r->uri with encoded '%'"
Rainer Jung wrote:
OK Mladen, I understand that, but I think it's not correct.
Might be.
But: none of the existing options does the right thing. That's why I
suggested another way of handling the forward. I think my sugeggested
variant "forward r->uri with encoded '%'" is the right way of
Look, what I'm saying is that we should simplify all the JkOptions
ForwardURI* . IMHO they all originate from the fact that uri in the Apache
can come from multiple pre-processing stages that modify the original
URI. The solution is very simple but it would require that we write
the URI decoder. W
Rainer Jung wrote:
Mladen Turk wrote:
You got me wrong. I suggest we decode the encoded uri, do mapping,
remove ;jsessionid=xxx and send that to the Tomcat.
This way tomcat won't have double encoding issue.
And it's completely legitimate if we comply to the RFC.
This would also solve malicious
Mladen Turk wrote:
Jean-Frederic wrote:
What about url like /context-a/../context-b/?
There could be a problem if the goal is not to map /context-b.
Should we normalise /context-a/../context-b/ to /context-b and then do
the mapping.
Yes. It would require some programming of course, but
it'll
Jean-Frederic wrote:
What about url like /context-a/../context-b/?
There could be a problem if the goal is not to map /context-b.
Should we normalise /context-a/../context-b/ to /context-b and then do
the mapping.
If the *original* URI is "/context-a/../context-b/" then apache httpd
normalizes
Mladen Turk wrote:
You got me wrong. I suggest we decode the encoded uri, do mapping,
remove ;jsessionid=xxx and send that to the Tomcat.
This way tomcat won't have double encoding issue.
And it's completely legitimate if we comply to the RFC.
This would also solve malicious mapping attempts lik
Jean-Frederic wrote:
What about url like /context-a/../context-b/?
There could be a problem if the goal is not to map /context-b.
Should we normalise /context-a/../context-b/ to /context-b and then do
the mapping.
Yes. It would require some programming of course, but
it'll solve the issues wi
On Sat, 2007-05-19 at 18:57 +0200, Rainer Jung wrote:
> Jean-Frederic wrote:
> > On Sat, 2007-05-19 at 14:27 +0200, Rainer Jung wrote:
> >> Hi,
> >>
> >> now that we changed the default way how to forward URIs from mod_jk to
> >> Tomcat (mod_jk 1.2.23) because of a directory traversal issue, I wan
Rainer Jung wrote:
Mladen Turk wrote:
My proposal is that we make our own decoder if the URI is encoded
and then do a match and forward that.
As far as I understand you suggestion, this would not help.
There's nothing wrong with "our" decoder (the httpd decoder), what's
wrong is, that the de
Jean-Frederic wrote:
On Sat, 2007-05-19 at 14:27 +0200, Rainer Jung wrote:
Hi,
now that we changed the default way how to forward URIs from mod_jk to
Tomcat (mod_jk 1.2.23) because of a directory traversal issue, I want to
propose a better long term solution.
What's the problem?
===
On Sat, 2007-05-19 at 14:27 +0200, Rainer Jung wrote:
> Hi,
>
> now that we changed the default way how to forward URIs from mod_jk to
> Tomcat (mod_jk 1.2.23) because of a directory traversal issue, I want to
> propose a better long term solution.
>
> What's the problem?
> ===
Mladen Turk wrote:
My proposal is that we make our own decoder if the URI is encoded
and then do a match and forward that.
As far as I understand you suggestion, this would not help.
There's nothing wrong with "our" decoder (the httpd decoder), what's
wrong is, that the decoded URI gets decod
Rainer Jung wrote:
Hi,
now that we changed the default way how to forward URIs from mod_jk to
Tomcat (mod_jk 1.2.23) because of a directory traversal issue, I want to
propose a better long term solution.
My proposal is that we make our own decoder if the URI is encoded
and then do a match
26 matches
Mail list logo
