tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Derrick Koes" <>
Subject Regression -- jakarta-tomcat-connectors/jk/native/common jk_uri_worker_map.c
Date Tue, 14 Jun 2005 15:28:21 GMT
The fix checked into CVS in December has regressed in JK 1.2.14.  URL rewriting no longer works
with JK 1.2.14.

Has anyone else experienced the regression?


-----Original Message-----
From: Derrick Koes 
Sent: Friday, December 17, 2004 3:33 PM
To: 'Tomcat Developers List'
Subject: another data point RE: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_uri_worker_map.c

The fix made early this morning (~7-8am Eastern) works to fix the problem I was having with
URL rewriting.
I'll grab the latest code set again soon and retry.

Thanks for your fast response on this Mladen.  JK2s eol is the impetus for my usage of JK
and this is the one glaring defect/difference I've found to this point.


-----Original Message-----
From: Mladen Turk []
Sent: Friday, December 17, 2004 2:59 PM
To: Tomcat Developers List
Subject: Re: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_uri_worker_map.c

Bill Barker wrote:
>>But since the request is supposed to be atomic why to strdup an uri?
>>I'd rather remove
>>char *uri = apr_pstrdup(r->pool, r->uri); before calling 
>>map_uri_to_worker then adding strdup to IIS.
> It was done to fix a '//' bypass traversal bug (e.g.
> http://myserver/myapp//foo.jsp would serve the source of the JSP).

Yep, but is that really the responsibility of the JK?
The jk is supposed to be a proxy, so as less intervention in the protocol the better results
will be.

I have comment out the jk_no2slash checking inside map_uri_to_worker cause found no difference
with or without it.


To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message