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/masinterReceived on Thursday, 11 December 1997 05:12:43 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:16:28 UTC