RE: What is Content-Length?

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.

Anybody know of such implementations?

Paul

> ----------
> From: 	Larry Masinter[SMTP:masinter@parc.xerox.com]
> Sent: 	Wednesday, December 17, 1997 10:43 AM
> To: 	Josh Cohen
> Cc: 	'koen@win.tue.nl'; mogul@pa.dec.com;
> http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> Subject: 	Re: What is Content-Length?
> 
> We need to resolve the issue of content-length and cascaded
> transfer encodings quickly. We need two interoperable
> implementations of this 'feature', even if it is implicit in
> the spec, or else we should restrict the allowed set.
> 
> I don't think we should explore too many degrees of freedom.
> 
> * chunked is only allowed once, as the last transfer encoding
>   applied.
> * before chunked is applied, only one T-E should be sent,
>   but recipients should accept all combinations (as long as
>   there are no duplicates).
> * no T-E's other than 'chunked' may be applied to multipart/
>   content-types, but T-Es are allowed within a multipart type
>   (e.g., multipart/byte-ranges, multipart/form-data).
> 
> The entire transmission is required to be either with content-length
> or else self-delimited where multipart is the only self-delimited
> media type, but chunked, gzip are self-delimited T-Es.
> 
> 
> -- 
> http://www.parc.xerox.com/masinter
>

Received on Wednesday, 17 December 1997 13:04:06 UTC