httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chuck Murcko <ch...@topsail.org>
Subject Re: [PATCH] mod_proxy Keepalives
Date Mon, 02 Apr 2001 14:01:21 GMT
Greg Stein wrote:
> 
> On Mon, Apr 02, 2001 at 02:55:11AM -0400, Chuck Murcko wrote:
> > Graham Leggett wrote:
> > > Greg Stein wrote:
> >...
> > > > Further, using a conn_rec for an *outbound* connection is just wrong.
Yes,
> > > > there is a tiny bit of similarity. But things like base_server,
> > > > vhost_lookup_data, remote_logname, double_reverse, local_ip, local_host,
etc
> > > > ... none of those apply whatsoever to outbound connections.
> > >
> > > Using a conn_rec for an outbound connection has allowed us to use
> > > filters - which has cut down the proxy code by an enormous amount.
> > > Outbound connections are almost identical to inbound ones - once the
> > > status or request lines have been removed both outbound and inbound
> > > requests are virtually the same.
> >
> > Greg, are you suggesting we need to reimplement filters for outbound
> > connects (in general) to gain their benefits? That just sounds like too
> > big a bit of reusability to toss. I mean, it sure looks to me like
> > there's at least as much stuff in a conn_rec that an outbound connect
> > can use as there is that it can't. And what's not used is a matter of
> > bytes per connection, not a large amount of wastage.
> 
> The filters should not be tied to request_rec or conn_rec. Unfortunately,
> they are.
> 
> I'd be most interested in understanding how the proxy-outbound filters you
> are using (I forgot the list) are tied to the conn_rec. If we can discover
> how they are tied, then we can get them fixed.
> 
Gotcha, I was trying to ease into the bigger issue you're addressing.
The primary reason for doing this is to be able to use the dechunk
filter, as Graham points out in his original keepalive patch for the
proxy (in which case, he's trying to get the http handler's conn_rec
into the filter chain, via the regular conn_rec that's carried in
request_rec):

Known Bugs:

- Lack of DECHUNK support from downstream server.

If a downstream server sends a response that is chunked, there is no way
for the proxy to determine the content length. As a result the
connection between the proxy and the downstream server hangs until the
downstream server times out it's connection, causing a delay.

There is a DECHUNK filter inside Apache - but it depends on a
request_rec
being available. In the ap_proxy_http_handler() there is only a conn_rec
defined, but no request_rec. Any ideas on the correct way to fix this?

That last question is what we're really trying to find an answer for.

> Filters are arranged as a simple chain. Somewhere, you record the head of
> that chain, and you organize how items are inserted into a current/active
> chain. I don't believe that conn_rec.output_filters is any benefit to you;
> the filter system itself: yes. I believe you can use the filters, and that
> you can use them without needing a conn_rec.
> 

Agreed, as long as we're writing new filters.

> Summary: for expediency, I can see how you may want to use a conn_rec. But
> please recognize and (I hope) make it a long-term goal to remove them. As a
> precondition, that means the (builtin) filters that you want to use need to
> fixed. I'd totally agree to those fixes on two reasons: make the filters
> more isolated/independent/less-coupled, and enable mod_proxy to stop using
> conn_rec for outbound connections.
> 
> [ consider: any filter referencing a conn_rec or a request_rec becomes
>   tightly coupled with the Apache system. And ideal filter is just massaging
>   data that flows through it. ]
> 

OK, I see what you're saying now. But that also means that a conn_rec
has really come to be rather more of a server_conn_rec.
-- 
Chuck
Chuck Murcko
Topsail Group
chuck@topsail.org

Mime
View raw message