tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <>
Subject Re: cvs commit: jakarta-tomcat-connectors/jk/native/common jk_uri_worker_map.c
Date Fri, 17 Dec 2004 20:22:44 GMT

----- Original Message -----
From: "Mladen Turk" <>
To: "Tomcat Developers List" <>
Sent: Friday, December 17, 2004 11:59 AM
Subject: Re: cvs commit: jakarta-tomcat-connectors/jk/native/common

> 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.

It's consistant with location_walk in Apache, so at least for is
seems to be pretty important that the uri mapping rules work the same way.
Without the consistancy, configuration for JK becomes even harder than for
JK2 :(.

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

Try with only:
JkMount /myapp/*.jsp

and requesting:

> Regards,
> Mladen.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

This message is intended only for the use of the person(s) listed above as the intended recipient(s),
and may contain information that is PRIVILEGED and CONFIDENTIAL.  If you are not an intended
recipient, you may not read, copy, or distribute this message or any attachment. If you received
this communication in error, please notify us immediately by e-mail and then delete all copies
of this message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet
is not secure. Do not send confidential or sensitive information, such as social security
numbers, account numbers, personal identification numbers and passwords, to us via ordinary
(unencrypted) e-mail.

View raw message