tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remy Maucherat" <r...@apache.org>
Subject Re: [Catalina] Resources
Date Mon, 31 Jul 2000 19:38:48 GMT
> Remy Maucherat wrote:
>
> > java.lang.IllegalArgumentException: Context relative path
> > \jsp\dates\date.jsp must start with /
> >  at
> >
org.apache.tomcat.resources.ResourcesBase.validate(ResourcesBase.java:1107)
> >  at
> >
org.apache.tomcat.resources.FileResources.getRealPath(FileResources.java:165
> > )
> >  at
> >
org.apache.tomcat.core.ApplicationContext.getRealPath(ApplicationContext.jav
> > a:333)
> >  at
> >
org.apache.jasper.JspEngineContext.getRealPath(JspEngineContext.java:359)
> > <snip/>
> >
> > I guess the validate method has to be made more tolerant ...
>
> I'm OK with translating "\" to "/", I guess, but it should be done
> consistently,
> and very early in each of the spots validate() is already called --
> perhaps:
>
>     path = normalize(path);
>     validate(path);
>
> and the "normalize" method can do this change if it needs to.

I'll fix that this evening (unless you fix it before, of course).

> True ... but we can embed smartness in a properties file where the key
> is the
> URL scheme and the value is class name to use; basically the way
> Authenticators
> are looked up based on login method.  That way, people using Catalina
> can add
> custom extensions to the list of supported resource bases by defining
> their own
> URL scheme prefixes -- which they are going to have to do anyway to
> return
> something useful from getResource() -- and add a mapping to a property
> file with
> no changes to the code of ContextConfig.
>
> The default should be to use FileResources if we can't figure out
> anything
> else.  That covers the case where a relative or absolute pathname is
> used
> without the "file:" prefix.

All right, that makes sense.

> > [snip]
> > And if you look at my implementation, you'll notice that indeed I'm not
> > using it (and the getResourceBean method I planned to add is commented
out.
> > Basically, I read the code a bit too quickly.
>
> Let's go ahead and remove the code we don't need (including the unused
> imports),
> now that it is clear the code will not be required.
>
> As you probably saw, I added another patch that improves the speed of
> this
> parsing when it is done -- avoids StringTokenizer, and uses
> unsynchronized
> access to collection classes (because this is all local variables so
> there is no
> opportunity for multi thread access to cause problems).
>
> > > > I guess after all those changes are made, I'll have to do another
rounds
> > of
> > > > benchmarks :-)
> > >
> > > Should be interesting :-)
> >
> > Of course, the biggest gain would probably come if we started using some
> > buffer operations (arraycopy ...) to do most string operations.
>
> Yep, as long as we're talking byte arrays.  Once you start talking about
> Strings, we have to deal with the i18n issues, which (as Costin can
> attest to
> :-) get pretty sticky.

True.

> I thought about that one quite a bit.  Basically, we have to decide
> whether we
> want the user to be able to modify files in the docBase directory, and
> have
> those changes recognized even when the old version was cached.  The way
> to
> detect changes seems to be to flow through the cache for the "last
> modified"
> check (although you can probably use any cached value for the file
> length safely
> -- modifying this will have set the last modified date anyway).

In the cache I had in in DefaultServlet, the entries were valid for 30s,
after which they had to be revalidated.

> For JarResources, I explicitly assumed (as stated in the class comments
> in the
> Javadoc) that you won't be trying to modify the JAR file while the app
> is
> running -- if you want to change things, you need to restart the app.
> That's
> why it pre-caches all the file and directory entries out of the JAR, and
> only
> caches the data according to the cacheable() policy.

Well, I'm pretty much neutral on caching policies. However, the more
aggressive we are, the better the benchmarks. Perhaps we could have
configuration options for this so that the user could tweak for performance
once the website is put in production (IIS has options like this) ?

> > The servlets benchs went down a bit lately (around 5% overall). The
> > benchmark I use doesn't use the "language" header, so there was no
> > improvements because of that, but I'm sure the real world performance
went
> > up quite a bit.
> >
> > >   * Leave out any entries for WEB-INF and META-INF (trying to follow
the
> > >     links would fail anyway, so there is no reason to show them)
> >
> > Actually, that was working, but I think it's a security problem to
display
> > them.
> >
>
> Yep ... they no longer display.  I also cleaned up a few other details
> that
> weren't quite right in the rendered HTML.

Some shading problems at the top of the table.

> > I found a problem with the rewriting of some characters in the URL.
"%20" is
> > no longer converted into " " (I think it was working at one point, but I
> > can't really remember. I added that in ResourcesBase.normalize. Do you
think
> > it's the right place for that ?
> > If you're +1, I'm committing the (very small) fix.
>
> +1 to fix (i.e. URL encode) the hyperlink that is part of the "<a
> href="xxxx">
> element.  The displayed filename should still have the spaces in it.

Right. I forgot to fix the link ...

> > I'll work on the WebDAV servlet for the immediate future.
> > Propfind is already done, so you can browse the site using Webfolders.
>
> Cool.

I'll try to have PUT and the namespace operations (mkcol, copy, move,
delete) working soon.

Remy


Mime
View raw message