Return-Path: Delivered-To: new-httpd-archive@hyperreal.org Received: (qmail 5337 invoked by uid 6000); 14 Jul 1998 19:50:33 -0000 Received: (qmail 5330 invoked from network); 14 Jul 1998 19:50:31 -0000 Received: from mail2.digital.com (204.123.2.56) by taz.hyperreal.org with SMTP; 14 Jul 1998 19:50:31 -0000 Received: from pachyderm.pa.dec.com (pachyderm.pa.dec.com [16.4.16.23]) by mail2.digital.com (8.8.8/8.8.8/WV1.0f) with SMTP id MAA09367; Tue, 14 Jul 1998 12:50:30 -0700 (PDT) Received: by pachyderm.pa.dec.com; id AA09121; Tue, 14 Jul 1998 12:50:29 -0700 Date: Tue, 14 Jul 1998 12:50:29 -0700 From: jg@pa.dec.com (Jim Gettys) Message-Id: <9807141950.AA09121@pachyderm.pa.dec.com> X-Mailer: Pachyderm (client pachyderm.pa-x.dec.com, user jg) To: new-httpd@apache.org Cc: Alexei Kosut In-Reply-To: Subject: Re: request that we support TE Mime-Version: 1.0 Content-Type: text/plain Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org > Sender: new-httpd-owner@apache.org > From: Alexei Kosut > Date: Tue, 14 Jul 1998 12:42:20 -0700 (PDT) > To: new-httpd@apache.org > Subject: Re: request that we support TE > ----- > On Tue, 14 Jul 1998, Dean Gaudet wrote: > > > While it's a good thing to support, it's not a walk in the park. This > > comes down to needing a more generic form of caching, which is on the > > plate for 2.0. Someone could do a mod_te for 1.3 with only moderate > > effort in my opinion, it wouldn't be perfect, but it could do the job. > > I'm confused. I pulled up a copy of draft-ietf-http-vt11-spec-rev-03, and > read over the TE section. AFAIK, Apache doesn't need to do a thing in > order to implement it, because we support use any transfer codings except > identity and chunked (although I guess we *could* parse the header to > determine if the client perfers chunked over identity for a request where > we could serve either, i.e., entities with content-lengths, but that seems > trivial). > > Is there something here I'm missing? Is he saying we should also implement > other transfer-codings, e.g., deflate? In that case, of course, TE would > make sense to implement... Yes, I'm saying that transfer-coding deflate (and gzip, but it isn't as efficient as deflate due to the unneeded file overhead) is a good thing... To do so in a routine way that is cache safe, you need to deal with TE. As I said, RFC2068 is buggy in this area, and TE is the fix. - Jim -- Jim Gettys Digital Industry Standards and Consortia Compaq Computer Corporation Visting Scientist, World Wide Web Consortium, M.I.T. http://www.w3.org/People/Gettys/ jg@w3.org, jg@pa.dec.com