httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Spero <>
Subject Re: HTTP/1.1 implementation speeds (was Re: votes for 0.6.3)
Date Fri, 05 May 1995 01:17:45 GMT
On Thu, 4 May 1995, Brian Behlendorf wrote:

> Rob McC could probably answer here when he's not busy, but I'm guessing 
> that the benefits of HTTP/1.1 won't be nearly as subtle as content 
> negotiation and that once 1.1 is officially proposed they'll start 
> implementing it on both the server and browser side.  

I wish I could reproduce my live-action HTTP/1.0 vs HTTP/1.1 vs HTTP-NG 
performance piece from Darmstadt (Tim and Henrik were great in the role 
of client and server :-)..

You can get a lot of the benefits of persistent connections from these 
new protocols even if only two machines in the entire world ever ran 
them- just set up two proxy servers at each end of the intercontinental 
link, and you can avoid latency over the longest pipe. 

One suggestion I did push which had a fair reception (though there are 
some good arguments against it) is using HTTP-NG in its simplest form as 
the packetiser and multi-plexing component of HTTP/1.1. 

HTTP-NG uses a simple packetising protocol (SCP). SCP basically just 
sticks a channel identifier and a length count in front of each chunk of 
data, together with a few flags to do things like close or abort a 
channel. HTTP-NG also has a request "HTTP-TOS" which is basically 
designed to carry an HTTP/1.0 request, and then recieve an HTTP/1.0 
response (This request type was originally included to solve a problem 
with gateway S-HTTP and MDA (which I just have to support in MDMA)), but 
turns out to make retrofitting existing servers really easy (little bit 
of wrapper magic to get the packets, and a little bit of search and 
replace on the send_foo files to not send straight to the file 

HTTP-NG allows a lot of the cool stuff like interleaving streams and 
responding to requests out of order to be disabled; it also negotiates 
the type of requests which each system handles (it's designed for 
incremental implementation).

If anybody's interested I'll knock of a quick draft of NG-lite containing 
just the bits needed to run in this profile. I could also include the 
necessary parsing code (it's not rocket science - hell, it's barely 
safety match science :-)

My current idle-task is trying to change apache to make the back end more 
protocol independent (less writing straight to the socket) and to make 
the  code re-runnable (fixing all the dies). I should have the java-ng 
client going soon, and I'd like to be able to test against a non-threaded 


  Warning: Do not write code in java and immediately after try to write 
code in C++; you don't realise how broken C++ is until you use a language 
so similar to C++, but which  does the right thing for so many of 
those things that C++ gets wrong.....

View raw message