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()
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()
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()
>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()
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()
>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()
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()
>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()
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()
>- 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()
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 cut&paste 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 fe
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 cut&paste 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, rem
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 cut&paste 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 op
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 cut&paste 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 > > > >
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 cut&paste 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". > > >&