Received: by taz.hyperreal.com (8.8.3/V2.0) id KAA15797; Tue, 3 Dec 1996 10:50:33 -0800 (PST) Received: from paris.ics.uci.edu by taz.hyperreal.com (8.8.3/V2.0) with SMTP id KAA15793; Tue, 3 Dec 1996 10:50:29 -0800 (PST) Received: from liege.ics.uci.edu by paris.ics.uci.edu id aa18804; 3 Dec 96 10:29 PST To: new-httpd@hyperreal.com Subject: Re: Blaze?? In-reply-to: Your message of "Tue, 03 Dec 1996 15:17:39 GMT." <199612031517.PAA00295@aaaaaaaa.demon.co.uk> Date: Tue, 03 Dec 1996 10:29:13 -0800 From: "Roy T. Fielding" Message-ID: <9612031029.aa18804@paris.ics.uci.edu> Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@hyperreal.com > More on this Blaze thing. Suppose you had two xSpeed aware poxies > back to back. They could send requests to each other with 'Accept: > xSpeed/compressed' (or some such MIME), and once satisfied could > then do the compression/encapsulation dance to send responses. They don't even need that. See the Upgrade header in HTTP/1.1. > Mmm, besides, once two proxies have identified that they understand > the same transfer protocol they can just open a UDP line and send > their information down that, provided it doesn't abuse HTTP's > various safeguards. > > Roy F, is this just hokum? Is there already a sensible mechanism > for speeding up transfers between Proxies that doesn't go against > the letter of the HTTP law? The idea was for HTTP/2.0 to be a multiplexing, tokenized protocol. The only thing it lacked was an persistent person to do the work of defining it, as I did for HTTP/1.x. The Upgrade header is the graceful deployment mechanism. Henrik already has a working version of this for Jigsaw. Using a proprietary protocol for this kind of thing would be really stupid. .....Roy