Ignore:
Timestamp:
23/01/13 10:21:37 (8 years ago)
Author:
fielding@…
Message:

(editorial) more cleanup in p5

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p5-range.xml

    r2147 r2150  
    229229</artwork></figure>
    230230<t>
    231    The first-byte-pos value in a byte-range-spec gives the byte-offset
    232    of the first byte in a range. The last-byte-pos value gives the
    233    byte-offset of the last byte in the range; that is, the byte
    234    positions specified are inclusive. Byte offsets start at zero.
    235 </t>
    236 <t>
    237    Examples of byte-ranges-specifier values:
     231   The <x:ref>first-byte-pos</x:ref> value in a <x:ref>byte-range-spec</x:ref>
     232   gives the byte-offset of the first byte in a range.
     233   The <x:ref>last-byte-pos</x:ref> value gives the byte-offset of the last
     234   byte in the range; that is, the byte positions specified are inclusive.
     235   Byte offsets start at zero.
     236</t>
     237<t>
     238   Examples of <x:ref>byte-ranges-specifier</x:ref> values:
    238239  <list style="symbols">
    239240     <t>The first 500 bytes (byte offsets 0-499, inclusive):
     
    250251</t>
    251252<t>
    252    If the last-byte-pos value is present, it &MUST; be greater than or
    253    equal to the first-byte-pos in that byte-range-spec, or the byte-range-spec
    254    is syntactically invalid. The recipient of a byte-range-set
    255    that includes one or more syntactically invalid byte-range-spec
    256    values &MUST; ignore the header field that includes that byte-range-set.
    257 </t>
    258 <t>
    259    If the last-byte-pos value is absent, or if the value is greater than
    260    or equal to the current length of the representation data, last-byte-pos is
    261    taken to be equal to one less than the current length of the representation
    262    in bytes.
    263 </t>
    264 <t>
    265    By its choice of last-byte-pos, a client can limit the number of
    266    bytes retrieved without knowing the size of the representation.
     253   A <x:ref>byte-range-spec</x:ref> is invalid if the
     254   <x:ref>last-byte-pos</x:ref> value is present and less than the
     255   <x:ref>first-byte-pos</x:ref>.
     256</t>
     257<t>
     258   A client can limit the number of bytes requested without knowing the size
     259   of the selected representation.
     260   If the <x:ref>last-byte-pos</x:ref> value is absent, or if the value is
     261   greater than or equal to the current length of the representation data, the
     262   byte range is interpreted as the remainder of the representation (i.e., the
     263   server replaces the value of <x:ref>last-byte-pos</x:ref> with a value that
     264   is one less than the current length of the selected representation).
     265</t>
     266<t>
     267   A client can request the last N bytes of the selected representation using
     268   a <x:ref>suffix-byte-range-spec</x:ref>.
    267269</t>
    268270<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="suffix-byte-range-spec"/><iref primary="true" item="Grammar" subitem="suffix-length"/>
     
    271273</artwork></figure>
    272274<t>
    273    A suffix-byte-range-spec is used to specify the suffix of the
    274    representation data, of a length given by the suffix-length value. (That is,
    275    this form specifies the last N bytes of a representation.) If the
    276    representation is shorter than the specified suffix-length, the entire
    277    representation is used. For example (assuming a representation of
    278    length 10000):
     275   If the selected representation is shorter than the specified
     276   <x:ref>suffix-length</x:ref>, the entire representation is used.
     277   For example (assuming a representation of length 10000):
    279278  <list style="symbols">
    280279     <t>The final 500 bytes (byte offsets 9500-9999, inclusive):
     
    302301</t>
    303302<t>
    304    If a syntactically valid byte-range-set includes at least one byte-range-spec
    305    whose first-byte-pos is less than the current length of
    306    the representation, or at least one suffix-byte-range-spec with a non-zero
    307    suffix-length, then the byte-range-set is satisfiable.
    308    Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set
    309    is unsatisfiable, the server &SHOULD; send a response with a
    310    <x:ref>416 (Range Not Satisfiable)</x:ref> status code. Otherwise, the server
    311    &SHOULD; send a response with a <x:ref>206 (Partial Content)</x:ref> status code
    312    containing the satisfiable ranges of the representation.
     303   If a valid <x:ref>byte-range-set</x:ref> includes at least one
     304   <x:ref>byte-range-spec</x:ref> with a <x:ref>first-byte-pos</x:ref> that is
     305   less than the current length of the representation, or at least one
     306   <x:ref>suffix-byte-range-spec</x:ref> with a non-zero
     307   <x:ref>suffix-length</x:ref>, then the <x:ref>byte-range-set</x:ref> is
     308   satisfiable. Otherwise, the <x:ref>byte-range-set</x:ref> is unsatisfiable.
    313309</t>
    314310<t>
    315311   In the byte range syntax, <x:ref>first-byte-pos</x:ref>,
    316312   <x:ref>last-byte-pos</x:ref>, and <x:ref>suffix-length</x:ref> are
    317    expressed as decimal number of octets.  Since there is no predefined limit
    318    to the length of a payload, recipients &SHOULD; anticipate
    319    potentially large decimal numerals and prevent parsing errors due to integer
    320    conversion overflows.
     313   expressed as decimal number of octets. Since there is no predefined limit
     314   to the length of a payload, recipients ought to anticipate potentially
     315   large decimal numerals and prevent parsing errors due to integer conversion
     316   overflows.
    321317</t>
    322318</section>
     
    338334  <x:anchor-alias value="acceptable-ranges"/>
    339335<t>
    340    The "Accept-Ranges" header field allows a resource to indicate
    341    its acceptance of range requests.
     336   The "Accept-Ranges" header field allows a server to indicate that it
     337   supports range requests for the target resource.
    342338</t>
    343339<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Ranges"/><iref primary="true" item="Grammar" subitem="acceptable-ranges"/>
     
    346342</artwork></figure>
    347343<t>
    348    Origin servers that accept byte-range requests &MAY; send
     344   Origin servers that support byte-range requests &MAY; send
    349345</t>
    350346<figure><artwork type="example">
     
    357353</t>
    358354<t>
    359    Servers that do not accept any kind of range request for a
    360    resource &MAY; send
     355   Servers that do not support any kind of range request for the target
     356   resource resource &MAY; send
    361357</t>
    362358<figure><artwork type="example">
     
    378374<t>
    379375   The "Range" header field on a GET request modifies the method semantics to
    380    request transfer of only one or more sub-ranges of the selected
    381    representation data in a successful response, rather than the entire
    382    representation data.
     376   request transfer of only one or more subranges of the selected
     377   representation data, rather than the entire selected representation data.
    383378</t>
    384379<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Range"/>
     
    395390</t>
    396391<t>
    397    An origin server &MUST; ignore a <x:ref>Range</x:ref> header field that
    398    contains a range unit it does not understand. A proxy &MAY; either discard
    399    a <x:ref>Range</x:ref> header field that contains a range unit it does not
    400    understand or pass it to the next inbound server when forwarding the
    401    request.
     392   An origin server &MUST; ignore a Range header field that contains a range
     393   unit it does not understand. A proxy &MAY; either discard a Range header
     394   field that contains a range unit it does not understand or pass it to the
     395   next inbound server when forwarding the request.
    402396</t>
    403397<t>
     
    414408<t>
    415409   If all of the preconditions are true, the server supports the Range header
    416    field for the target resource, the specified range(s) are syntactically
    417    correct (as defined in <xref target="byte.ranges"/>), and at least one of
    418    the ranges has a non-empty intersection with the current selected
    419    representation extent, then the server &MAY; respond with a status code of
    420    <x:ref>206 (Partial Content)</x:ref> and a payload containing one or more
    421    partial representations that correspond to those requested, as defined in
     410   field for the target resource, and the specified range(s) are valid and
     411   satisfiable (as defined in <xref target="byte.ranges"/>), the
     412   server &SHOULD; send a <x:ref>206 (Partial Content)</x:ref> response with a
     413   payload containing one or more partial representations that correspond to
     414   the satisfiable ranges requested, as defined in
    422415   <xref target="range.response"/>.
     416</t>
     417<t>
     418   If all of the preconditions are true, the server supports the Range header
     419   field for the target resource, and the specified range(s) are invalid or
     420   unsatisfiable, the server &SHOULD; send a
     421   <x:ref>416 (Range Not Satisfiable)</x:ref> response.
    423422</t>
    424423</section>
     
    462461</t>
    463462<t>
    464    The If-Range header field &SHOULD; only be sent by clients together with
    465    a Range header field.  The If-Range header field &MUST; be ignored if it
    466    is received in a request that does not include a Range header field.
    467    The If-Range header field &MUST; be ignored by a server that does not
    468    support the sub-range operation.
     463   A client &MUST-NOT; generate an If-Range header field in a request that
     464   does not contain a <x:ref>Range</x:ref> header field.
     465   A server &MUST; ignore an If-Range header field received in a request that
     466   does not contain a <x:ref>Range</x:ref> header field.
     467   An origin server &MUST; ignore an If-Range header field received in a
     468   request for a target resource that does not support Range requests.
    469469</t>
    470470<t>
    471471   If the validator given in the If-Range header field matches the current
    472472   validator for the selected representation of the target resource, then
    473    the server &SHOULD; send the specified sub-range of the representation
    474    using a <x:ref>206 (Partial Content)</x:ref> response. If the validator
    475    does not match, then the server &SHOULD; send the entire representation
    476    using a <x:ref>200 (OK)</x:ref> response.
     473   the server &SHOULD; process the Range header field as requested.
     474   If the validator does not match, then the server &MUST; ignore the
     475   <x:ref>Range</x:ref> header field.
    477476</t>
    478477</section>
Note: See TracChangeset for help on using the changeset viewer.