On Thu, 11 Dec 1997, David W. Morris wrote: > > > On Thu, 11 Dec 1997, John Franks wrote: > > > I would prefer Content-length to be the length BEFORE any transfer > > encoding. From Scott's remarks it is clear this is what he > > understands content length to be. But if Content-length is length > > before transfer encoding we must introduce a Transfer-length header or > > forbid any future transfer encodings which are not self-delimiting. > > As I've already said, transfer encoding was introduced to resolve the > problem that some servers don't know the total length until > the whole document has been sent. That was the reason "chunked" was introduced. There are other reasons one might want to use a Transfer-encoding, e.g. compression to conserve bandwidth. > All future transfer encodings MUST > be self-delimiting. What is the basis of this assertion? I find no evidence this was the intent of the protocol authors. > It would be stupid to introduce a new header > whose value can't always be computed to define the length of > some possible new method of encoding. > Or it might be stupid to preclude the possibility of ever using lots of useful transfer encodings to avoid introducing a new header. Here's one scenario that I think people have in mind. A proxy receives documents, compresses them on the fly and caches the compressed version (saving disk space). When a client requests the document it is served in the compressed form (with the appropriate Transfer-encoding header) to save bandwidth. The proxy knows the compressed length; the client needs to know it for the transaction to work. John Franks john@math.nwu.eduReceived on Thursday, 11 December 1997 12:19:46 UTC
This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:04 UTC