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 /blah/somewhere/else. > *) proxy mass name-based virtual hosts with one directive on frontend: > AccelPass / http://192.168.1.1/ [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. Regards, Graham -- ----------------------------------------- [EMAIL PROTECTED] "There's a moon over Bourbon Street tonight..."
smime.p7s
Description: S/MIME Cryptographic Signature
