- From: Larry Masinter <masinter@parc.xerox.com>
- Date: Thu, 11 Dec 1997 05:09:24 PST
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
I'm all for an editorial note about "Content-Length" that explains its difficulty in serving both as an entity length and a transfer length. In fact, this kind of confusion is, I believe, one of the reasons why content-length was deprecated for use in mail! So we're saddled with a legacy, and need some clear warnings that "Content-Length". It's less clear what "Transfer-Length" would buy us, since we've survived for so long without it. It sounds like a good conceptual aid ("we shoulda done it that way") but not a necessary protocol addition ("we need to do it this way now"). > I see no alternative other than rewriting the specification to make > Content-length a hop-by-hop general header and not an entity header. Unfortunately, this seems (to me, personally) to be the only way out. I believe that most implementations treat it this way, in any case. > The authentication specification would also need to be modified > since it is not possible to put Authentication-Info in a chunked > trailer as it is currently defined if Content-length is the length > of the chunked message. This seems acceptable to me; what do others think? We will need two interoperable digest implementations (two clients, two servers) that have been tested as interworking in conjunction with a 1.1 proxy that does rewriting of the transfer encoding. Is there any hope of setting up such a test during the weekly testing? Larry -- http://www.parc.xerox.com/masinter
Received on Thursday, 11 December 1997 05:12:43 UTC