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-name>HelloWorld</servlet-name>
> <servlet-class>com.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]>
