httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Jim Gettys)
Subject Re: request that we support TE
Date Tue, 14 Jul 1998 19:50:29 GMT

> Sender:
> From: Alexei Kosut <akosut@leland.Stanford.EDU>
> Date: Tue, 14 Jul 1998 12:42:20 -0700 (PDT)
> To:
> 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.,

View raw message