W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1997

RE: What is Content-Length?

From: Paul Leach <paulle@microsoft.com>
Date: Wed, 17 Dec 1997 13:47:04 -0800
Message-Id: <5CEA8663F24DD111A96100805FFE6587203896@red-msg-51.dns.microsoft.com>
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 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:05 EDT