- From: Peter <cnmjbm@gmail.com>
- Date: Fri, 23 Jan 2009 12:23:52 -0800
- To: <ietf-http-wg@w3.org>
Hi, Adrien. Thanks a lot for your response. In Sec 4.4 of RFC 2616, there seems another alternative way (ie. "multipart/...") to decide message length. If there is other alternative than chunking, why would you think chunking is a MUST? Thanks. peter ----- Original Message ----- From: "Adrien de Croy" <adrien@qbik.com> To: "Peter" <cnmjbm@gmail.com> Cc: <ietf-http-wg@w3.org> Sent: Friday, January 23, 2009 11:56 AM Subject: Re: A question about Content-Length header > > there is no other way to signal the end of the message that the client > is sending. > > A server has the option to close the connection to signal end of message > if no Content-Length or chunking is not used. A client for obvious > reasons does not have this option. > > So in short, I would say the answer is yes, if the client message has an > entity body, and it will not send a Content-Length for whatever reason, > it must use chunking. > > Adrien > > > Peter wrote: >> >> Hi, Julian. >> >> Thanks for your response. >> >> Frustratedly, i still did not get an explicit answer from reading the >> section. >> >> Perhaps i should ask it this way: >> >> MUST an HTTP 1.1 *client* transfer-encode a message body in chunks >> and send Transfer-Encoding header if the client can/will not send >> Content-Length header for some reason? >> >> Looking forward to a either "YES" or "NO" answer according to official >> interpretation of RFC 2616. >> >> Thanks!! >> >> peter >> >> > > -- > Adrien de Croy - WinGate Proxy Server - http://www.wingate.com >
Received on Friday, 23 January 2009 20:27:47 UTC