----- Original Message -----
From: "Mladen Turk" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Friday, December 17, 2004 9:34 AM
Subject: Re: cvs commit: jakarta-tomcat-connectors/jk/native/common
jk_uri_worker_map.c


> Bill Barker wrote:
> >>
> >> No, it's not related to IIS at all.
> >>
> >
> > Of course it is related to IIS, since IIS is the only one that (wrongly)
> > doesn't pass a copy of the URI to map_uri_to_worker
> >
>
> OK. Seems that you catch me on that :).
>
> 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).
map_uri_to_worker calls jk_no2slash, which modifies the URI in ways that are
hard to undo.  The reason that the call is done outside of map_uri_to_worker
is simply that apr_pstrdup is better than jk_pool_strdup.  Otherwise, it's
trying to be like location_walk in Apache.

In the case of IIS, something like:
  char temp_uri[INTERNET_MAX_URL_LENGTH];
  strcpy(temp_uri, uri);
  worker = map_uri_to_worker(uw_map, temp_uri, logger);

is probably no worse than the rest of the code :).  However, I kept breaking
IIS whenever I tried to change things in it, so I just gave up at some
point.

>
> Regards,
> Mladen.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>



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.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to