httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject HTTP + XML + SCP = HTTP/ng
Date Fri, 11 Feb 2000 00:03:23 GMT
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

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

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

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

- 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?


View raw message