You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by André Warnier <aw...@ice-sa.com> on 2008/07/23 00:11:14 UTC

[users@httpd] Generic questions on Alias, JkMount etc.. priorities

Hi.

Could a real Apache/mod_jk specialist clear up a few questions to which 
I do not seem to find a clear, definitive and explicit answer in the 
documentation(s) ?

I mean, some of the things below seem to be working for me, but I would 
kind of like to get some official confirmation, before I repeat them too 
often to newbies on this list ;-).
I would also like to know if they represent official, supported, 
likely-to-stay features, or if they are going to be obsoleted-out 
anytime soon.

(It is possible that some questions overlap; the available documentation 
does too sometimes).

1) I see on this list and on the Tomcat lists, a lot of questions where 
people create a configuration of the following genre :

Assuming the Tomcat webapps directory is (e.g.) /var/lib/tomcatX/webapps

then, in apache.conf :

DocumentRoot /var/lib/tomcatX/webapps
or
Alias /apps "/var/lib/tomcatX/webapps"

I am of the impression that such a configuration is basically a bad 
idea, because it exposes, through Apache, things that should not be 
accessible by the users, such as the Tomcat webapps/xxx/WEB-INF 
directories and files.
True/False ?
Elaborate ?

2) When one has the following configuration in Apache :

Alias /eg /var/lib/tomcatX/webapps/examples
<Directory /var/lib/tomcatX/webapps/examples>
   Order Allow, Deny
   Allow from all
