httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Sysoev ...@rambler-co.ru>
Subject Re: mod_proxy Cache-Control: no-cache=<directive> support Apache1.3
Date Thu, 07 Mar 2002 14:17:28 GMT
On Wed, 6 Mar 2002, Graham Leggett wrote:

> > mod_accel is not proxy. It's accelarator. It can not work as usual proxy.
> > I did not even try to implement it - Apache 1.3 is poor proxy. Squid or
> > Oops are much better.
> 
> Until recently you were not aware that the proxy had been updated - I
> would look at the code again before passing this judgement ;)

The main reason why Squid is better than Apache is much lesser
memory overhead per connection. And of course, Squid has many other
proxing features - it's proxy, not webserver.

> For example, you pointed out some problems with Squid and content
> negotiation - mod_proxy doesn't have these problems.

Do you mean that Squid returns cached gzipped content to client
that does not send 'Accept-Encoding' ? mod_proxy 1.3.23 does the same.
Would it be changed in 1.3.24 ?

> > mod_accel can ignore client's 'Pragma: no-cache' and
> > 'Cache-Control: no-cache'. These headers are sent if you press Reload
> > button in Netscape or Mozilla. By default if mod_accel gets these headers
> > then it does not look cache but send request to backend.
> > Webmaster can set 'AccelIgnoreNoCache on' if he sure that
> > backend did not give fresh data and such requests only overload backend.
> 
> This design is broken.
> 
> If the client sent a cache-control or pragma header it was because the
> client specifically wanted that behaviour. If this causes grief on the
> backend, then your backend needs to be redesigned so that it does not
> have such a performance hit.

I live in real world and many webmasters are too. It's not always possible
to redesign backend. Unfortunately while Internet boom too many brain-damaged
solutions were born.

> Breaking the HTTP protocol isn't the fix to a broken backend.

I'm considering mod_accel and backend as single entity. It does not
matter for me which protocol I use for communication between them.
Clients see nice HTTP protocol.

> > > Everything under /blah is proxied, except for everything under
> > > /blah/somewhere/else.
> > 
> > Yes. But '!' is already implemented ?
> 
> Yes it is.

I suppose in 1.3.24 ? By the way mod_accel's syntax is more flexible -
mod_accel can use regexp.

> > > > *) 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...?
> > 
> > What are two mod_proxy's directives ?
> > As far as I know mod_proxy always change 'Host' header.
> 
> Use the ProxyPreserveHost option.

I suppose in 1.3.24 ?

> > mod_accel can send part of answer to client even backend has not sent
> > whole answer. But even in this case slow client never block backend -
> > I use nonblocking operations and select().
> > Would it be possible with mod_cache ?
> 
> The idea behind mod_cache was to separate the "send" threads from the
> "receive" thread. This means that if a response is half-way downloaded,
> and a new request comes in, the new request will be served from the
> half-cached half-downloaded file, and not from a new request. When the
> original request is finished, the backend is released, and the "receive"
> threads carry on regardless.

Would it be work in prefork MPM ?

> > > 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.
> > 
> > Probably but Apache 1.3.x has not such module and I needed it too much
> > in mod_accel.
> 
> You should have created a separate module for this, and run it alongside
> mod_accel. This can still be done though.

I did not use mod_cgi and Java.

> > > This is the job of mod_rewrite.
> > 
> > mod_rewrite can not do it.
> 
> Then rewrite should be patched to do it.

Your phrase is like 'mod_rewrite should be patched to do some SSI job'
mod_rewrite works with URLs and filenames only. It can not change content.
mod_randban changes content on the fly.

Igor Sysoev


Mime
View raw message