Return-Path: hallam@zorch.w3.org To: jg@w3.org, Subject: Proposed change to wording on chunked. Date: Wed, 13 Mar 96 14:49:42 -0500 From: hallam@zorch.w3.org X-Mts: smtp Content-Length: 1995 Issue list: Definition of chunked encoding as presently stated may require unreasonable and unnecessary modification of client/server software architectures. Future revisions may need to transmit attributes on a per chunk basis and proxies/gateways should be prepared to deal with such messages even if they do not generate them. Rationale:- 1) Minimize the impact of footers on existing code architectures. It is inconvenient for a client to recieve the type of an entity only after recieving the bytes. Footers are likely to be restricted to dealing with checksum and signature operations. 2) Allow for future revisions of the spec to send chunk attributes without breaking 1.1 recipients. Change:- Section 3.6: Chunked-Body = *chunk "0" CRLF footer CRLF chunk = chunk-size [" " chunk_attr] CRLF chunk-data CRLF chunk_attr = *text chunk-size = hex-no-zero *HEX chunk-data = chunk-size(OCTET) footer = * hex-no-zero = Note that the chunks are ended by a zero-sized chunk, followed by the footer and terminated by an empty line. 1.1 compliant agents should be tolerant of chunk attributes (chunk-attr) when present but should not attempt to generate them. Future HTTP versions may specify a more restrictive syntax for chunk attributes. An example process for decoding a Chunked-Body is presented in Appendix C.5. Section 7.1 Entity-Footer = Content-MD5 | extension-header [NB, I am also going to suggest at a later point that we drop content-md5 out of the 1.1 spec since MD5 is less than entirely satisfactory as a digest mechanism and it is inappropriate to incorporate it as a tag - even if another group got it wrong. also the license for MD5 means that the tag would have to be changed to Content-RSA-MD5 in any case.] Phill