Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@apache.org Received: (qmail 72504 invoked from network); 3 May 2002 12:55:51 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 3 May 2002 12:55:51 -0000 Received: (qmail 28257 invoked by uid 97); 3 May 2002 12:55:46 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-dev@nagoya.betaversion.org Received: (qmail 28154 invoked by alias); 3 May 2002 12:55:45 -0000 Delivered-To: jakarta-archive-tomcat-dev@jakarta.apache.org Received: (qmail 28102 invoked by uid 97); 3 May 2002 12:55:44 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Developers List" Reply-To: "Tomcat Developers List" Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 28086 invoked by uid 98); 3 May 2002 12:55:44 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Sender: glenn@zathras.earthdome.org Message-ID: <3CD288F9.C8CBB4E3@voyager.apg.more.net> Date: Fri, 03 May 2002 07:56:25 -0500 From: Glenn Nielsen X-Mailer: Mozilla 4.74 [en] (X11; U; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Tomcat Developers List Subject: Re: SSI Servlet has big problems References: <3CCFA08B.5060005@cs.stanford.edu> <001e01c1f102$31ef9ce0$6501a8c0@apache.org> <3CD0C2FB.1040101@cs.stanford.edu> <3CD20CF0.8020601@cs.stanford.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Dan Sandberg wrote: > > I'll be done with the SSI rewrite tomorrow. > > I'd like to get the community's advice on a number of issues: > > 1-I changed the names of the files from Ssi... to SSI... This seems to > be more consistent with the naming scheme of other files, and made > things easier for me since I did a gradual rewrite of everything. This > will make it harder to see what I changed when I submit a diff, > however. I changed 75% of everything, so I'm not sure this matters. Is > it ok? > Thats fine, please put the SSI servlet code into a sub package in servlet also. i.e. org.apache.catalina.servlet.ssi.*. > 2-What's the story with the SSI jar having the .renametojar extension? > I'm surmising that this is because this class will be loaded under the > system class loader rather than the user servlet class loader, causing > the #exec functionality to be a security risk. Can't we just have a > directory where we put servlets that should be loaded under the 'safe' > class loader? > Yes, this is so SSI can not be used without the admin explicitely enabling it by renaming the jar. Whether the Runtime.exec() method can be called is dependent upon the catalina.policy, not on what ClassLoader is used. I have proposed a reorganization of the servlets into sub packages in org.apache.catalina.servlets. In addition moving the jar files for the servlets into a separate directory. /server/servlets for those which require access to privileged internal catalina code, and /shared/servlets for those which do not require access to privileged catalina code. > 3-Right now the SSIServlet has an initialization parameter to determine > whether unsupported commands ( #foobar ) should be ignored. It seems > like the issue should be more complicated than this. There is a > difference between #foobar and #if. #foobar is not supported by anyone, > and should be handled the same way apache would do it ( echo an error ). > #if however, IS handled by apache, and is not handled by the > SSIServlet. Therefore it seems that the initialization parameter > mentioned should only apply to the latter case. Personally I think this > initialization parameter should be axed completely, as I don't see where > its use solves more problems that it creates. For example, if a person > did have code that used #if, #else, etc., then by ignoring these > directives we'd end up making the output be even weirder ( and with no > explanation of why! ) than if we just stuck [an error occurred while > processing this directive] all over the place. > > 4-Right now we are not logging invalid atribute names ( --#echo > nonExistantAttribute="foobar" -- ), or logging invalid commands, or > logging invalid settings for attributes ( --#echo > encoding="noSuchEncoding" var="DOCUMENT_NAME" -- ). Apache logs this > stuff, it seems like we should too. Where do I log it to ( what > classes/methods do I use )? Should there be a way to turn this logging off? > > 5-The command <#echo var='SOMETHING'> is not too useful right now, > because what SOMETHING can be is highly constrained. > I'd like to make so that this command searches the request attributes ( > for a variable named SOMETHING ). This will make this servlet more > useful when writing filters that use it. More importantly, it lets > existing users who are using SSI already have more power without needing > to rewrite their .shtml files in .jsp. [The company that I consult for > said they would find this useful, so I'm not making this up] I'd like to > also implement the #set command, so that it sets a variable in the > request. Anyone have objections to this? > > 6-This servlet has the option of being buffered or unbuffered. Can > someone explain to me why this is useful? The SSIServlet should never > throw an error, so I don't see why this would matter. > > Thanks, > > Dan > > -- > To unsubscribe, e-mail: > For additional commands, e-mail: -- ---------------------------------------------------------------------- Glenn Nielsen glenn@more.net | /* Spelin donut madder | MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | ---------------------------------------------------------------------- -- To unsubscribe, e-mail: For additional commands, e-mail: