(Message HTTP-TOEDIT:553) Return-Path: mogul@pa.dec.com Received: by zorch.w3.org; id AA10295; Thu, 27 Feb 1997 22:05:49 -0500 Received: from mail2.digital.com (mail2.digital.com [204.123.2.56]) by www10.w3.org (8.7.5/8.7.3) with SMTP id WAA06928; Thu, 27 Feb 1997 22:05:43 -0500 (EST) Received: from acetes.pa.dec.com by mail2.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA24271; Thu, 27 Feb 1997 19:01:01 -0800 Received: by acetes.pa.dec.com; id AA22432; Thu, 27 Feb 97 19:01:00 -0800 Message-Id: <9702280301.AA22432@acetes.pa.dec.com> To: Henrik Frystyk Nielsen Cc: jg@w3.org, fielding@liege.ICS.UCI.EDU, mogul@pa.dec.com Subject: Other Problem with use of Byte Ranges in HTTP/1.1 In-Reply-To: Your message of "Wed, 26 Feb 97 11:03:25 EST." <3.0.1.32.19970226110325.0098a9a0@pop.w3.org> Date: Thu, 27 Feb 97 19:00:59 PST From: Jeffrey Mogul You also noted: Another problem with byte ranges is that they require the server to know the total content-length of the object in order to generate the "Content-Range" header. Especially, this prevents clients to ask to, say the first 5000 bytes, of streamed audio or other objects where the server normally would use chunked encoding. I guess we hadn't really thought throught the issues surrounding range requests on objects of unknown length. After all, if the server doesn't know the total length, then the client doesn't know the total length either, so how is it supposed to know when it has all of the byte-ranges that cover the object? However, this problem doesn't prevent the client from asking for a byte-range, since the Range request doesn't have to indicate whether the client knows the object total size or not. It simply prevents the server from answering with 206, which means that it would have to answer with 200. There are two cases here. One is the case where the client doesn't have any of the content yet, so is doing something like asking for the first 500 bytes. In this case, the 200 response gives the client more than it wanted (but this is always a risk, since the server is not required to implement ranges). In most cases, it's not such a big problem, since sooner or later the client would presumably want the entire object. Note that the server could send "Accept-ranges: none", although this might not be that useful if the client has never seen the object before. In the other case, the client is trying to fill in a hole in its cache. There are two ways that a hole can be created; a previous subrange response (but that couldn't have happened here), or a transfer that failed partway through. In this case, we would like to restart the transfer in the middle, but (according to the current spec) the server would have to start from scratch (exactly what has to happen in HTTP/1.0). However: I'll grant you that there might be some cases (such as the recovery from a truncated transfer) where it's nice for the server to be able to send a 206 response without knowing how long the total content will be. Perhaps we could change the BNF in section 14.17 from byte-content-range-spec = bytes-unit SP first-byte-pos "-" last-byte-pos "/" entity-length To byte-content-range-spec = bytes-unit SP first-byte-pos "-" last-byte-pos "/" ( entity-length | "*" ) With "*" meaning "unknown". I'm not 100% certain that this would work, but then I can't recall if we ever discussed the requirement for the total length. Presumably, the "last" Content-Range for a resource should still include the entity-length, or the client doesn't know when it is done. But I'm not sure if there is an easy way to do this for a streaming (but finite) resource. Add this to the issues list, I guess. -Jeff