OK ... the prefix match mapping now makes sense to me (and runs faster than my
"longest prefix match" approach, which requires a scan of all registrations).  One
more quibble on the extension matching and I'll go away quietly :-)

In your pseudocode for parsing out the extension, you propose:

    String ext = path.substring(path.indexOf('.'), path.length())

which grabs everything from the *first* period on, and calls it the extension.
This still works for a request URI like:

    /dir1/dir2/file.html

but it will not work intuitively on a path like

    /dir.1/dir.2/file.html

(the name components just happen to have a period in them) which will consider
".1/dir.2/file.html" to be the extension, and (obviously) not match a servlet
mapped to ".html".

Would it make sense to specify that extension mapping starts at the *last* period,
instead of the first?  In other words, the parse line would say:

    String ext = path.substring(path.lastIndexOf('.'), path.length())

instead, and both URIs would map to the ".html" handling servlet.

I can see both sides of the argument about supporting extra path information when
doing extension matching (it might be nice to pass extra path information to a JSP
page, for exampe), but I can live without it (perhaps pass the extra stuff as a
query parameter instead).

Craig McClanahan



James Duncan Davidson wrote:

> "Craig R. McClanahan" wrote:
> >
> > James Duncan Davidson wrote:
> >
> > > >  - map a servlet X to "/"
> > > >  - map a servlet Y to ".html"
> > > >  - map a servlet Z to "/file.html"
> > > >  - map a servlet A to "/catalog"
> > > >  - map a servlet B to "/catalog/foo"
> > > >
> > > >  - request "/file.html" should be served by Z
> > > >  - request "/foo.html" should be served by X
> > > >  - request "/catalog/foo/bar" should be served by B
> > > >
> > > > It would be nice if James Davidson can confirm this.
> > >
> > > As requested -- this is the way that the spec is intended to work.
> > >
> >
> > OK, now I have a question ... how does a servlet engine know the difference
> > between the mapping for servlet Z and servlet A?  In other words, is the
> > difference between a file mapping and a directory mapping because of the
> > existence of the period in the Z mapping, or what?
> >
> > I'm mostly concerned about how you tell the difference between an "individual
> > URL" match (which might be followed by some extra path information!) and a
> > "directory path" match.  For example, what would you do with
> > "
>
> But then /file.html is just a dir in the URL path... Not a file any
> more. Actually, technically, there is no such thing as  "file" in URL
> strings -- everything describes a resource. But that's neither here nor
> there.
>
> The way we really have it (the way that the rules describe, it's just
> non obvious on first read), is that we first treat the URL path as a '/'
> seperated list of tree nodes. We walk the list till we find a match.
> Note that doing this, we don't make any assumption about a node being a
> file or a directory. -- /catalog/foo/bar/index.html becomes a list of
> "catalog"+"foo"+"bar"+"index.html".
>
> If we don't get a match, then we look for a case where we can make an
> extension match -- now we are making some assumptions about the
> distinction between files and dirs in the URL space -- it's not exactly
> fair, but it's damn useful, so we do it.
>
> If we still don't get a match, we give up.
>
> > The rules that make the most sense to me are:
> > * "Longest prefix" match (except for "/"); else
> > * Extension match (which cannot include extra path info); else
> > * "/" match (i.e. the default servlet) if nothing else matches
> > without any special cases for exact pathname matching.
>
> The way these rules apply does pretty much this...
>
> How it's implemented in servletrunner is the following (this is
> pseudocode for clarity, not the actual code used in the impl!):
>
> String path = request.getRequestURI();
> ServletWrapper s = null;
> while (nomatch && path.length > 1) {
>     s = container.lookup(path);
>     if (s != null) {
>         nomatch=false;
>     } else {
>         path = path.substring(0, path.lastIndexOf("/"));
>     }
> }
> if (s == null) {
>     // see if path has a '.' in it, grab that and try to make
>     // an extension match
>     String ext = path.substring(path.indexOf('.'), path.length());
>     s = container.lookupOnExt(ext);
> }
> if (s == null) {
>     s = defaultServlet;
> }
>
> Given the rules above we'd do a search for a servlet on path
> "/file.html/extra/path/info" like:
>
>         /file.html/extra/path/info  --> No
>         /file.html/extra/path       --> No
>         /file.html/extra            --> No
>         /file.html                  --> Yes, cool
>
> So you get the behavior that you are describing the the way that you say
> the rules make sense....
>
> Have I totally scrambled you neurons? Or does this make sense? It is
> first thing in the morning for me after a long long night so I wont take
> offense if you say "What the heck are you talking about James!" :)
>
> .duncan
>
> ___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html

___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".

Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html

Reply via email to