- From: Henrik Nordstrom <hno@squid-cache.org>
- Date: Fri, 05 Jan 2007 06:56:37 +0100
- To: "Travis Snoozy (Volt)" <a-travis@microsoft.com>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Message-Id: <1167976597.14662.15.camel@henriknordstrom.net>
tor 2007-01-04 klockan 15:50 -0800 skrev Travis Snoozy (Volt): > Since it's possible for the client to detect when a Content-Length or > a chunk-length is too long, To be precise, what most programming langauges tells you (when used correctly) is that Content-Length could not be converted into the word-sise the application developer had selected for storing the said value internally in the application, not necessarily why it could not be converted. It is not realistic for the HTTP specification to expect that all implementations uses bignum for every integer which may be transmitted in the protocol. All that can be expected is that application developers recognize that failure to handle >2GB files is a bug if their users expects it to work, and that all parties who agree on handling files >2GB do it in the same manner at the protocol level and this is fulfilled fine by the specs as it is. The range-retreival question is purely hypothetical. A client which can not handle large integer values for content length won't be able to split it up in ranges either as the range specifications need numbers larger than the client can represent. And how clients store downloaded content is completely outside the concerns of the specification. A client is free to split downloaded files in many OS:level files if required, protocol specs do not care and must not care. > SHOULD the client then attempt a series of byte-range requests > instead? Why on earth should a client do that under these conditions? It most likely won't be able to reassemble the result, or even compose the range requests.. > Also, in regard to connection handling: as far as I can tell, the > client is going to have to close the connection if an oversized > Content-Length shows up, since the client won't be able to read > through to the next request reliably. Yes, unless it's seen acceptable to waste the network bandwidth sending the data to the bitbucket.. > If this is the case, is it specified? Does it need to? I think not. Regards Henrik
Received on Friday, 5 January 2007 05:56:53 UTC