tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Nielsen <gl...@voyager.apg.more.net>
Subject Re: SSI Servlet has big problems
Date Fri, 03 May 2002 12:56:25 GMT
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:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>

-- 
----------------------------------------------------------------------
Glenn Nielsen             glenn@more.net | /* Spelin donut madder    |
MOREnet System Programming               |  * if iz ina coment.      |
Missouri Research and Education Network  |  */                       |
----------------------------------------------------------------------

--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message