httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Sutherland <ja...@cam.ac.uk>
Subject Re: [module porting] mod_proxy
Date Tue, 14 Mar 2000 20:12:36 GMT
On Tue, 14 Mar 2000, Dean Gaudet wrote:

> On Tue, 14 Mar 2000, James Sutherland wrote:
> 
> > Sorry - I wasn't meaning a full-blown proxy. Rather, I was thinking in
> > terms of the setup many big Apache installations use - a reverse proxy
> > front-end, with "full size" Apache backend servers. This proxy doesn't
> > handle FTP, or indeed connections to anything other than the backend
> > Apache daemons.
> 
> heh.  see the new-httpd archives for the first two weeks of february.  
> i've included a relevant message from the threads below.

With the exception of SSL support, Squid does all of what is described in
that post. This isn't quite what I had in mind - I wasn't thinking in
terms of a cache, or any protocol handling, just simple load-balancing and
buffering. Mainly aimed at off-loading the encryption work to a seperate
box, as well as simplifying the load-balancing requirements.

> it's nice to see this theme has gone from repeating every 6 months to
> repeating every month.  :)
> 
> i think a lot of us agree that these ideas are good.  we just need folks
> to code it.  i'm going to be really honest and say that i can't code this
> project -- too many other things competing for my attention.  but i'm
> totally here to help with the design and debugging after the first
> prototypes exist.

OK... I'll make a start on the front-end bit, see how that goes. (Hint to
anyone from Sun: a nice Starfire so I can test /dev/poll support would
help :)

> Dean
> 
> On Thu, 10 Feb 2000, Dean Gaudet wrote:
> > 
> > Date: Thu, 10 Feb 2000 16:03:23 -0800 (PST)
> > From: Dean Gaudet <dgaudet@arctic.org>
> > To: new-httpd@apache.org
> > Cc: tomcat-dev@tomcat.apache.org, jserv-dev@list.working-dogs.com, Simon Spero <ses@tipper.oit.unc.edu>
> > Subject: HTTP + XML + SCP = HTTP/ng
> > X-comment: visit http://www.arctic.org/~dean/legal for information regarding copyright
and disclaimer.
> > Reply-To: new-httpd@apache.org
> > 
> > On Mon, 7 Feb 2000, Martin Pool wrote:
> > 
> > > Given the state of Java and HTTP today I wonder whether it would be
> > > better to build a toolkit of Java classes for building HTTP servers,
> > > rather than using AJP to plug into Apache.
> > 
> > that's what i was advocating.
> > 
> > > Where's Apache going to go in the future?  Is it going to be a single
> > > big do-everything program, or a cluster of complementary projects?  
> > 
> > i hope not, but unfortunately there's a little bit of momentum... i've
> > made a couple attempts to suggest ways we could split it up.  but i don't
> > have the energy to evangelise the topic.
> > 
> > so one of the points i brought up earlier in the thread hasn't been
> > addressed:  what problems are people trying to solve?
> > 
> > the web applications of which i'm aware are essentially composed of:
> > 
> > - static content
> > - dynamic content which is cacheable (i.e. almost static)
> > - dynamic content which is uncacheable
> > 
> > the best url design includes all these components under the same hostname.  
> > so either all the services end up on one box, or some sort of front-end is
> > required.
> > 
> > both apache and squid perform as front-ends today.
> > 
> > if we had a front-end server with the following feature set:
> > 
> > - full HTTP/1.1 proxy cache
> > - HTTP/1.1 server capable of serving static files
> > - uses async i/o at least for serving static files (which includes
> >   files in the proxy cache)
> > - capable of dividing the urlspace amongst different pools of
> >   backend servers
> > - capable of load balancing amongst several backends within a pool
> > - handles persistant/pipelined connections with clients and with
> >   backends
> > - SSL
> > 
> > in this scenario i would expect the back-ends to talk http.  the front-end
> > would parse the incoming request and either handle it from disk/cache, or
> > pass it through to a back-end.
> > 
> > then i'd really like to know what applications can't be solved?  real
> > world examples please, you know how much of a pain i am :)
> > 
> > i mean i can think of some.  consider authentication.  you might want your
> > entire urlspace to live behind an auth method which you want to implement
> > in java to talk to your databases in some way.  but you've got portions of
> > your urlspace served by static files, some served by perl, and some served
> > by java.
> > 
> > well, the front-end could make a SOAP request (XML over HTTP) to your java
> > back-end, and presumably your java back-end can return a response which is
> > temporarily cacheable.  the front-end keeps that in its proxy cache...  
> > (or heck it could just proxy a HEAD request... my point is that it can
> > just pass the entire client request to the backend.)
> > 
> > anyhow we could go through each phase of the current module API and come
> > up with an application... but when i sit down and think about these things
> > i frequently find myself showing that a particular api phase just isn't
> > needed.
> > 
> > aren't the php and java back-ends just content handlers today?  they don't
> > even touch other API phases right?
> > 
> > i honestly don't see the point of CORBA, or any of the other binary
> > protocols.
> > 
> > - they require more code, which clobbers L1 cache efficiency (which i'm
> > willing to bet will eliminate any perceived benefit you're hoping for by
> > making things binary)
> > 
> > - they require us to document the interfaces and be careful about defining
> > semantics... whereas HTTP/1.1 proxying is well defined by rfc2616, that
> > work is done for us already.
> > 
> > - some of us haven't had the patience to keep up with the object protocol
> > acronym soup of the day ;)
> > 
> > - most of us will end up using XML anyhow, and we've already got XML
> > libraries in our codebases (this is if we even need SOAP)
> > 
> > - code reuse #1
> > 
> > about the only extension to HTTP which i think we might want to consider
> > is Simon Spero's SCP -- session control protocol.  (you can find a version
> > of it named TMP used without credit in rfc2371).  SCP allows you to
> > optimise front-end/back-end communications by multiplexing multiple
> > streams into one tcp session... big performance boost from this.
> > 
> > HTTP + XML + SCP = HTTP/ng :)
> > 
> > other than C and java libraries implementing SCP, what's missing?
> > 
> > Dean
> > 
> > 
> 
> 


Mime
View raw message