Sorry to respond to my own message but I see that I was trying to answer two
different messages in one.

Nic's approach of identifying an extension match based on a period that is NOT
followed by a slash will fail in both the second and third cases I quoted below,
not just the third.  I was trying to incorporate the suggestion of Gabriel Wong
(earlier in this thread) that it would be nice to do extension matching and still
allow extra path information after the match.  I cannot see how you can set up
rules that unambiguously work through the following case:

Goal:  Filename extension mapping for extension ".html" to a particular servlet,
assuming that no higher priority matching rule (on exact match or directory
prefix) finds a match first.

Scenario Cases:

    /directory/file.html -- works fine
    /directory/file.html/extra/path/info -- works only if you look for the last
period to
        identify where the "extension" is, even if it is followed by a slash
    /directory/file.html/extra.path.info -- fails if you use the logic that makes
the
        previous case work -- this one tries to extension match on ".info"
instead

Conclusion:  I do not see how to define the matching rules for extension matching
that let you have extra path information after the "extension" that was matched,
unless you (a) specifically identify the delimiter character that starts an
extension in the spec (traditionally a period), and (b) do not allow that
character to appear in the extra path information string.

Craig McClanahan




"Craig R. McClanahan" wrote:

> Nic Ferrier wrote:
>
> > >>> "Craig R. McClanahan" <[EMAIL PROTECTED]> 3/31/99 7:51:03
> > AM >>>
> > 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.
> >
> > I think the easiest to implement (the one Paperclips uses) is
> > Extension match, ie: checking that the period is not followed by a /.
> >
> > I don't think the standards going to be much use here,
> >
> > Nic
> >
>
> This kind of rule still gets messed up if you allow extra path information AND
> the extra path information might have periods in it.  For example, assume a
> mapping from ".html" to a servlet, as we have been discussing:
>
>     /file.html --> HTML processing servlet -- no problem
>     /file.html/extra/path/info --> HTML processing servlet by your rule
>     /file.html/extra.path.info --> ???
>
> This is the kind of thing that prompted my question on how you identify exact
> path matches versus directory matches.
>
> Craig McClanahan
>
> ___________________________________________________________________________
> 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