I'm running Apache 1.3.12 for the backend and Apache 2.0.16 (beta release)
with current mod_proxy (CVS from Thursday) in front.

We've gone through a few thousand hits now with this setup, so I think it
is safe to say that the lobotimized (HTTP/1.0-only) mod_proxy is
wonderfully stable.  I can't vouch for caching, but IMHO adding an option
to downgrade to HTTP/1.0 would be the only thing necessary to reintegrate
mod_proxy back into the httpd source tree.  I'm sure there are a lot of
people who will want to run a setup similar to mine, with Apache 2.0.x
beta in front and Apache 1.3.x with special modules in back, who will
run Apache 2.0 as soon as mod_proxy is available in the package.  -Nathan

On Sun, 22 Apr 2001, Chuck Murcko wrote:

> Um, what version of httpd are you talking about, BTW? 8^)
>
> On Sunday, April 22, 2001, at 01:05 AM, Chuck Murcko wrote:
>
> > Both chunking and persistent connections need some work. I thought I
> > was crazy, since no one seems to have seen the persistent connection
> > problem save me until now.
> >
> > Thanks. The idea of a runtime downgrade option to 1.0 might be useful
> > in the long run, not just the beta timeframe.
> >
> > Chuck
> >
> > On Saturday, April 21, 2001, at 07:48 PM, Nathan Lutchansky wrote:
> >
> >> Hi again,
> >>
> >> It seems that mod_proxy does not support chunked responses.  Is this
> >> correct, or do I have something configured wrong?
> >>
> >> Many of the generated responses from Apache 1.3, particularly those for
> >> error and redirect messages, are sent in chunked format.  Thus, any 404
> >> messages sent from my backend server do not get displayed by the client
> >> browser, and instead the user gets a blank page.
> >>
> >> I changed proxy_http.c to send HTTP/1.0 requests instead, and now it
> >> seems
> >> to work fine.
> >>
> >> Perhaps we could have a run-time configuration directive to force
> >> mod_proxy to use HTTP/1.0?  At least until chunked replies are
> >> implemented, anyway.  I'm sure this problem will be noticed as soon as
> >> mod_proxy makes it into the Apache 2.0 distribution if it is not at
> >> least
> >> documented.
> >>
> >> Thanks.  -Nathan
> >>
> >> On Sat, 21 Apr 2001, Nathan Lutchansky wrote:
> >>
> >>> Hello everyone,
> >>>
> >>> I'm in the process of upgrading my webserver to Apache 2.0, but
> >>> since I
> >>> need mod_php and mod_perl, I'm leaving Apache 1.3.12 running on a
> >>> different port to service some parts of the site.  Thus my need for
> >>> mod_proxy.
> >>>
> >>> I installed mod_proxy from CVS on Thursday, so I believe it's still
> >>> up to
> >>> date.  It went into Apache 2.0.16 as static, after several hours of
> >>> fighting trying to get the .so to build correctly.  Argh.  This is a
> >>> known
> >>> problem, though.
> >>>
> >>> Anyway, now that it's all up and running, I'm pretty happy with it.
> >>> I'm
> >>> using it with both ProxyPass and the RewriteRule [P] flag and it all
> >>> seems
> >>> to work fine.
> >>>
> >>> The one problem I'm having is that keepalive doesn't seem to work
> >>> correctly.  The symptom is that loading documents that are already
> >>> cached
> >>> take 15-20 seconds *each* to load, when all that is being returned
> >>> is a
> >>> 304 status code.  This is a pain when loading a page with a large
> >>> number
> >>> of graphics as it can take several minutes to complete.  This problem
> >>> occurs with both Mozilla 0.8.1 and MSIE 5.x.
> >>>
> >>> When the following conditions are true, there is a 15-20 second delay
> >>> in
> >>> getting back a response:
> >>>
> >>> 1) The browser supports keepalive.
> >>> 2) The browser has the current page in the cache.
> >>> 3) Current mod_proxy 2.0 is talking to an HTTP/1.1 backend server.
> >>> 4) The backend returns a 304 status code for the request.
> >>>
> >>> The workaround is to put a "SetEnv nokeepalive" on the backend server
> >>> to
> >>> disable keepalive on proxied requests.  I've also tried putting
> >>> "SetEnv
> >>> force-response-1.0" and "SetEnv downgrade-1.0" but they did not solve
> >>> the
> >>> problem.
> >>>
> >>> Interestingly, when the browser does not have the page in its cache,
> >>> keepalive seems to work fine when passing the full page back to the
> >>> client.
> >>>
> >>> I hope this is enough information to track down the problem.  -Nathan
> >>>
> >>>
> >>
> >> --
> >> +-------------------+---------------------+------------------------+
> >> | Nathan Lutchansky | [EMAIL PROTECTED] |  Lithium Technologies  |
> >> +------------------------------------------------------------------+
> >> |  I dread success.  To have succeeded is to have finished one's   |
> >> |  business on earth...  I like a state of continual becoming,     |
> >> |  with a goal in front and not behind. - George Bernard Shaw      |
> >> +------------------------------------------------------------------+
> >>
> >>
> >
> Chuck Murcko
> Topsail Group
> http://www.topsail.org/
> >
>

-- 
+-------------------+---------------------+------------------------+
| Nathan Lutchansky | [EMAIL PROTECTED] |  Lithium Technologies  |
+------------------------------------------------------------------+
|  I dread success.  To have succeeded is to have finished one's   |
|  business on earth...  I like a state of continual becoming,     |
|  with a goal in front and not behind. - George Bernard Shaw      |
+------------------------------------------------------------------+

Reply via email to