On Fri, 8 Mar 2002, Graham Leggett wrote:
Igor Sysoev wrote:
*) make simple fault-tolerance with dns-balanced backends.
mod_proxy does this already.
No. mod_proxy tries it but code is broken. If connection failed it try
to connect with the same socket. It should make new
Bill Stoddard wrote:
mod_disk_cache does not require knowledge of content length. In principle, do you
think
this is a problem for a proxy cache provided we can gracefully detect and handle
cases
where cache thresholds are being exceeded? What does squid and apache 1.3 do?
I have no idea
Bill Stoddard wrote:
mod_disk_cache does not require knowledge of content length. In principle, do you
think
this is a problem for a proxy cache provided we can gracefully detect and handle
cases
where cache thresholds are being exceeded? What does squid and apache 1.3 do?
I have no
Igor Sysoev wrote:
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.
In my experience, use a proxy as a forward proxy (like Squid), and use a
webserver as a reverse
Igor Sysoev wrote:
*) make simple fault-tolerance with dns-balanced backends.
mod_proxy does this already.
No. mod_proxy tries it but code is broken. If connection failed it try
to connect with the same socket. It should make new socket.
Anyway mod_accel tries another backend if
Igor Sysoev wrote:
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 ?
Looking into this further, proxy uses the HTTP/1.1 Vary mechanism for
determining whether a negoitated
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
Bill Stoddard wrote:
Haven't thought this through, but there is at least one complicated case to consider
and
handle correctly. If the backend is chunking a response back to the proxy and that
response exceeds the size the proxy is allowed to cache, then the proxy would need to
abort the
Igor Sysoev 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
Bill Stoddard wrote:
Haven't thought this through, but there is at least one complicated case to
consider
and
handle correctly. If the backend is chunking a response back to the proxy and that
response exceeds the size the proxy is allowed to cache, then the proxy would need
to
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
Eli Marmor wrote:
Then, integration with mod_proxy still needed, because the connection
of mod_proxy with the backend server was still done directly, and not
through the filtering infrastructure.
The v2.0 port has used the filtering infrastructure on the backend since
day one - however this
*) 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
On Fri, 1 Mar 2002, Graham Leggett wrote:
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
On Wed, 27 Feb 2002, Joseph Wayne Norton wrote:
For dynamic content that has been cached or can be cached, the
Distributor component would simply send the response back to the
client (as mod_proxy does now after talking with the backend). For
dynamic content that cannot be cached or doesn't
On Wed, 20 Feb 2002, Graham Leggett wrote:
Igor Sysoev wrote:
1.3.23 mod_proxy calls ap_proxy_send_fb() and than closes backend.
But ap_proxy_send_fb() flushes output to client so it can hang
for a long time.
I have come up with a patch to solve this problem - in theory anyway.
On Thu, 21 Feb 2002, Joseph Wayne Norton wrote:
After I read your posting, I downloaded but haven't tried to install
the mod_accel. From you description, it looks like a very, powerful
module with pretty much the features that I have been looking for.
Can mod_accel work with the mod_rewrite
On Thu, 21 Feb 2002, Igor Sysoev wrote:
On Thu, 21 Feb 2002, Joseph Wayne Norton wrote:
After I read your posting, I downloaded but haven't tried to install
the mod_accel. From you description, it looks like a very, powerful
module with pretty much the features that I have been looking
Igor Sysoev wrote:
1.3.23 mod_proxy calls ap_proxy_send_fb() and than closes backend.
But ap_proxy_send_fb() flushes output to client so it can hang
for a long time.
I have come up with a patch to solve this problem - in theory anyway.
Can you test it and get back to me with whether it
On Tue, 19 Feb 2002, Fowler, Brian wrote:
Due to a requirement on a project we are currently working on involving
using Apache as a caching reverse proxy server to WebLogic.
We are considering implementing the
Cache-Control: no-cache=directive
for the Apache 1.3 mod_proxy module
Igor Sysoev wrote:
mod_proxy is very ancient module and it's hard to maintain it.
Er, mod_proxy _was_ a very ancient module, but has been largely
overhauled in v1.3 and completely rewritten in v2.0 in both cases having
full support of HTTP/1.1.
Once mod_cache is finished in v2.0, (in theory)
On Tue, 19 Feb 2002, Graham Leggett wrote:
Igor Sysoev wrote:
mod_proxy is very ancient module and it's hard to maintain it.
Er, mod_proxy _was_ a very ancient module, but has been largely
overhauled in v1.3 and completely rewritten in v2.0 in both cases having
full support of
Igor Sysoev wrote:
The main problem with mod_proxy is that it reads backend response
to 8K buffer and than sends it to client. When it have sent it
to client it reads again from backend. After it have sent whole
content to client it flushes buffer and only after this it closes
backend
On Tue, 19 Feb 2002, Graham Leggett wrote:
Igor Sysoev wrote:
The main problem with mod_proxy is that it reads backend response
to 8K buffer and than sends it to client. When it have sent it
to client it reads again from backend. After it have sent whole
content to client it flushes
Igor Sysoev wrote:
1.3.23 mod_proxy calls ap_proxy_send_fb() and than closes backend.
But ap_proxy_send_fb() flushes output to client so it can hang
for a long time.
Then this needs to be fixed. I have 24 hours sitting on a plane starting
tomorrow night, so I'll probably have time then :)
25 matches
Mail list logo
