Ignore:
Timestamp:
Jan 24, 2013, 7:04:10 AM (7 years ago)
Author:
fielding@…
Message:

Require that Content-Range not be generated in the HTTP header block
of a multiple part 206 response; addresses #405

Finish editorial cleanup of p5.

File:
1 edited

Legend:

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

    r2157 r2158  
    530530   If multiple parts are being transferred, the server generating the 206
    531531   response &MUST; generate a "multipart/byteranges" payload, as defined
    532    in <xref target="internet.media.type.multipart.byteranges"/>, and send a
     532   in <xref target="internet.media.type.multipart.byteranges"/>, and a
    533533   <x:ref>Content-Type</x:ref> header field containing the
    534534   multipart/byteranges media type and its required boundary parameter.
     535   To avoid confusion with single part responses, a server &MUST-NOT; generate
     536   a <x:ref>Content-Range</x:ref> header field in the HTTP header block of a
     537   multiple part response (this field will be sent in each part instead).
     538</t>
     539<t>
    535540   Within the header area of each body part in the multipart payload, the
    536541   server &MUST; generate a <x:ref>Content-Range</x:ref> header field
     
    594599<t>
    595600   When a 206 response is generated, the server &MUST; generate the following
    596    header fields, in addition to those described above, if the field would
     601   header fields, in addition to those required above, if the field would
    597602   have been sent in a <x:ref>200 (OK)</x:ref> response to the same request:
    598603   <x:ref>Date</x:ref>, <x:ref>Cache-Control</x:ref>, <x:ref>ETag</x:ref>,
     
    603608   If a 206 is generated in response to a request with an <x:ref>If-Range</x:ref>
    604609   header field, the sender &SHOULD-NOT; generate other representation header
    605    fields beyond those described above because the client is understood to
     610   fields beyond those required above, because the client is understood to
    606611   already have a prior response containing those header fields.
    607612   Otherwise, the sender &MUST; generate all of the representation header
     
    626631  <x:anchor-alias value="other-range-resp"/>
    627632<t>
    628    The "Content-Range" header field is sent with a partial representation to
    629    specify what range of the full representation is enclosed as payload.
     633   The "Content-Range" header field is sent in a single part
     634   <x:ref>206 (Partial Content)</x:ref> response to indicate the partial range
     635   of the selected representation enclosed as the message payload, sent in
     636   each part of a multipart 206 response to indicate the range enclosed within
     637   each body part, and sent in <x:ref>416 (Range Not Satisfiable)</x:ref>
     638   responses to provide information about the selected representation.
    630639</t>
    631640<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Range"/><iref primary="true" item="Grammar" subitem="byte-content-range"/><iref primary="true" item="Grammar" subitem="byte-range-resp"/><iref primary="true" item="Grammar" subitem="byte-range"/><iref primary="true" item="Grammar" subitem="unsatisfied-range"/><iref primary="true" item="Grammar" subitem="other-content-range"/><iref primary="true" item="Grammar" subitem="other-range-resp"/><iref primary="true" item="Grammar" subitem="complete-length"/>
     
    646655</artwork></figure>
    647656<t>   
    648    Range units are defined in <xref target="range.units"/>. A recipient of a
    649    <x:ref>206 (Partial Content)</x:ref> response containing a
     657   If a <x:ref>206 (Partial Content)</x:ref> response contains a
    650658   <x:ref>Content-Range</x:ref> header field with a <x:ref>range unit</x:ref>
    651    that the recipient does not understand &MUST-NOT; attempt to recombine it
    652    with a stored representation. A proxy that receives such a message
    653    &SHOULD; forward it downstream.
     659   (<xref target="range.units"/>) that the recipient does not understand, the
     660   recipient &MUST-NOT; attempt to recombine it with a stored representation.
     661   A proxy that receives such a message &SHOULD; forward it downstream.
    654662</t>
    655663<t>
    656664   For byte ranges, a sender &SHOULD; indicate the complete length of the
    657    representation from which the range has been extracted unless the complete
     665   representation from which the range has been extracted, unless the complete
    658666   length is unknown or difficult to determine. An asterisk character ("*") in
    659667   place of the complete-length indicates that the representation length was
     
    661669</t>
    662670<t>
    663    A Content-Range field value with a <x:ref>byte-range-resp</x:ref> that has
    664    a <x:ref>last-byte-pos</x:ref> value less than its
    665    <x:ref>first-byte-pos</x:ref> value, or a <x:ref>complete-length</x:ref>
    666    value less than or equal to its <x:ref>last-byte-pos</x:ref> value, is
    667    invalid. The recipient of an invalid <x:ref>Content-Range</x:ref> &MUST-NOT;
    668    attempt to recombine the received content with a stored representation.
    669 </t>
    670 <t>
    671    A server generating a <x:ref>206 (Partial Content)</x:ref> response to a
    672    byte range request &MUST; send, in each body part of a multipart response
    673    or in the header block of a single part response, a Content-Range header
    674    field containing a <x:ref>byte-range-resp</x:ref> value that reflects the
    675    corresponding range being sent. The following example would apply
    676    when the complete length of the selected representation is known by the
    677    sender to be 1234 bytes:
     671   The following example illustrates when the complete length of the selected
     672   representation is known by the sender to be 1234 bytes:
    678673</t>
    679674<figure><artwork type="example">
     
    681676</artwork></figure>
    682677<t>
    683    or this second example would apply when the complete length is unknown:
     678   and this second example illustrates when the complete length is unknown:
    684679</t>
    685680<figure><artwork type="example">
    686681  Content-Range: bytes 42-1233/*
    687682</artwork></figure>
     683<t>
     684   A Content-Range field value is invalid if it contains a
     685   <x:ref>byte-range-resp</x:ref> that has a <x:ref>last-byte-pos</x:ref>
     686   value less than its <x:ref>first-byte-pos</x:ref> value, or a
     687   <x:ref>complete-length</x:ref> value less than or equal to its
     688   <x:ref>last-byte-pos</x:ref> value. The recipient of an invalid
     689   <x:ref>Content-Range</x:ref> &MUST-NOT; attempt to recombine the received
     690   content with a stored representation.
     691</t>
    688692<t>
    689693   A server generating a <x:ref>416 (Range Not Satisfiable)</x:ref> response
     
    696700<t>
    697701   The complete-length in a 416 response indicates the current length of the
    698    selected representation, which will be known by the server generating the
    699    response because that is how it determined the range to be unsatisfiable.
     702   selected representation.
    700703</t>
    701704<t>
     
    707710</t>
    708711<t>
    709    More examples of Content-Range values, assuming that the representation
    710    contains a total of 1234 bytes:
     712   The following are examples of Content-Range values in which the
     713   selected representation contains a total of 1234 bytes:
    711714   <list style="symbols">
    712715      <t>
     
    751754</t>
    752755<t>
    753    When a client receives an incomplete <x:ref>200 (OK)</x:ref> response or a
    754    <x:ref>206 (Partial Content)</x:ref> response, and already has one or more
    755    partial responses for the same method and effective request URI that have
    756    the same strong validator as present in the new response,
    757    the recipient &MAY; combine some or all of those responses into a set of
    758    continuous ranges. A client &MUST-NOT; combine responses that differ in the
    759    strong validator or that do not have a strong validator.
    760 </t>
    761 <t>
    762    If the new response is an incomplete <x:ref>200 (OK)</x:ref> response, then
    763    the header fields of that new response are used for any combined response
    764    and replace those of the matching stored responses.
    765 </t>
    766 <t>
    767    If the new response is a <x:ref>206 (Partial Content)</x:ref> response and
    768    at least one of the matching stored responses is a <x:ref>200 (OK)</x:ref>,
    769    then the combined response header fields consist of the most recent 200
    770    response's header fields. If all of the matching stored responses are 206
    771    responses, then the stored response with the most recent header fields is
    772    used as the source of header fields for the combined response, except that
    773    the client &MUST; use other header fields provided in the new response,
    774    aside from <x:ref>Content-Range</x:ref>, to replace all instances of the
    775    corresponding header fields in the stored response.
     756   A client that has received multiple partial responses to GET requests on a
     757   target resource &MAY; combine those responses into a larger continuous
     758   range if they share the same strong validator.
     759</t>
     760<t>
     761   If the most recent response is an incomplete <x:ref>200 (OK)</x:ref>
     762   response, then the header fields of that response are used for any
     763   combined response and replace those of the matching stored responses.
     764</t>
     765<t>
     766   If the most recent response is a <x:ref>206 (Partial Content)</x:ref>
     767   response and at least one of the matching stored responses is a
     768   <x:ref>200 (OK)</x:ref>, then the combined response header fields consist
     769   of the most recent 200 response's header fields. If all of the matching
     770   stored responses are 206 responses, then the stored response with the most
     771   recent header fields is used as the source of header fields for the
     772   combined response, except that the client &MUST; use other header fields
     773   provided in the new response, aside from <x:ref>Content-Range</x:ref>, to
     774   replace all instances of the corresponding header fields in the stored
     775   response.
    776776</t>
    777777<t>
     
    798798  <x:anchor-alias value="416 (Range Not Satisfiable)"/>
    799799<t>
    800    The <x:dfn>416 (Range Not Satisfiable)</x:dfn> status code
    801    indicates that none of the ranges-specifier values in the request's
    802    <x:ref>Range</x:ref> header field (<xref target="header.range"/>)
    803    overlap the current
    804    extent of the selected resource and the request did not include an
    805    <x:ref>If-Range</x:ref> header field (<xref target="header.if-range"/>).
    806    (For byte-ranges, this means that the first-byte-pos of all of the
    807    byte-range-spec values were greater than the current length of the selected
    808    representation.)
    809 </t>
    810 <t>
    811    When this status code is sent in response to a byte-range request, the
     800   The <x:dfn>416 (Range Not Satisfiable)</x:dfn> status code indicates that
     801   none of the ranges in the request's <x:ref>Range</x:ref> header field
     802   (<xref target="header.range"/>) overlap the current extent of the selected
     803   resource or that the set of ranges requested has been rejected due to
     804   invalid ranges or an excessive request of small or overlapping ranges.
     805</t>
     806<t>
     807   For byte ranges, failing to overlap the current extent means that the
     808   <x:ref>first-byte-pos</x:ref> of all of the <x:ref>byte-range-spec</x:ref>
     809   values were greater than the current length of the selected representation.
     810   When this status code is generated in response to a byte range request, the
    812811   sender &SHOULD; generate a <x:ref>Content-Range</x:ref> header field
    813812   specifying the current length of the selected representation
    814    (see <xref target="header.content-range"/>).
     813   (<xref target="header.content-range"/>).
    815814</t>
    816815<figure>
     
    820819Date: Mon, 20 Jan 2012 15:41:54 GMT
    821820Content-Range: bytes */47022
    822 Content-Type: image/gif
    823821</artwork></figure>
    824822<x:note>
    825823  <t>
    826     &Note; Clients cannot depend on servers to send a <x:ref>416 (Range Not
    827     Satisfiable)</x:ref> response instead of a <x:ref>200 (OK)</x:ref>
    828     response for an unsatisfiable <x:ref>Range</x:ref> header field, since not
    829     all servers implement this header field.
     824    &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    requested ranges are invalid or not satisfiable. That is partly because
     827    most clients are prepared to receive a <x:ref>200 (OK)</x:ref> to
     828    complete the task (albeit less efficiently) and partly because clients
     829    might not stop making an invalid partial request until they have received
     830    a complete representation. Thus, clients cannot depend on receiving a
     831    <x:ref>416 (Range Not Satisfiable)</x:ref> response even when it is most
     832    appropriate.
    830833  </t>
    831834</x:note>
Note: See TracChangeset for help on using the changeset viewer.