httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: axe proxy support from 2.0?
Date Sat, 13 Nov 1999 01:01:58 GMT
On 12 Nov 1999 tvaughan@aventail.com wrote:
> Greg Stein <gstein@lyra.org> writes:
> > Now, to be clear: while I'd be happy to be the guy to rip proxy support
> > (fair enough that if I start a discussion to rip it out, then I better be
> > ready to volunteer for it :-), I'm not standing up to do the work for this
> > new stuff. Certainly, if somebody wants to just port over mod_proxy and do
> > the whole biz, then they're welcome to. I'm simply trying to shepherd the 
> > requirements around bringing the proxy stuff into 2.0.
> 
> I think it would be helpful to say which of these are more appropriate for
> apr too.

I was deferring that until after some semblance of consensus arrived :-)
But hey... all right.

> Like how about an http client library? One shared by ab and this 
> new "shiny object". Or perhaps this is a new library built on top of
> apr. And hooks to filter fetched resources would be nice too. Not that I
> can promise any of this myself either, but should I happen to have a spare
> weekend, it would be nice to know what would be accepted.

In one of my prior emails, I was going to say "just grab one of the HTTP
client libraries that are out there" but then realized that we'd probably
want to use APR.

I would think that a library built on APR would be most appropriate.

Filtering or not is pretty easy. To filter:

  while (1) {
    read data
    filter
    send data
  }

To just copy a remote resource:

  ap_sendfile(...)


In other words, the HTTP client lib probably ought to just expose an
ap_socket_t for the body rather than a higher-level concept.
(note that it might do some processing on the headers, though!)

> > Also note that I advocate removing forward proxy support. Many of the bugs
> > we have seem to deal with protocol issues around this. I would also
> > advocate killing FTP support for remote resources.
> 
> /I/ can live with this.

Excellent!

I'd love to be in a world with no more FTP. Just give me DAV...


On Fri, 12 Nov 1999, Jim Winstead wrote:
> On Nov 12, Greg Stein wrote:
> > I'm currently advocating dropping the term/thought/belief that we're a
> > forward/reverse proxy and just support fetching remote resources (with
> > optional/smart caching of those resources).
> 
> And where 'remote' can simply mean another port on the local machine.
> A bunch of mod_perl-enabled servers fronted by lightweight static/proxy
> servers, for example.

Sure. That would seem to be straight-forward, as I don't think the remote
fetching would care whether the target host is remote/local.

> In that case, it can also be useful to be able to pass some additional
> things to and from the backend server (so they can be logged by
> the front-end, for example). We've got some hacked-up solutions to
> that, but it would be nice to see a clean mainstream solution.

I think this would be a pretty straight-forward extension. Given an HTTP
client lib (as above), then the module that *uses* that lib could quite
easily expose various Apache config commands to insert stuff into the
request stream and/or parse headers/body from the response.

Cheers,
-g

--
Greg Stein, http://www.lyra.org/





Mime
View raw message