- 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