httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgaudet-list-new-ht...@arctic.org>
Subject Re: [module porting] mod_proxy
Date Tue, 14 Mar 2000 19:53:16 GMT
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.

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.

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