BTW, I think you are right Eric, I consider this a theoretical discussion at best -- the fact is that for client requests, the content-length should be present and I would consider it an error for it to be ommitted. The specification is primarily oriented towards data being sent BACK where the length may not be known in advance.
Practically speaking, were I developing a web server, I would error out with a 400/411 if I could not accurately detect the content length up front. mark > -----Original Message----- > From: Discussion of advanced .NET topics. > [mailto:[EMAIL PROTECTED] On Behalf Of Mark Smith > Sent: Tuesday, March 28, 2006 5:46 PM > To: [email protected] > Subject: Re: [ADVANCED-DOTNET] Retrieving all available data > on a Blocking TCP Listener Call... > > > Is that true for a client as well? I thought the client had to keep > > the connection open in order to receive the server's > response. I know > > the > > *server* can omit Content-Length and close the connection; but it > > seems that would be not-very-useful for a client to do. > > All header entity values apply to either client or server. > There's a whole section in the spec (section 4.4) that talks > about message lengths and how to determine them based on > Content-Length presence and Transfer-Encoding types. > > That said, for HTTP 1.1 applications, the server can respond > back with 400 (Bad request) or 411 (Length required) if it > wishes to insist on receiving a valid Content-Length. I > would certainly expect the length to be present in most cases > unless it's just a really old application. > > mark > > =================================== > This list is hosted by DevelopMentor. http://www.develop.com > > View archives and manage your subscription(s) at > http://discuss.develop.com =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
