Re: Volunteers for: - RE: TC 3.3: getRequestURI()
Bojan Smojver wrote: [EMAIL PROTECTED] wrote: I don't think I can do this alone ( if it sounded like I volunteer to fix it - well, I need help ). - Test. I'm one of those overly brave and too stupid that put CVS versions of software in production environment. Promise to give it a bashing within my applications. My first tests show that today's version of both Tomcat 3.3 and mod_jk that comes with it are fine on this issue. Hurray! Bojan PS. OK, let's move this baby to production server... ;-)
RE: Volunteers for: - RE: TC 3.3: getRequestURI()
- Revert jk/apache to use uri, remove the encode call ( again, j-t and
j-t-c - one more week to do that, after that we'll be j-t-c
only ). Henri
- could you do this and the next one ?
I'll reintroduce the JkOptions which will help us play with
different encoding :
ForwardStandardURI :
will send just std uri
s-req_uri = r-uri
ForwardEscapedURI :
will send escaped
s-req_uri = ap_escape_uri(r-uri))
ForwardUnparsedURI :
will send escaped
s-req_uri = r-unparsed_uri;
if (s-req_uri != NULL) {
char *query_str = strchr(s-req_uri, '?');
if (query_str != NULL) {
*query_str = 0;
}
We could later drop support for some options
and make by default ForwardEscapedURI
RE: Volunteers for: - RE: TC 3.3: getRequestURI()
Henri, I do not think this will be useful
or necessary with the planned changes. I'd
be -1.
r-uri will be used, making the mod_rewrite
folks happy, and the facade will encode the
uri, which implements the spec correctly.
Does this plan break something, the reason
you want to add an Option?
Keith
| -Original Message-
| From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
| Sent: Monday, October 01, 2001 5:18 AM
| To: [EMAIL PROTECTED]
| Subject: RE: Volunteers for: - RE: TC 3.3: getRequestURI()
|
|
|
| - Revert jk/apache to use uri, remove the encode call ( again, j-t and
| j-t-c - one more week to do that, after that we'll be j-t-c
| only ). Henri
| - could you do this and the next one ?
|
| I'll reintroduce the JkOptions which will help us play with
| different encoding :
|
| ForwardStandardURI :
|
| will send just std uri
|
| s-req_uri = r-uri
|
|
| ForwardEscapedURI :
|
| will send escaped
|
| s-req_uri = ap_escape_uri(r-uri))
|
|
| ForwardUnparsedURI :
|
| will send escaped
|
| s-req_uri = r-unparsed_uri;
| if (s-req_uri != NULL) {
| char *query_str = strchr(s-req_uri, '?');
| if (query_str != NULL) {
| *query_str = 0;
| }
|
| We could later drop support for some options
| and make by default ForwardEscapedURI
|
RE: Volunteers for: - RE: TC 3.3: getRequestURI()
Henri, I do not think this will be useful
or necessary with the planned changes. I'd
be -1.
r-uri will be used, making the mod_rewrite
folks happy, and the facade will encode the
uri, which implements the spec correctly.
Does this plan break something, the reason
you want to add an Option?
The idea is to conserve compatibility with
Tomcat 3.2.x and Tomcat 4.0 until they have
their java side implementing the required stuff.
Keith
| -Original Message-
| From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
| Sent: Monday, October 01, 2001 5:18 AM
| To: [EMAIL PROTECTED]
| Subject: RE: Volunteers for: - RE: TC 3.3: getRequestURI()
|
|
|
| - Revert jk/apache to use uri, remove the encode call (
again, j-t and
| j-t-c - one more week to do that, after that we'll be j-t-c
| only ). Henri
| - could you do this and the next one ?
|
| I'll reintroduce the JkOptions which will help us play with
| different encoding :
|
| ForwardStandardURI :
|
| will send just std uri
|
| s-req_uri = r-uri
|
|
| ForwardEscapedURI :
|
| will send escaped
|
| s-req_uri = ap_escape_uri(r-uri))
|
|
| ForwardUnparsedURI :
|
| will send escaped
|
| s-req_uri = r-unparsed_uri;
| if (s-req_uri != NULL) {
| char *query_str = strchr(s-req_uri, '?');
| if (query_str != NULL) {
| *query_str = 0;
| }
|
| We could later drop support for some options
| and make by default ForwardEscapedURI
|
RE: Volunteers for: - RE: TC 3.3: getRequestURI()
What whould happen in 3.3 if ForwardEscapedURI was chosen?
Wouldn't the facade escape it again?
Keith
| -Original Message-
| From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
| Sent: Monday, October 01, 2001 10:10 AM
| To: [EMAIL PROTECTED]
| Subject: RE: Volunteers for: - RE: TC 3.3: getRequestURI()
|
|
| Henri, I do not think this will be useful
| or necessary with the planned changes. I'd
| be -1.
|
| r-uri will be used, making the mod_rewrite
| folks happy, and the facade will encode the
| uri, which implements the spec correctly.
|
| Does this plan break something, the reason
| you want to add an Option?
|
| The idea is to conserve compatibility with
| Tomcat 3.2.x and Tomcat 4.0 until they have
| their java side implementing the required stuff.
|
|
| Keith
|
|
| | -Original Message-
| | From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
| | Sent: Monday, October 01, 2001 5:18 AM
| | To: [EMAIL PROTECTED]
| | Subject: RE: Volunteers for: - RE: TC 3.3: getRequestURI()
| |
| |
| |
| | - Revert jk/apache to use uri, remove the encode call (
| again, j-t and
| | j-t-c - one more week to do that, after that we'll be j-t-c
| | only ). Henri
| | - could you do this and the next one ?
| |
| | I'll reintroduce the JkOptions which will help us play with
| | different encoding :
| |
| | ForwardStandardURI :
| |
| | will send just std uri
| |
| | s-req_uri = r-uri
| |
| |
| | ForwardEscapedURI :
| |
| | will send escaped
| |
| | s-req_uri = ap_escape_uri(r-uri))
| |
| |
| | ForwardUnparsedURI :
| |
| | will send escaped
| |
| | s-req_uri = r-unparsed_uri;
| | if (s-req_uri != NULL) {
| | char *query_str = strchr(s-req_uri, '?');
| | if (query_str != NULL) {
| | *query_str = 0;
| | }
| |
| | We could later drop support for some options
| | and make by default ForwardEscapedURI
| |
|
RE: Volunteers for: - RE: TC 3.3: getRequestURI()
What whould happen in 3.3 if ForwardEscapedURI was chosen? Wouldn't the facade escape it again? My goal in mod_jk is to keep compatibility with ALL tomcat release, TC 3.2, 3.3 and 4.0. The option will let us configure it, even if by default mod_jk found in TC 3.3 and J-T-C will use the TC 3.3 collaborative scheme (part in Native and part in Java). Let's note that the JkOptions are only available in Apache 1.3/2.0 and such flags could be needed also in IIS/NES/DOMINO
RE: Volunteers for: - RE: TC 3.3: getRequestURI()
Why can't we implement the 3.3 collaborative solution in 4.0 ? That would maintain compatibility. I just hate to provide an option which could result in wrong (double escaped) behavior. At the least, it's one more variable to debug, at worst, it will generate erroneous bug reports. I'd hesitate to add it. Keith | -Original Message- | From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] | Sent: Monday, October 01, 2001 10:35 AM | To: [EMAIL PROTECTED] | Subject: RE: Volunteers for: - RE: TC 3.3: getRequestURI() | | | What whould happen in 3.3 if ForwardEscapedURI was chosen? | Wouldn't the facade escape it again? | | | My goal in mod_jk is to keep compatibility with ALL tomcat | release, TC 3.2, 3.3 and 4.0. | | The option will let us configure it, even if by default | mod_jk found in TC 3.3 and J-T-C will use the TC 3.3 | collaborative scheme (part in Native and part in Java). | | Let's note that the JkOptions are only available in Apache | 1.3/2.0 and such flags could be needed also in IIS/NES/DOMINO |
RE: Volunteers for: - RE: TC 3.3: getRequestURI()
Why can't we implement the 3.3 collaborative solution in 4.0 ? That would maintain compatibility. And also in TC 3.2.4 ? I just hate to provide an option which could result in wrong (double escaped) behavior. At the least, it's one more variable to debug, at worst, it will generate erroneous bug reports. I'd hesitate to add it. The Option could be hidden and use the TC 3.3 behaviour by default... | -Original Message- | From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] | Sent: Monday, October 01, 2001 10:35 AM | To: [EMAIL PROTECTED] | Subject: RE: Volunteers for: - RE: TC 3.3: getRequestURI() | | | What whould happen in 3.3 if ForwardEscapedURI was chosen? | Wouldn't the facade escape it again? | | | My goal in mod_jk is to keep compatibility with ALL tomcat | release, TC 3.2, 3.3 and 4.0. | | The option will let us configure it, even if by default | mod_jk found in TC 3.3 and J-T-C will use the TC 3.3 | collaborative scheme (part in Native and part in Java). | | Let's note that the JkOptions are only available in Apache | 1.3/2.0 and such flags could be needed also in IIS/NES/DOMINO |
RE: Volunteers for: - RE: TC 3.3: getRequestURI()
I thought you were talking about the mod_jk in the TC3.3 branch. If you're talking j-t-c only, then I don't mind an Option, as long as it defaults to the 3.3 behavior. Keith | -Original Message- | From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] | Sent: Monday, October 01, 2001 11:24 AM | To: [EMAIL PROTECTED] | Subject: RE: Volunteers for: - RE: TC 3.3: getRequestURI() | | | Why can't we implement the 3.3 collaborative solution in 4.0 ? | That would maintain compatibility. | | And also in TC 3.2.4 ? | | I just hate to provide an option which could result | in wrong (double escaped) behavior. At the least, | it's one more variable to debug, at worst, it will | generate erroneous bug reports. I'd hesitate to | add it. | | The Option could be hidden and use the TC 3.3 behaviour | by default...
RE: Volunteers for: - RE: TC 3.3: getRequestURI()
I done some works for both TC 3.3 and J-T-C, since the both tree will live for at least some month. And J-T-C will be used for TC 3.3, 4.0 and also good old TC 3.2.3 ;) I'll commit the change which use TC 3.3 behaviour by default but allow us to fall-back in compatibility mode for old TCs. - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Keith Wannamaker [mailto:[EMAIL PROTECTED]] Sent: Monday, October 01, 2001 10:52 PM To: [EMAIL PROTECTED] Subject: RE: Volunteers for: - RE: TC 3.3: getRequestURI() I thought you were talking about the mod_jk in the TC3.3 branch. If you're talking j-t-c only, then I don't mind an Option, as long as it defaults to the 3.3 behavior. Keith | -Original Message- | From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] | Sent: Monday, October 01, 2001 11:24 AM | To: [EMAIL PROTECTED] | Subject: RE: Volunteers for: - RE: TC 3.3: getRequestURI() | | | Why can't we implement the 3.3 collaborative solution in 4.0 ? | That would maintain compatibility. | | And also in TC 3.2.4 ? | | I just hate to provide an option which could result | in wrong (double escaped) behavior. At the least, | it's one more variable to debug, at worst, it will | generate erroneous bug reports. I'd hesitate to | add it. | | The Option could be hidden and use the TC 3.3 behaviour | by default...
Re: Volunteers for: - RE: TC 3.3: getRequestURI()
Actually, my original was a straight java.net.URLEncode after stripping out the session id. However, I'm easy. Attached is using UEncoder (which I initially felt was too expensive). I'm starting to come around to your original idea however. This is better done in the Facade (where there is zero hit for pages that don't ask for RequestURI). Currently, nobody uses unparsedURI, and it is arguably a protocol violation if a servlet serves different pages for equivalent URIs - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED]; Bill Barker [EMAIL PROTECTED] Sent: Sunday, September 30, 2001 1:23 AM Subject: Re: Volunteers for: - RE: TC 3.3: getRequestURI() On Sat, 29 Sep 2001, Bill Barker wrote: It seems that I must have been bad in a past life, since my Karma isn't high enough.:) I've added the code to re-encode the URL to DecodeInterceptor on my machine. If you want it right away, I can post a diff. Hi, Could you send the diff, I'll have to merge it with my changes anyway... ( I hope you found UEncoder and used it, because that's what I did ). I am now thinking about how to encode the context path - which is more difficult than I tought. The problem is of course that we don't know the charset in many cases, and Context.getPath() returns the UTF version. If we encode this - it may be inconsistent with the original request encoding. So I'll try to count the '/' and return a substring of the uri - I can't think of any better way. Of course, I have no idea why the contextPath has to be encoded - poor people using the contextPath as a key will have a bad surprise since you can have multiple representations for the same context ( based on the charset of the request ), but as usual we ( 8859_1 uses ) are ok. I can leave this the way it is, as it makes more sense ( and 2.2 doesn't seem to require the context path to be encoded) - and wait until 4.0 fixes that ( beeing consistent with 2.3 doesn't seem a good idea in this case ). I'm not sure, need to look deeper at the specs and impl. Costin - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 28, 2001 11:17 AM Subject: Volunteers for: - RE: TC 3.3: getRequestURI() It seems most agree on using 'decoded' URI in mod_jk. Making the change is not easy, there are few places where we need to coordinate and make sure we're on the same page. I don't think I can do this alone ( if it sounded like I volunteer to fix it - well, I need help ). Problems: - Someone with IIS must cutpaste the decoding stuff from Apache ( probably in jk/common ), make sure the uri sent is decoded ( so consistent with Apache and NES ). That should happen in j-t and j-t-c ( with this ocasion we'll help Marc a bit :-) - One piece is to implement the java side of the decoding. I can do that if nobody else wants ( I have few other bugs in work, so I'll probably do it tommorow ). - I'll fix DecodeInterceptor to avoid double decoding ( I'm already fixing the normalization for JNI ). - Someone should check 4.0. Strange, even if this is a 2.3 requirement I didn't see any comment so far... Well, they have cool features and jars to add, so I can do that if nobody else does. - Revert jk/apache to use uri, remove the encode call ( again, j-t and j-t-c - one more week to do that, after that we'll be j-t-c only ). Henri - could you do this and the next one ? - Build and make some jars available - so we can test. - Test. Yes, it's a long list - but at the end we might solve one of the trickiest problems. Costin 2. mod_jk will send the 'decoded' URI ( %xx replaced with the real char ). On IIS - we need to decode the URI, Apache+NES - nothing to do. On java side - we do a 'canonical' encoding in the facade. All the code will operate on the decoded request ( this is what Apache and NES are doing ). We also need to prevent DecodeInterceptor to re-decode the URIs from jk. ( that's trivial, just a flag ) Benefits: - consistency with Apache, all processing on decoded uris. - easier to maintain ( java :-) - important - servlets will get a consistently encoded uri, thus preventing many security problems. With the current code many tricks can be played ( see recent security problems in tomcat ) using encoding - if we were vulnerable to that, I suspect most servlet authors will be as well. Problems: - a bit more work to do. - the 'original' uri will not be preserved in any servers ( the first solution allows that for IIS and standalone ). Your votes please, I'm ok with any of them ( with a slight preference to 2 ) Costin On Thu, 27 Sep 2001, Larry Isaacs wrote: -Original Message- From: [EMAIL PROTECTED] [mailto
Re: Volunteers for: - RE: TC 3.3: getRequestURI()
What I get for trying to do this on a computer without javac installed. Diff file with typos fixed and exceptions handled. - Original Message - From: Bill Barker [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Bill Barker [EMAIL PROTECTED] Sent: Sunday, September 30, 2001 12:40 AM Subject: Re: Volunteers for: - RE: TC 3.3: getRequestURI() Actually, my original was a straight java.net.URLEncode after stripping out the session id. However, I'm easy. Attached is using UEncoder (which I initially felt was too expensive). I'm starting to come around to your original idea however. This is better done in the Facade (where there is zero hit for pages that don't ask for RequestURI). Currently, nobody uses unparsedURI, and it is arguably a protocol violation if a servlet serves different pages for equivalent URIs - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED]; Bill Barker [EMAIL PROTECTED] Sent: Sunday, September 30, 2001 1:23 AM Subject: Re: Volunteers for: - RE: TC 3.3: getRequestURI() On Sat, 29 Sep 2001, Bill Barker wrote: It seems that I must have been bad in a past life, since my Karma isn't high enough.:) I've added the code to re-encode the URL to DecodeInterceptor on my machine. If you want it right away, I can post a diff. Hi, Could you send the diff, I'll have to merge it with my changes anyway... ( I hope you found UEncoder and used it, because that's what I did ). I am now thinking about how to encode the context path - which is more difficult than I tought. The problem is of course that we don't know the charset in many cases, and Context.getPath() returns the UTF version. If we encode this - it may be inconsistent with the original request encoding. So I'll try to count the '/' and return a substring of the uri - I can't think of any better way. Of course, I have no idea why the contextPath has to be encoded - poor people using the contextPath as a key will have a bad surprise since you can have multiple representations for the same context ( based on the charset of the request ), but as usual we ( 8859_1 uses ) are ok. I can leave this the way it is, as it makes more sense ( and 2.2 doesn't seem to require the context path to be encoded) - and wait until 4.0 fixes that ( beeing consistent with 2.3 doesn't seem a good idea in this case ). I'm not sure, need to look deeper at the specs and impl. Costin - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 28, 2001 11:17 AM Subject: Volunteers for: - RE: TC 3.3: getRequestURI() It seems most agree on using 'decoded' URI in mod_jk. Making the change is not easy, there are few places where we need to coordinate and make sure we're on the same page. I don't think I can do this alone ( if it sounded like I volunteer to fix it - well, I need help ). Problems: - Someone with IIS must cutpaste the decoding stuff from Apache ( probably in jk/common ), make sure the uri sent is decoded ( so consistent with Apache and NES ). That should happen in j-t and j-t-c ( with this ocasion we'll help Marc a bit :-) - One piece is to implement the java side of the decoding. I can do that if nobody else wants ( I have few other bugs in work, so I'll probably do it tommorow ). - I'll fix DecodeInterceptor to avoid double decoding ( I'm already fixing the normalization for JNI ). - Someone should check 4.0. Strange, even if this is a 2.3 requirement I didn't see any comment so far... Well, they have cool features and jars to add, so I can do that if nobody else does. - Revert jk/apache to use uri, remove the encode call ( again, j-t and j-t-c - one more week to do that, after that we'll be j-t-c only ). Henri - could you do this and the next one ? - Build and make some jars available - so we can test. - Test. Yes, it's a long list - but at the end we might solve one of the trickiest problems. Costin 2. mod_jk will send the 'decoded' URI ( %xx replaced with the real char ). On IIS - we need to decode the URI, Apache+NES - nothing to do. On java side - we do a 'canonical' encoding in the facade. All the code will operate on the decoded request ( this is what Apache and NES are doing ). We also need to prevent DecodeInterceptor to re-decode the URIs from jk. ( that's trivial, just a flag ) Benefits: - consistency with Apache, all processing on decoded uris. - easier to maintain ( java :-) - important - servlets will get a consistently encoded uri, thus preventing many security problems. With the current code many tricks can be played ( see recent security problems in tomcat ) using encoding - if we were vulnerable
Re: Volunteers for: - RE: TC 3.3: getRequestURI()
Thanks Bill. I'll merge this with my changes and check in. Costin On Sun, 30 Sep 2001, Bill Barker wrote: What I get for trying to do this on a computer without javac installed. Diff file with typos fixed and exceptions handled. - Original Message - From: Bill Barker [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Bill Barker [EMAIL PROTECTED] Sent: Sunday, September 30, 2001 12:40 AM Subject: Re: Volunteers for: - RE: TC 3.3: getRequestURI() Actually, my original was a straight java.net.URLEncode after stripping out the session id. However, I'm easy. Attached is using UEncoder (which I initially felt was too expensive). I'm starting to come around to your original idea however. This is better done in the Facade (where there is zero hit for pages that don't ask for RequestURI). Currently, nobody uses unparsedURI, and it is arguably a protocol violation if a servlet serves different pages for equivalent URIs - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED]; Bill Barker [EMAIL PROTECTED] Sent: Sunday, September 30, 2001 1:23 AM Subject: Re: Volunteers for: - RE: TC 3.3: getRequestURI() On Sat, 29 Sep 2001, Bill Barker wrote: It seems that I must have been bad in a past life, since my Karma isn't high enough.:) I've added the code to re-encode the URL to DecodeInterceptor on my machine. If you want it right away, I can post a diff. Hi, Could you send the diff, I'll have to merge it with my changes anyway... ( I hope you found UEncoder and used it, because that's what I did ). I am now thinking about how to encode the context path - which is more difficult than I tought. The problem is of course that we don't know the charset in many cases, and Context.getPath() returns the UTF version. If we encode this - it may be inconsistent with the original request encoding. So I'll try to count the '/' and return a substring of the uri - I can't think of any better way. Of course, I have no idea why the contextPath has to be encoded - poor people using the contextPath as a key will have a bad surprise since you can have multiple representations for the same context ( based on the charset of the request ), but as usual we ( 8859_1 uses ) are ok. I can leave this the way it is, as it makes more sense ( and 2.2 doesn't seem to require the context path to be encoded) - and wait until 4.0 fixes that ( beeing consistent with 2.3 doesn't seem a good idea in this case ). I'm not sure, need to look deeper at the specs and impl. Costin - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 28, 2001 11:17 AM Subject: Volunteers for: - RE: TC 3.3: getRequestURI() It seems most agree on using 'decoded' URI in mod_jk. Making the change is not easy, there are few places where we need to coordinate and make sure we're on the same page. I don't think I can do this alone ( if it sounded like I volunteer to fix it - well, I need help ). Problems: - Someone with IIS must cutpaste the decoding stuff from Apache ( probably in jk/common ), make sure the uri sent is decoded ( so consistent with Apache and NES ). That should happen in j-t and j-t-c ( with this ocasion we'll help Marc a bit :-) - One piece is to implement the java side of the decoding. I can do that if nobody else wants ( I have few other bugs in work, so I'll probably do it tommorow ). - I'll fix DecodeInterceptor to avoid double decoding ( I'm already fixing the normalization for JNI ). - Someone should check 4.0. Strange, even if this is a 2.3 requirement I didn't see any comment so far... Well, they have cool features and jars to add, so I can do that if nobody else does. - Revert jk/apache to use uri, remove the encode call ( again, j-t and j-t-c - one more week to do that, after that we'll be j-t-c only ). Henri - could you do this and the next one ? - Build and make some jars available - so we can test. - Test. Yes, it's a long list - but at the end we might solve one of the trickiest problems. Costin 2. mod_jk will send the 'decoded' URI ( %xx replaced with the real char ). On IIS - we need to decode the URI, Apache+NES - nothing to do. On java side - we do a 'canonical' encoding in the facade. All the code will operate on the decoded request ( this is what Apache and NES are doing ). We also need to prevent DecodeInterceptor to re-decode the URIs from jk. ( that's trivial, just a flag ) Benefits: - consistency with Apache, all processing on decoded uris. - easier to maintain
Re: Volunteers for: - RE: TC 3.3: getRequestURI()
It seems that I must have been bad in a past life, since my Karma isn't high enough.:) I've added the code to re-encode the URL to DecodeInterceptor on my machine. If you want it right away, I can post a diff. - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 28, 2001 11:17 AM Subject: Volunteers for: - RE: TC 3.3: getRequestURI() It seems most agree on using 'decoded' URI in mod_jk. Making the change is not easy, there are few places where we need to coordinate and make sure we're on the same page. I don't think I can do this alone ( if it sounded like I volunteer to fix it - well, I need help ). Problems: - Someone with IIS must cutpaste the decoding stuff from Apache ( probably in jk/common ), make sure the uri sent is decoded ( so consistent with Apache and NES ). That should happen in j-t and j-t-c ( with this ocasion we'll help Marc a bit :-) - One piece is to implement the java side of the decoding. I can do that if nobody else wants ( I have few other bugs in work, so I'll probably do it tommorow ). - I'll fix DecodeInterceptor to avoid double decoding ( I'm already fixing the normalization for JNI ). - Someone should check 4.0. Strange, even if this is a 2.3 requirement I didn't see any comment so far... Well, they have cool features and jars to add, so I can do that if nobody else does. - Revert jk/apache to use uri, remove the encode call ( again, j-t and j-t-c - one more week to do that, after that we'll be j-t-c only ). Henri - could you do this and the next one ? - Build and make some jars available - so we can test. - Test. Yes, it's a long list - but at the end we might solve one of the trickiest problems. Costin 2. mod_jk will send the 'decoded' URI ( %xx replaced with the real char ). On IIS - we need to decode the URI, Apache+NES - nothing to do. On java side - we do a 'canonical' encoding in the facade. All the code will operate on the decoded request ( this is what Apache and NES are doing ). We also need to prevent DecodeInterceptor to re-decode the URIs from jk. ( that's trivial, just a flag ) Benefits: - consistency with Apache, all processing on decoded uris. - easier to maintain ( java :-) - important - servlets will get a consistently encoded uri, thus preventing many security problems. With the current code many tricks can be played ( see recent security problems in tomcat ) using encoding - if we were vulnerable to that, I suspect most servlet authors will be as well. Problems: - a bit more work to do. - the 'original' uri will not be preserved in any servers ( the first solution allows that for IIS and standalone ). Your votes please, I'm ok with any of them ( with a slight preference to 2 ) Costin On Thu, 27 Sep 2001, Larry Isaacs wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 27, 2001 3:10 AM To: [EMAIL PROTECTED] Subject: RE: TC 3.3: getRequestURI() Given this is an important change - and something will be broken regardless of what we do - I think we need to coordinate and make sure we're doing it right. - First: Larry - what do you think ? We just had RC1, and we have already a simple patch ( changing SessionId to hide the problem ). My proposal is simple to implement ( just encode the URI on the facade, and use only decoded URIs internally ), but it is braking some of the 2.3 clarifications ( not mandatory for 2.2, of course, but important ) I'm leaning towards your encode in facade solution. I'm curious about the 2.3 clarifications you are referring to beyond the URI being the original. - Someone with access to NES and/or IIS, could you please verify if the requestUri variable in NSAPI/ISAPI is encoded or not ? Neither of them seems to provide the choice between unencoded_uri and uri, so whatever they provide is the only thing we can use. I can try IIS easily enough. I'll also try to get NES running and see if I can determine this one too. I'll need to do this at home, so I'll report my results tonight. Larry I think the result of the test with IIS/NES is essential to resolving this problem once and for all. If the URI they provide is the 'original/or encoded' - that's what we should use on Apache side. If not ( and the URI is decoded ) - that means the 'original uri' is un-implementable, and we shouldn't worry about it anymore, and using the decoded URI consistently is the best solution. Please, (I know there aren't too many windows user around :-), could someone check this ? Costin ** This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information
Re: Volunteers for: - RE: TC 3.3: getRequestURI()
On Sat, 29 Sep 2001, Bill Barker wrote: It seems that I must have been bad in a past life, since my Karma isn't high enough.:) I've added the code to re-encode the URL to DecodeInterceptor on my machine. If you want it right away, I can post a diff. Hi, Could you send the diff, I'll have to merge it with my changes anyway... ( I hope you found UEncoder and used it, because that's what I did ). I am now thinking about how to encode the context path - which is more difficult than I tought. The problem is of course that we don't know the charset in many cases, and Context.getPath() returns the UTF version. If we encode this - it may be inconsistent with the original request encoding. So I'll try to count the '/' and return a substring of the uri - I can't think of any better way. Of course, I have no idea why the contextPath has to be encoded - poor people using the contextPath as a key will have a bad surprise since you can have multiple representations for the same context ( based on the charset of the request ), but as usual we ( 8859_1 uses ) are ok. I can leave this the way it is, as it makes more sense ( and 2.2 doesn't seem to require the context path to be encoded) - and wait until 4.0 fixes that ( beeing consistent with 2.3 doesn't seem a good idea in this case ). I'm not sure, need to look deeper at the specs and impl. Costin - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 28, 2001 11:17 AM Subject: Volunteers for: - RE: TC 3.3: getRequestURI() It seems most agree on using 'decoded' URI in mod_jk. Making the change is not easy, there are few places where we need to coordinate and make sure we're on the same page. I don't think I can do this alone ( if it sounded like I volunteer to fix it - well, I need help ). Problems: - Someone with IIS must cutpaste the decoding stuff from Apache ( probably in jk/common ), make sure the uri sent is decoded ( so consistent with Apache and NES ). That should happen in j-t and j-t-c ( with this ocasion we'll help Marc a bit :-) - One piece is to implement the java side of the decoding. I can do that if nobody else wants ( I have few other bugs in work, so I'll probably do it tommorow ). - I'll fix DecodeInterceptor to avoid double decoding ( I'm already fixing the normalization for JNI ). - Someone should check 4.0. Strange, even if this is a 2.3 requirement I didn't see any comment so far... Well, they have cool features and jars to add, so I can do that if nobody else does. - Revert jk/apache to use uri, remove the encode call ( again, j-t and j-t-c - one more week to do that, after that we'll be j-t-c only ). Henri - could you do this and the next one ? - Build and make some jars available - so we can test. - Test. Yes, it's a long list - but at the end we might solve one of the trickiest problems. Costin 2. mod_jk will send the 'decoded' URI ( %xx replaced with the real char ). On IIS - we need to decode the URI, Apache+NES - nothing to do. On java side - we do a 'canonical' encoding in the facade. All the code will operate on the decoded request ( this is what Apache and NES are doing ). We also need to prevent DecodeInterceptor to re-decode the URIs from jk. ( that's trivial, just a flag ) Benefits: - consistency with Apache, all processing on decoded uris. - easier to maintain ( java :-) - important - servlets will get a consistently encoded uri, thus preventing many security problems. With the current code many tricks can be played ( see recent security problems in tomcat ) using encoding - if we were vulnerable to that, I suspect most servlet authors will be as well. Problems: - a bit more work to do. - the 'original' uri will not be preserved in any servers ( the first solution allows that for IIS and standalone ). Your votes please, I'm ok with any of them ( with a slight preference to 2 ) Costin On Thu, 27 Sep 2001, Larry Isaacs wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 27, 2001 3:10 AM To: [EMAIL PROTECTED] Subject: RE: TC 3.3: getRequestURI() Given this is an important change - and something will be broken regardless of what we do - I think we need to coordinate and make sure we're doing it right. - First: Larry - what do you think ? We just had RC1, and we have already a simple patch ( changing SessionId to hide the problem ). My proposal is simple to implement ( just encode the URI on the facade, and use only decoded URIs internally ), but it is braking some of the 2.3 clarifications ( not mandatory for 2.2, of course, but important ) I'm leaning towards your encode in facade solution. I'm curious about
