httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <>
Subject Re: mod_proxy Cache-Control: no-cache=<directive> support Apache1.3
Date Fri, 01 Mar 2002 02:01:12 GMT
Igor Sysoev wrote:

> mod_proxy can not do many things that mod_accel can. Some of
> them can be easy implemented, some not.

Keep in mind that mod_proxy is exactly that - a proxy. It does not try
to duplicate functionality that is performed by other parts of Apache.
(This is the main reason mod_proxy and mod_cache were separated from
each other in v2.0)

> mod_accel can:
> *) ignore headers like 'Pragma: no-cache' and 'Authorization'.

This is the job of mod_headers, not mod_proxy.

However: ignoring headers violates the HTTP protocol and is not
something that should be included in a product that claims to be as HTTP
compliant as possible. If you want to cache heavy data sources, use the
Cache-Control header correctly, or correct the design of the application
so as to be less inefficient.

> *) log its results.

In theory mod_proxy (and mod_cache) should allow results to be logged
via the normal logging modules. If this is not yet possible, it should
be fixed.

> *) pass cookies to backend even response can be cached.

Again RFC2616 dictates how this should be done - proxy should support
the specification.

> *) taking cookies into account while caching responses.
> *) mod_accel has AccelNoPass directive.

What does this do?

If it allows certain parts of a proxied URL space to be "not-proxied",
then the following will achieve this effect:

ProxyPass /blah http://somewhere/blah
ProxyPass /blah/somewhere/else !

Everything under /blah is proxied, except for everything under

> *) proxy mass name-based virtual hosts with one directive on frontend:
>    AccelPass   /    [PH]
>    [PH] means preserve hostname, i.e. request to backend would go with
>    original 'Host' header.

mod_accel does this in one directive, mod_proxy does it in two - but the
effect is the same. Should we consider adding a combined directive to
mod_proxy the same way mod_accel works...?

> *) resolve backend on startup.

This is a good idea.

> *) make simple fault-tolerance with dns-balanced backends.

mod_proxy does this already.

> *) use timeout when it connects to backend.

mod_proxy should do this - if it doesn't, it is a bug.

> *) use temporary file for buffering client request body (there is patch
>    for mod_proxy).

What advantage does this give?

> *) serve byte-range requests.

This needs to be fixed in proxy, yes.

> *) get backend response as soon as possible even it's very big.
>    mod_accel uses temporary file for buffering backend response if
>    reponse can not fill in mod_accel configurable buffer.

This kind of thing is fixed in v2.0 in mod_cache. It is too big an
architecture change for the v1.3 proxy.

> *) use busy locks. If there are several the same requests to backend
>    then only one of them would go to backend during specified time.
> *) limit concurrent connections and waiting processes on per-backend
>    or per Location basis.

This is not the job of mod_proxy, but the job of a separate module.

Both busy locks and limiting concurrent connections can be useful in a
normal Apache server using mod_cgi, or one of the Java servlet
connectors. Adding this to proxy means it can only be used in proxy -
which is a bad idea.

> *) mod_accel has mod_randban module that allow to randomize some
>    part of content. For example it can replace '11111' number in
>    <img src="http://host/path1?place=1&key=1234&rand=11111">
>    with random value.

This is the job of mod_rewrite.

-----------------------------------------		"There's a moon
					over Bourbon Street
View raw message