Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@jakarta.apache.org Received: (qmail 99481 invoked by uid 500); 13 Sep 2001 16:22:56 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: tomcat-dev@jakarta.apache.org Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 99463 invoked from network); 13 Sep 2001 16:22:56 -0000 Message-ID: <3BA0C13B.30906@sun.com> Date: Thu, 13 Sep 2001 16:22:51 +0200 From: Lars Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.3) Gecko/20010801 X-Accept-Language: en-us MIME-Version: 1.0 To: tomcat-dev@jakarta.apache.org Subject: Re: URI handling in tomcat 3.2.3 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Hi Marc, Thanks for you reply... Marc Saegesser wrote: > I agree that this URI handling sucks. I'm the one that > committed the change that made it happen and I still > think it sucks. However, allowing these encoded characters > opens some very large security problems. From what I understand, these security problems are all related to mapping URIs to filesystem paths. So how do you feel about doing this processing in the filesystem (default) servlet? > Also, even if TC 3.2.x allowed these characters, the resulting URL > wouldn't be portable because several other web servers impose the > same restrictions. > [400 with Apache 1.3.19] I think, if it is possible to do this in a better way while keeping up the protection there is no reason for copying the behaviour of httpd. However, if those security implications can not be handled in the file servlet like I mentioned before, I'd need to do some more thinking on this point. > If you need to pass this sort of data to a servlet (or CGI) the most > portable way is to simply use a query string. Yes, that sounds like a straight-forward solution. Unfortunatly the service that gets excuted here will access some document and return an html representation. This document contains relative references within the hierarchy represented by the 'wrapped' URI. for this to work with a browser, the request URI has to be used, because the client can not resolve relative references inside a query (why should it) I belive that there are many more use-cases where using URIs to represent hierachical names that do not map to files is desirable, espacialy in a servlet environment. In httpd, which's main work consists of serving file-system resources this might be viewed differently Cheers, Lars -- ---------------------------------------------------------------------- Lars Oppermann Sun Microsystems Software Engineer - Sun ONE Webtop Sachsenfeld 4 Phone: +49 40 23646 959 D-20097 Hamburg Fax: +49 40 23646 550 http://www.sun.com/webtop