tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Sandberg...@cs.stanford.edu>
Subject Re: SSI Servlet has big problems
Date Fri, 03 May 2002 04:07:12 GMT
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?

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?

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>


Mime
View raw message