- From: Mark Nottingham <mnot@mnot.net>
- Date: Sat, 15 Sep 2012 10:07:48 +1000
- To: "Fall, Kevin" <kfall@qualcomm.com>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Comments below. On 14/09/2012, at 1:48 AM, "Fall, Kevin" <kfall@qualcomm.com> wrote: > Hi all. > I originally posted the question below to the authors of the range-related ID, but they suggested I post to the entire list. I just joined and am now doing so. Please see the questions below. > > To provide a bit more background, these questions are coming up in the context of MPEG-DASH, where (potentially real-time generated) media segments are being fetched by a client via HTTP, possibly with Range requests. As a possible alternative to what I mentioned below in the second half, would it be possible to clarify the use of "Range: 0-" as a request for 'whatever you have available for me right now'. > > Thanks, > - Kevin > > From: <Fall>, Kevin Fall <kfall@qualcomm.com> > Date: Wednesday, September 12, 2012 3:51 AM PDT > To: "fielding@gbiv.com" <fielding@gbiv.com>, "ylafon@w3.org" <ylafon@w3.org>, "julian.reschke@greenbytes.de" <julian.reschke@greenbytes.de> > Subject: question/comment on draft-ietf-httpbis-p5-range-20.txt > > Hi folks- > > I was just reading over draft-ietf-httpbis-p5-range-20 and have two small comments/questions. > First, I see there are no examples where the multipart/byteranges response contains multiple ranges that are out of order. > As far as I can tell this is ok, but not explicitly mentioned or provided in an example. If, indeed, this is ok, I believe it would be helpful to mention or illustrate. Section 4.1 <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p5-range.html#rfc.section.4.1> says: """When a client asks for multiple ranges in one request, the server should return them in the order that they appeared in the request.""" > Perhaps more controversial, Section 3.1 requires a Partial Content request to only be permitted if the corresponding request had a Range header field. > We at least have one case where it would be rather useful to allow a Partial Content / Content-Range response even if the request didn't include the Range header. > Would it be possible to consider replacing MUST with SHOULD in line #2 of Section 3.1? (along with maybe replacing 'partial GET' with simply 'GET' in line #1)? > [or similar wording such as Content-Range responses SHOULD only be present in responses if partial GETs were the request types]. I can explain the use case > in more detail if interested. This can't be changed; it would change the semantics of a 200 response for clients that don't understand partial content, which is OPTIONAL. Regards, -- Mark Nottingham http://www.mnot.net/
Received on Saturday, 15 September 2012 00:08:16 UTC