cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <p...@betaversion.org>
Subject Re: [TIPS] Basic configurations of Apache 2.0 for Cocoon 2
Date Wed, 05 Feb 2003 15:13:50 GMT
"Jeremy Quinn" <jeremy@media.demon.co.uk> wrote:
> On Wednesday, Feb 5, 2003, at 02:46 Europe/London, Pier Fumagalli wrote:
> 
>> After few discussions had face-to-face with some of you (Stefano on the
>> phone ranting about setting up Tomcat, Jeremy over lunch at my place
>> few
>> weeks ago, and several others), and few odd questions popping out on
>> the
>> list, I feel the need to tell you why my vision is so narrow when
>> someone
>> touches the "Apache" argument.
> 
> Brilliant!!!! It is working, hurrah!

I knew you would have liked it! ;-) (Re: per our discussion over salads!)

> One thing I would like to try, is to make Apache handle the display of
> any 404s, 500s etc. caught by TomCat/Cocoon. (Not switched to Jetty
> yet).

Oh, you won't have to change anything on the Apache front if you switch
container... You won't have to use a different module! :-)

> ie. I would like our production server to have Apache outputting a
> common style of error pages, while keeping Cocoon outputting error
> pages (with stacktraces etc.) only on the staging server (so developers
> can see the cause).
> 
> Obviously I can get Cocoon to output the same style of error page as
> Apache's ones, but I'd prefer to get Cocoon to offload all error
> reporting to Apache if possible.
> 
> Anyone know how to do this?

Ouch... I _knew_ I forgot somethin0g yesterday night, well, time to do a
small addition (craps, I have to _really_ learn how to use the Wiki now):

Letting Apache to handle error pages
------------------------------------

Whenever we want Apache to handle error messages in a consistent way
(basically overwriting what Cocoon writes as a body in error pages), we can
do that by simply adding a few lines to the configurations we used before:

    # Make sure that Apache processes the headers coming back from the proxy
    # requests. This will enable also the evaluation of HTTP status codes.
    ProxyPassReverse / http://localhost:8000/

    # Tell mod_mod proxy that it should not send back the body-content of
    # error pages, but be fascist and use its local error pages if the
    # remote HTTP stack is sending an HTTP 4xx or 5xx status code.
    ProxyErrorOverride On

    # For each individual error we want to handle, let's specify what file
    # we want to use. Note that all files must be available through a
    # locally accessible directory (as our /static/), and they can even be
    # SSI files (SHTML files).
    ErrorDocument 404 /static/notfound.shtml
    ErrorDocument 500 /static/error.shtml
    ErrorDocument 502 /static/unavailable.shtml

This is how it can be done, so that (for example, as suggested by Jeremy),
one can configure Cocoon to dump full-stack-traces on the staging server,
(or from an interface available only to the internal network), while
displaying nicely formatted error messages to our client.


Preserving the Host header through a proxy
------------------------------------------

In some cases, it is quite important to preserve the "Host" header
throughout the proxied request.

For example, to be able to deal with multiple virtual hosts on the backend
servlet container, the proxied request  MUST include the original Host name
requested by our client. Apache allows us to pass this value through using
the ProxyPreserveHost directive:

    # Make sure that the virtual host name is passed through to the
    # backend servlet container for virtual host support.
    ProxyPreserveHost On


Putting it all together
-----------------------

Linking together all the different pieces we've analyzed before, now, we can
attempt to write up a do-it-all fragment of our httpd.conf file:


    #######################################################################
    # GLOBAL CONFIGURATIONS                                               #
    #######################################################################

    # Make sure that my document root points to the root of the web
    # application (where the WEB-INF is located, for instance).
    DocumentRoot /export/webapps/cocoon

    # Make sure that Server Side Includes are processed and sent
    # to the client with mime-type as text/html
    AddType text/html .shtml
    AddOutputFilter Includes .shtml

    # Make sure that our SHTMLs are processed in the static
    # directory
    <Directory "/export/webapps/cocoon">
        Options +IncludesNoExec
    </Directory>

    #######################################################################
    # ERROR PAGES CONFIGURATION                                           #
    #######################################################################

    # If mod_proxy cannot connect to the servlet container, we want
    # to display a nice static page saying the reason. This is a
    # SHTML page (using the Server-Side-Includes filter)
    ErrorDocument 502 /static/unavailable.shtml

    # For each individual error we want to handle, let's specify what file
    # we want to use. Note that all files must be available through a
    # locally accessible directory (as our /static/), and they can even be
    # SSI files (SHTML files).
    ErrorDocument 404 /static/notfound.shtml
    ErrorDocument 500 /static/error.shtml

    #######################################################################
    # MOD_PROXY CONFIGURATIONS                                            #
    #######################################################################

    # Make sure that if the servlet container specifies a "Location" HTTP
    # header during redirection starting with "http://localhost:8080/", we
    # can handle it and return to our client the effective (not real)
    # location we want to redirect them to. This is _essential_ to handle
    # also the error returned by the backend servlet container.
    ProxyPassReverse / http://localhost:8080/

    # Make sure that the virtual host name is passed through to the
    # backend servlet container for virtual host support.
    ProxyPreserveHost On

    # Tell mod_mod proxy that it should not send back the body-content of
    # error pages, but be fascist and use its local error pages if the
    # remote HTTP stack is sending an HTTP 4xx or 5xx status code.
    ProxyErrorOverride On

    #######################################################################
    # MOD_REWRITE CONFIGURATIONS                                          #
    #######################################################################

    # The nastiness begins, let's fire up the "rewrite engine"
    RewriteEngine On

    # Everything that starts with "/static" or "/static/" is served straight
    # through: no redirection, no proxying, no nothing, and the [L] flag
    # implies that if this rule is matched, no other matching must be
    # performed
    RewriteRule "^/static/?(.*)" "$0" [L]

    # Everything that starts with a NON-CASE-SENSITIVE match (the NC flag)
    # of "/WEB-INF" or "/WEB-INF/" is forbidden (the F flag). And again,
    # this is the last rule (the L flag), nothing will be processed by the
    # rewrite engine if this rule is matched
    RewriteRule "^/WEB-INF/?(.*)" "$0" [L,F,NC]

    # Everything ending in ".gif", ".jpg" or ".jpeg" will be served again
    # directly by Apache, no need to bother the servlet container. As above
    # this is the last rule as specified by the [L] flag at the end
    RewriteRule "^/(.*)\.gif$" "$0" [L]
    RewriteRule "^/(.*)\.(jpg|jpeg)$" "$0" [L]

    # Everything else not matched above needs to go to the servlet container
    # via HTTP listening on port 8080. The [P] flag (which is required)
    # implies that our requests will be handled by mod_proxy.
    RewriteRule "^/(.*)" "http://localhost:8080/$1" [P]

And that's all... You can roughly copy and paste this example in a
<VirtualHost> section of your httpd.conf (obviously after having applied the
appropriate modification), and go...

    Pier


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message