- From: Paul Leach <paulle@microsoft.com>
- Date: Wed, 17 Dec 1997 13:47:04 -0800
- To: "'David W. Morris'" <dwm@xpasc.com>
- Cc: Josh Cohen <joshco@microsoft.com>, 'Larry Masinter' <masinter@parc.xerox.com>, "'koen@win.tue.nl'" <koen@win.tue.nl>, mogul@pa.dec.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> ---------- > From: David W. Morris[SMTP:dwm@xpasc.com] > Sent: Wednesday, December 17, 1997 1:21 PM > > > On Wed, 17 Dec 1997, Paul Leach wrote: > > > Before we can just "resolve quickly", I'm worried about the possibility > of > > existing implementations of (e.g.) > > > > Content-Length: XXX > > T-E: gzip > > > > <gzipped stuff, XXX bytes long> > > > > which means that C-L is, defacto, the length of the message-body. > > > > Absent info on such an implementation(s), we can invent lots of > internally > > consistent schemes, but they wouldn't conform to existing (presumably) > RFC > > 2068 compliant implementations. > > But then "Transfer-encoding: gzip" would be an extension to RFC2068. > It seems to me that by the rules, an extension we haven't heard about > can be ignored as experimental and subject to the risk of requiring > adjustment as standards change. > I last time I looked at the latest draft for HTTP/1.1, I thought I saw it specify T-E: gzip, so that that will be in the RFC that will be the Draft Standard. So you're right that it's an extension to RFC 2069, but the conclusion you draw from that is incorrect. Paul
Received on Wednesday, 17 December 1997 13:50:44 UTC