</Directory>
JkMount /eg ajp13w
JkMount /eg/* ajp13w

my understanding is that :
- mod_jk (and Tomcat) intervene at the "content generation" phase of the 
request processing.
- but "Alias" intervenes earlier, during the "URL translation" phase

Thus, if a browser requests a URL like "/eg/HelloWorld",
- Apache (by virtue of the Alias) will first translate this internally 
to "/var/lib/tomcatX/webapps/examples/HelloWorld"
- then mod_jk will get a chance to generate the content of this request, 
but it will decline because the URI no longer matches "/eg" or "/eg/*"
- thus Apache will (try to) serve this itself, from the directory 
/var/lib/tomcatX/webapps/examples, using its default content handler
(and might fail doing so, and return "Not Found", if there is nothing in 
there explictly called "HelloWorld").

True/False ?
if false, elaborate ?

3) mod_jk, for all intents and purposes within Apache, is a "content 
generator", and thus intervenes *after* URI translation, access control, 
authentication, authorisation, fixup.
True/False ?

4) The way in which mod_jk or Apache "decide" that a given URL is to be 
handled (for content generation) by mod_jk (and Tomcat behind it) is as 
follows : at the moment when the response content should be generated,

- Apache hands over the current request to mod_jk, and waits for mod_jk 
to return a response.
   - mod_jk examines the request and finally returns a response which is 
either "declined", "OK", or "error".
   - if the response of mod_jk was "declined", then Apache tries any 
other content generator configured, ending with it's own default handler.
   - if the response of mod_jk is OK, then Apache supposes that the 
content was generated by mod_jk, passes it on to the browser, and does 
not call any other handler.
   - if the response was "error", then Apache breaks up the request 
cycle, returns an error to the browser, and skips to logging.

True/false ?

5) Apache does not have a clue that Tomcat is behind mod_jk. For Apache, 
mod_jk is "the" content handler.  When Apache hands a request to mod_jk 
for processing, it expects a response from mod_jk, and could not care 
less if there is one, or a dozen, or zero Tomcats behind it.
True/False ?

6) What is the exact syntax of the URI's used in JkMount directives ?
I mean what is allowed/not allowed ? is it a regexp ? is it some other 
form of wildcard ? is it the same bizarre kind of thing as the 
<url-pattern> in the servlet specification ?
If I put for instance
JkMount /examples/* ajp13w
does the leading "/" mean "the DocumentRoot", or is this a string that 
can match anywhere in the request URI ?
Can I use "^/examples/*" if I want "/examples" to be at the beginning of 
the URI ?
Does there exist a description of this somewhere in the on-line 
documentation ?

6) If I have this configuration section :
(assuming mod_setenvif loaded)

<Location /jk_examples>
   SetHandler jakarta-servlet
   SetEnvIf REQUEST_URI "\.(gif|jpg)$" no-jk
</Location>

is it the exact equivalent of (in the sense of does it do the same thing 
as) having these directives at the server/vhost level :

   JkMount /jk_examples ajp13w
   JkMount /jk_examples/* ajp13w
   JkUnMount /jk_examples/*.gif
   JkUnMount /jk_examples/*.jpg

If not, why not ?

(I think I found the "SetHandler jakarta-servlet" somewhere in the 
documentation of either Apache or Tomcat, but I think it's not at the 
same place as the "JkMount/JkUnMount" documentation)


Many thanks in advance,
André

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Re: [users@httpd] Generic questions on Alias, JkMount etc.. priorities

Posted by Serge Dubrouski <se...@gmail.com>.
On Tue, Jul 22, 2008 at 4:11 PM, André Warnier <aw...@ice-sa.com> wrote:
> Hi.
>
> Could a real Apache/mod_jk specialist clear up a few questions to which I do
> not seem to find a clear, definitive and explicit answer in the
> documentation(s) ?
>
> I mean, some of the things below seem to be working for me, but I would kind
> of like to get some official confirmation, before I repeat them too often to
> newbies on this list ;-).
> I would also like to know if they represent official, supported,
> likely-to-stay features, or if they are going to be obsoleted-out anytime
> soon.
>
> (It is possible that some questions overlap; the available documentation
> does too sometimes).
>
> 1) I see on this list and on the Tomcat lists, a lot of questions where
> people create a configuration of the following genre :
>
> Assuming the Tomcat webapps directory is (e.g.) /var/lib/tomcatX/webapps
>
> then, in apache.conf :
>
> DocumentRoot /var/lib/tomcatX/webapps
> or
> Alias /apps "/var/lib/tomcatX/webapps"

Per my opinion that doesn't make any sense. DocumentRoot in Apache
points to a directory where static content is kept, webapps in Tomcat
usually is used for storing application files. Those are 2 absolutely
different things and shouldn't be mixed together. Yet it is absolutely
insecure.

>
> I am of the impression that such a configuration is basically a bad idea,
> because it exposes, through Apache, things that should not be accessible by
> the users, such as the Tomcat webapps/xxx/WEB-INF directories and files.
> True/False ?
> Elaborate ?
>
> 2) When one has the following configuration in Apache :
>
> Alias /eg /var/lib/tomcatX/webapps/examples
> <Directory /var/lib/tomcatX/webapps/examples>
>  Order Allow, Deny
>  Allow from all
> </Directory>
> JkMount /eg ajp13w
> JkMount /eg/* ajp13w

Again a really strange configuration. JkMount says that all requests
to those locations shall be forwarded to Tomcat. There is no need for
that Alias neither for Directory configuration options. Access control
should be done through Location options:

<Location /eg>
   Order ...
   Allow ...
</Location>

There is no need to expose webapps subdirs through Apache.

>
> my understanding is that :
> - mod_jk (and Tomcat) intervene at the "content generation" phase of the
> request processing.
> - but "Alias" intervenes earlier, during the "URL translation" phase
>
> Thus, if a browser requests a URL like "/eg/HelloWorld",
> - Apache (by virtue of the Alias) will first translate this internally to
> "/var/lib/tomcatX/webapps/examples/HelloWorld"
> - then mod_jk will get a chance to generate the content of this request, but
> it will decline because the URI no longer matches "/eg" or "/eg/*"
> - thus Apache will (try to) serve this itself, from the directory
> /var/lib/tomcatX/webapps/examples, using its default content handler
> (and might fail doing so, and return "Not Found", if there is nothing in
> there explictly called "HelloWorld").
>
> True/False ?
> if false, elaborate ?
>
> 3) mod_jk, for all intents and purposes within Apache, is a "content
> generator", and thus intervenes *after* URI translation, access control,
> authentication, authorisation, fixup.
> True/False ?

True.

>
> 4) The way in which mod_jk or Apache "decide" that a given URL is to be
> handled (for content generation) by mod_jk (and Tomcat behind it) is as
> follows : at the moment when the response content should be generated,
>
> - Apache hands over the current request to mod_jk, and waits for mod_jk to
> return a response.
>  - mod_jk examines the request and finally returns a response which is
> either "declined", "OK", or "error".
>  - if the response of mod_jk was "declined", then Apache tries any other
> content generator configured, ending with it's own default handler.
>  - if the response of mod_jk is OK, then Apache supposes that the content
> was generated by mod_jk, passes it on to the browser, and does not call any
> other handler.
>  - if the response was "error", then Apache breaks up the request cycle,
> returns an error to the browser, and skips to logging.
>
> True/false ?

False. Based on JkMount Apache routes requests to Tomcat. If it can't
communicate to Tomcat it generates 503, if it can communicate to
Tomcat it simply forwards content generated by Tomcat back to the
client along with HTTP return code.

>
> 5) Apache does not have a clue that Tomcat is behind mod_jk. For Apache,
> mod_jk is "the" content handler.  When Apache hands a request to mod_jk for
> processing, it expects a response from mod_jk, and could not care less if
> there is one, or a dozen, or zero Tomcats behind it.
> True/False ?

If I understand you right it is True. You can configure mod_jk to load
balance your requests between several Tomcat instances.

>
> 6) What is the exact syntax of the URI's used in JkMount directives ?
> I mean what is allowed/not allowed ? is it a regexp ? is it some other form
> of wildcard ? is it the same bizarre kind of thing as the <url-pattern> in
> the servlet specification ?
> If I put for instance
> JkMount /examples/* ajp13w
> does the leading "/" mean "the DocumentRoot", or is this a string that can
> match anywhere in the request URI ?
> Can I use "^/examples/*" if I want "/examples" to be at the beginning of the
> URI ?
> Does there exist a description of this somewhere in the on-line
> documentation ?

There is some documentation here:
http://tomcat.apache.org/connectors-doc/index.html
>
> 6) If I have this configuration section :
> (assuming mod_setenvif loaded)
>
> <Location /jk_examples>
>  SetHandler jakarta-servlet
>  SetEnvIf REQUEST_URI "\.(gif|jpg)$" no-jk
> </Location>
>
> is it the exact equivalent of (in the sense of does it do the same thing as)
> having these directives at the server/vhost level :
>
>  JkMount /jk_examples ajp13w
>  JkMount /jk_examples/* ajp13w
>  JkUnMount /jk_examples/*.gif
>  JkUnMount /jk_examples/*.jpg
>
> If not, why not ?

Don't know. I've always used JkMount. In fact I'd rather split dynamic
and static content between different directories and would use only
JkMount for active content.

>
> (I think I found the "SetHandler jakarta-servlet" somewhere in the
> documentation of either Apache or Tomcat, but I think it's not at the same
> place as the "JkMount/JkUnMount" documentation)
>
>
> Many thanks in advance,
> André
>
> ---------------------------------------------------------------------
> The official User-To-User support forum of the Apache HTTP Server Project.
> See <URL:http://httpd.apache.org/userslist.html> for more info.
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>  "   from the digest: users-digest-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>



-- 
Serge Dubrouski.

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org