Ignore:
Timestamp:
31/03/13 16:23:11 (7 years ago)
Author:
julian.reschke@…
Message:

Editorial nits (http://lists.w3.org/Archives/Public/ietf-http-wg/2013JanMar/1377.html)

File:
1 edited

Legend:

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

    r2208 r2217  
    141141<t>
    142142   This document defines HTTP/1.1 range requests, partial responses, and the
    143    multipart/byteranges media type, obsoleting those parts previously defined
    144    in <xref target="RFC2616"/>. Range requests are an &OPTIONAL; feature
     143   multipart/byteranges media type. Range requests are an &OPTIONAL; feature
    145144   of HTTP, designed so that recipients not implementing this feature (or not
    146145   supporting it for the target resource) can respond as if it is a normal
     
    275274   If the selected representation is shorter than the specified
    276275   <x:ref>suffix-length</x:ref>, the entire representation is used.
    277    For example (assuming a representation of length 10000):
     276</t>
     277<t>   
     278   Additional examples, assuming a representation of length 10000:
    278279  <list style="symbols">
    279280     <t>The final 500 bytes (byte offsets 9500-9999, inclusive):
     
    823824  <t>
    824825    &Note; Because servers are free to ignore <x:ref>Range</x:ref>, many
    825     implementations will simply respond with <x:ref>200 (OK)</x:ref> if the
     826    implementations will simply respond with the entire selected representation
     827    in a <x:ref>200 (OK)</x:ref> response if the
    826828    requested ranges are invalid or not satisfiable. That is partly because
    827829    most clients are prepared to receive a <x:ref>200 (OK)</x:ref> to
Note: See TracChangeset for help on using the changeset viewer.