On Thu, 14 Mar 2002, Tony LaPaso wrote:
Date: Thu, 14 Mar 2002 11:47:09 -0600
From: Tony LaPaso [EMAIL PROTECTED]
Reply-To: Tomcat Users List [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Servlet Names -- ?? Modify Servlet Spec -- Comments ??
Hi All,
First, let me say that I'm *not* requesting creative ways to get around this
behavior. I'm wondering if the Servlet Spec (sec. SRV.11.1) should be
refined to address this issue. I'm using Tomcat v4.0.3 on Win 2K.
Let's say I have this servlet declaration in my deployment descriptor:
servlet
servlet-nameHelloWorld/servlet-name
servlet-classcom.abc.def.HelloWorld/servlet-class
/servlet
What I'm finding (and I don't like) is that I can invoke this servlet either
by its servlet name or its fully-qualified class name:
URL #1: http://myHost/servlet/HelloWorld
OR
URL #2: http://myHost/servlet/com/abc/def/HelloWorld
Both of these things are because of the invoker servlet (see the
$CATALINA_HOME/conf/web.xml file), which is a Tomcat feature and not
anything to do with the Servlet Specification. If you don't want this,
simply comment out the servlet-mapping entry for the invoker servlet.
Then, only the mappings you explicitly define yourself will be used.
Each URL creates a *separate instance* of the servlet. To my way of
thinking, the servlet-name specified in the deployment descriptor is more
or less a logical name for the physical servlet. By specifying this name
in the deployment descriptor, I am providing a name by which this servlet is
to be known to the world. This logical name should hide the physical
name of the servlet. If some rogue client (somehow) happens to know the
fully-qualified class name for the servlet, and invokes it using URL #2
above, this should *not* cause an extra instance of the servlet to be
created. In fact, it should not even cause the servlet to be invoked.
Off the top of my head, here are four reasons why the exisiting behavior
seems bad:
1. It's wasteful in that it creates an unneeded servlet instance.
2. It complicates the logic of a servlet because now it must allow for
additional instances created if the servlet is invoked by its fully
qualified class name.
3. A security issue arises. If a user is able to successfully invoke the
servlet using the fully qualified class name, it may give the user insight
into the server's directory structure.
4. It prevents a unified set of URLs from being the *only* way of invoking a
servlet.
My general feel is that the server administrator should have complete
control over the name(s) (i.e., URLs) by which a servlet is know to the
world. I'm wondering if SRV.11.1 should be updated. Here's a plain English
proposal:
If a servlet-mapping element(s) exists in the
deployment descriptor, the servlet is accessible
*only* via the specified url-pattern element(s)
and *not* by the servlet-name element(s) within
the servlet element.
If *no* servlet-mapping element(s) is present but a
servlet element exists, the servlet is accessible
*only* via the enclosed servlet-name element(s). If a
servlet element does *not* exist, then the servlet is
searched for using specified URL path.
If no servlet mapping at all is present, your servlet will not be
accessible. But, in fact, there is a servlet mapping (/servlet/*) that
covers these paths, and its functionality is based on historical
precedent. It would break very large numbers of existing applications to
change that functionality now.
You, on the other hand, are perfectly free to disable this mapping if you
don't want this service.
Comments?? Is this a dumb idea?
Craig
--
To unsubscribe: mailto:[EMAIL PROTECTED]
For additional commands: mailto:[EMAIL PROTECTED]
Troubles with the list: mailto:[EMAIL PROTECTED]
