W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2011

Re: an edit for easy reading on 5.4.1 "byte ranges"

From: Yves Lafon <ylafon@w3.org>
Date: Tue, 30 Aug 2011 08:46:11 -0400 (EDT)
To: Dale Anderson <dra@redevised.net>
cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <alpine.DEB.1.10.1108300835540.21549@wnl.j3.bet>
On Fri, 26 Aug 2011, Dale Anderson wrote:

> Missing a couple words there in my suggestion. Some tech-writing
> background, eh? Here's what I meant, sorry 'bout that.
>
> """
>   If a syntactically valid byte-range-set includes at least one byte-
>   range-spec whose first-byte-pos is less than the current length of
>   the representation, or at least one suffix-byte-range-spec with a
>   non-zero suffix-length, then the byte-range-set is satisfiable.
>   Otherwise, the byte-range-set is unsatisfiable.
>
>   If the byte-range-set is satisfiable, then the server SHOULD return
>   a response with a 206 (Partial Content) status code containing the
>   satisfiable ranges of the representation.
>
>   If the byte-range-set is unsatisfiable, then the server SHOULD return
>   a response with a 416 (Requested range not satisfiable) status code.
> """

The definition of a satifiable range will be reworked soon, in light of 
ticket 311
http://trac.tools.ietf.org/wg/httpbis/trac/ticket/311
and the thread starting at 
https://mail-archives.apache.org/mod_mbox/httpd-dev/201108.mbox/%3Calpine.DEB.2.00.1108231306230.24177@eru.sfritsch.de%3E

ex: end of 5.4.1 says
<<
Several legal but not canonical specifications of the second 500
       bytes (byte offsets 500-999, inclusive):

         bytes=500-600,601-999
         bytes=500-700,601-999
>>
So count overlapping ranges as one range only;
In Appendix A:
<<
When an HTTP 206 (Partial Content) response message includes the
    content of multiple ranges (a response to a request for multiple non-
    overlapping ranges), these are transmitted as a multipart message-
    body ([RFC2046], Section 5.1).
>>

So it calls out overlapping range, but more by reference than explicitely, 
and needs to be fixed.
Thanks,

> 2011/8/26 Dale Anderson <dra@redevised.net>:
>> A potential good edit on part 5:
>>  - In eighth paragraph of 5.4.1 "byte ranges"
>>
>> """
>>   If a syntactically valid byte-range-set includes at least one byte-
>>   range-spec whose first-byte-pos is less than the current length of
>>   the representation, or at least one suffix-byte-range-spec with a
>>   non-zero suffix-length, then the byte-range-set is satisfiable.
>>   Otherwise, the byte-range-set is unsatisfiable.  If the byte-range-
>>   set is unsatisfiable, the server SHOULD return a response with a 416
>>   (Requested range not satisfiable) status code.  Otherwise, the server
>>   SHOULD return a response with a 206 (Partial Content) status code
>>   containing the satisfiable ranges of the representation.
>> """
>>
>> I would paragraph break that after "Otherwise, the byte-range-set is
>> unsatisfiable" and consider changing the first recommendation to
>> address the satisfiable condition instead of unsatisfiable, and make
>> it two short paragraphs, like this.
>>
>> """
>>   If a syntactically valid byte-range-set includes at least one byte-
>>   range-spec whose first-byte-pos is less than the current length of
>>   the representation, or at least one suffix-byte-range-spec with a
>>   non-zero suffix-length, then the byte-range-set is satisfiable.
>>   Otherwise, the byte-range-set is unsatisfiable.
>>
>>   If the byte-range-set the server
>>   SHOULD return a response with a 206 (Partial Content) status code
>>   containing the satisfiable ranges of the representation.
>>
>>   If the byte-range-set is unsatisfiable, the server SHOULD return a
>> response with a 416
>>   (Requested range not satisfiable) status code.
>> """
>>
>> Just my tech-writing background kicking in there but I think it reads
>> more clearly.
>>
>> Regards,
>>
>> Dale Anderson
>>
>
>

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves
Received on Tuesday, 30 August 2011 12:46:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:47 GMT