On Mon, 21 Jan 2002, Anton Brazhnyk wrote:
> Date: Mon, 21 Jan 2002 12:59:23 +0200
> From: Anton Brazhnyk <[EMAIL PROTECTED]>
> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> To: Tomcat Users List <[EMAIL PROTECTED]>
> Subject: RE: mod_webapp and php
>
> > -----Original Message-----
> > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, January 18, 2002 7:52 PM
> > To: Tomcat Users List
> > Subject: Re: mod_webapp and php
> >
> >
> > > I cannot fathom how they plan to do that, since it would violate the
> > > view of a "web application" as a sealed component on the "servlet
> > > container". I mean suppose you have a WELCOME.GIF file in your web
> > > application, how is Apache supposed to serve it, other than through
> > > WARP? Pre-caching of all static content upon "Warp Deployment"?
> > >
> >
> > The original design goal was to make a decision based on the incoming
> > request URI of each request, by asking the following questions:
> > * Is this request URI matched by a filter mapping?
> > * Is this request URI matched by a servlet mapping?
> > * Is this request URI matched by a security constraint?
> > If the answer to any of these questions is YES, the request must be served
> > by Tomcat, to maintain the semantics required by the servlet
> > specification.
> >
> > On the other hand, if the answer to all of these questions is NO, there is
> > no semantic problem with allowing Apache to serve this resource, instead
> > of the default file-serving servlet in Tomcat.
> >
>
> Thanks for clarification, Craig But then again, what if the static
> content (e.g. some html pages) resides inside web-app, is it than
> considered static? Will Apache serve it from there directly (I believe
> not, cause it could be on a different host) or will mod_webapp pre-cache
> it in some place Apache is aware of or will such content be served by
> Tomcat? (that is what I think for now)
>
Your impression of how it works seems to be inaccurate. There is no
caching going on anywhere.
Let's look at the Tomcat stand-alone case first, and then examine the
combined case.
Technically, from the point of view of Tomcat 4 (details are slightly
different in 3.3), there is no such thing as "static content" -- all
requests are handled by a servlet. If you look in the
$CATALINA_HOME/conf/web.xml file, which defines default configuration
settings for all webapps, you will see a servlet named "default" that is
mapped to the URL pattern "/". This pattern means, "use the 'default'
servlet whenever no other servlet is matched by a particular request URI".
So, requests for things like "index.html" and "logo.jpg" don't match any
of your application servlets or JSP pages, so they are handled by the
default servlet -- which simply serves the contents of the corresponding
file back to the client.
Now, let's consider what happens when you put Apache and a web connector
in front of Tomcat (the concepts apply equally to mod_jk and mod_webapp,
only the configuration details differ). Essentially, what people try to
do is make Apache itself be the default file-serving servlet, instead of
the one built in to Tomcat.
This is accomplished in your configuration directives, where you tell
Apache which requests to forward (and by implication, all other requests
are handled by Apache itself in the usual way). Thus, when we add a
diretive that says "forward all *.jsp requests to Tomcat", we are telling
Apache that any request that ends with ".jsp" MUST be forwarded to Tomcat
for processing. Apache acts like a proxy server for these requests -- it
just calls Tomcat and then copies back the response Tomcat creates to the
original client.
If you do not have any such configuration directives for "*.html" and
"*.jpg" patterns, then Apache serves them directly, based on your Apache
configuration directives in httpd.conf. It is NOT an issue of pre-caching
or anything like that -- the request either gets forwarded to Tomcat or it
doesn't.
Now, if you configure Apache so that the directory being served by the
"/foo" request URI prefix is the same as the directory defined as the
context root of the "/foo" web app in Tomcat, you've accomplished the goal
-- Tomcat serves all the requests that Apache forwards to it, and Apache
serves all the requests that it doesn't forward. But your application
code is identical in either case.
Keep in mind that the ACTUAL directory pathname of your webapp doesn't
need to have anything at all to do with the "/foo" prefix on requiest
URIs. Both Apache (via the "Alias" directive) and Tomcat (via the
"docBase" attribute of the <Context> element) let you map that prefix to
whatever real directory you want -- the secret is to make sure they both
point at the same place.
Lastly, I want to emphasize again, NONE of this is new to mod_webapp --
the mod_jserv and mod_jk connectors have worked this way for around five
years. The only new thing mod_webapp was supposed to bring to the table
was automatic configuration of the httpd.conf directives that make all of
this happen, instead of requiring the sysadmin to do it all yourself.
>
> Anton
>
Craig
--
To unsubscribe: <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>
