Ignore:
Timestamp:
20/01/13 14:51:00 (10 years ago)
Author:
fielding@…
Message:

(editorial) move header fields to where they are used; no text changes

File:
1 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p5-range.xml

    r2141 r2142  
    328328</t>
    329329</section>
     330<section title="Accept-Ranges" anchor="header.accept-ranges">
     331  <iref primary="true" item="Accept-Ranges header field" x:for-anchor=""/>
     332  <x:anchor-alias value="Accept-Ranges"/>
     333  <x:anchor-alias value="acceptable-ranges"/>
     334<t>
     335   The "Accept-Ranges" header field allows a resource to indicate
     336   its acceptance of range requests.
     337</t>
     338<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Ranges"/><iref primary="true" item="Grammar" subitem="acceptable-ranges"/>
     339  <x:ref>Accept-Ranges</x:ref>     = <x:ref>acceptable-ranges</x:ref>
     340  <x:ref>acceptable-ranges</x:ref> = 1#<x:ref>range-unit</x:ref> / "none"
     341</artwork></figure>
     342<t>
     343   Origin servers that accept byte-range requests &MAY; send
     344</t>
     345<figure><artwork type="example">
     346  Accept-Ranges: bytes
     347</artwork></figure>
     348<t>
     349   but are not required to do so. Clients &MAY; generate range
     350   requests without having received this header field for the resource
     351   involved. Range units are defined in <xref target="range.units"/>.
     352</t>
     353<t>
     354   Servers that do not accept any kind of range request for a
     355   resource &MAY; send
     356</t>
     357<figure><artwork type="example">
     358  Accept-Ranges: none
     359</artwork></figure>
     360<t>
     361   to advise the client not to attempt a range request.
     362</t>
     363</section>
    330364</section>
    331365
    332366
    333367<section title="Range Requests" anchor="range.requests">
     368<section title="Range" anchor="header.range">
     369  <iref primary="true" item="Range header field" x:for-anchor=""/>
     370  <x:anchor-alias value="Range"/>
     371  <x:anchor-alias value="other-ranges-specifier"/>
     372  <x:anchor-alias value="other-range-set"/>
     373<t>
     374   The "Range" header field on a GET request modifies the method semantics to
     375   request transfer of only one or more sub-ranges of the selected
     376   representation data in a successful response, rather than the entire
     377   representation data.
     378</t>
     379<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Range"/>
     380  <x:ref>Range</x:ref> = <x:ref>byte-ranges-specifier</x:ref> / <x:ref>other-ranges-specifier</x:ref>
     381  <x:ref>other-ranges-specifier</x:ref> = <x:ref>other-range-unit</x:ref> "=" <x:ref>other-range-set</x:ref>
     382  <x:ref>other-range-set</x:ref> = 1*<x:ref>CHAR</x:ref>
     383</artwork></figure>
     384<t>
     385   A server &MAY; ignore the Range header field. However, origin servers and
     386   intermediate caches ought to support byte ranges when possible, since Range
     387   supports efficient recovery from partially failed transfers and partial
     388   retrieval of large representations. A server &MUST; ignore a Range header
     389   field received with a request method other than GET.
     390</t>
     391<t>
     392   An origin server &MUST; ignore a <x:ref>Range</x:ref> header field that
     393   contains a range unit it does not understand. A proxy &MAY; either discard
     394   a <x:ref>Range</x:ref> header field that contains a range unit it does not
     395   understand or pass it to the next inbound server when forwarding the
     396   request.
     397</t>
     398<t>
     399   The Range header field is evaluated after evaluating the preconditions of
     400   <xref target="Part4"/> and only if the result of their evaluation is
     401   leading toward a <x:ref>200 (OK)</x:ref> response. In other words, Range
     402   is ignored when a conditional GET would result in a
     403   <x:ref>304 (Not Modified)</x:ref> response.
     404</t>
     405<t>
     406   The If-Range header field (<xref target="header.if-range"/>) can be used as
     407   a precondition to applying the Range header field.
     408</t>
     409<t>
     410   If all of the preconditions are true, the server supports the Range header
     411   field for the target resource, the specified range(s) are syntactically
     412   correct (as defined in <xref target="byte.ranges"/>), and at least one of
     413   the ranges has a non-empty intersection with the current selected
     414   representation extent, then the server &MAY; respond with a status code of
     415   <x:ref>206 (Partial Content)</x:ref> and a payload containing one or more
     416   partial representations that correspond to those requested, as defined in
     417   <xref target="range.response"/>.
     418</t>
     419</section>
     420
     421<section title="If-Range" anchor="header.if-range">
     422  <iref primary="true" item="If-Range header field" x:for-anchor=""/>
     423  <x:anchor-alias value="If-Range"/>
     424<t>
     425   If a client has a partial copy of a representation and wishes
     426   to have an up-to-date copy of the entire representation, it could use the
     427   <x:ref>Range</x:ref> header field with a conditional GET (using
     428   either or both of <x:ref>If-Unmodified-Since</x:ref> and
     429   <x:ref>If-Match</x:ref>.) However, if the condition fails because the
     430   representation has been modified, the client would then have to make a
     431   second request to obtain the entire current representation.
     432</t>
     433<t>
     434   The "If-Range" header field allows a client to "short-circuit" the second
     435   request. Informally, its meaning is: if the representation is unchanged,
     436   send me the part(s) that I am requesting in Range; otherwise, send me the
     437   entire representation.
     438</t>
     439<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Range"/>
     440  <x:ref>If-Range</x:ref> = <x:ref>entity-tag</x:ref> / <x:ref>HTTP-date</x:ref>
     441</artwork></figure>
     442<t>
     443   Clients &MUST-NOT; use an entity-tag marked as weak in an If-Range
     444   field value and &MUST-NOT; use a <x:ref>Last-Modified</x:ref> date in an
     445   If-Range field value unless it has no entity-tag for the representation and
     446   the Last-Modified date it does have for the representation is strong
     447   in the sense defined by &lastmod-comparison;.
     448</t>
     449<t>
     450   A server that evaluates a conditional range request that is applicable
     451   to one of its representations &MUST; evaluate the condition as false if
     452   the entity-tag used as a validator is marked as weak or, when an HTTP-date
     453   is used as the validator, if the date value is not strong in the sense
     454   defined by &lastmod-comparison;. (A server can distinguish between a
     455   valid HTTP-date and any form of entity-tag by examining the first
     456   two characters.)
     457</t>
     458<t>
     459   The If-Range header field &SHOULD; only be sent by clients together with
     460   a Range header field.  The If-Range header field &MUST; be ignored if it
     461   is received in a request that does not include a Range header field.
     462   The If-Range header field &MUST; be ignored by a server that does not
     463   support the sub-range operation.
     464</t>
     465<t>
     466   If the validator given in the If-Range header field matches the current
     467   validator for the selected representation of the target resource, then
     468   the server &SHOULD; send the specified sub-range of the representation
     469   using a <x:ref>206 (Partial Content)</x:ref> response. If the validator
     470   does not match, then the server &SHOULD; send the entire representation
     471   using a <x:ref>200 (OK)</x:ref> response.
     472</t>
     473</section>
    334474</section>
    335475
    … …  
    466606   server &SHOULD; send them in the order that they appeared in the
    467607   request.
     608</t>
     609</section>
     610
     611<section title="Content-Range" anchor="header.content-range">
     612  <iref primary="true" item="Content-Range header field" x:for-anchor=""/>
     613  <x:anchor-alias value="Content-Range"/>
     614  <x:anchor-alias value="byte-content-range"/>
     615  <x:anchor-alias value="byte-range-resp"/>
     616  <x:anchor-alias value="byte-range"/>
     617  <x:anchor-alias value="unsatisfied-range"/>
     618  <x:anchor-alias value="complete-length"/>
     619  <x:anchor-alias value="other-content-range"/>
     620  <x:anchor-alias value="other-range-resp"/>
     621<t>
     622   The "Content-Range" header field is sent with a partial representation to
     623   specify where in the full representation the payload body is intended to be
     624   applied.
     625</t>
     626<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"/>
     627  <x:ref>Content-Range</x:ref>       = <x:ref>byte-content-range</x:ref>
     628                      / <x:ref>other-content-range</x:ref>
     629                         
     630  <x:ref>byte-content-range</x:ref>  = <x:ref>bytes-unit</x:ref> <x:ref>SP</x:ref>
     631                        ( <x:ref>byte-range-resp</x:ref> / <x:ref>unsatisfied-range</x:ref> )
     632
     633  <x:ref>byte-range-resp</x:ref>     = <x:ref>byte-range</x:ref> "/" ( <x:ref>complete-length</x:ref> / "*" )
     634  <x:ref>byte-range</x:ref>          = <x:ref>first-byte-pos</x:ref> "-" <x:ref>last-byte-pos</x:ref>
     635  <x:ref>unsatisfied-range</x:ref>   = "*/" <x:ref>complete-length</x:ref>
     636                         
     637  <x:ref>complete-length</x:ref>     = 1*<x:ref>DIGIT</x:ref>
     638 
     639  <x:ref>other-content-range</x:ref> = <x:ref>other-range-unit</x:ref> <x:ref>SP</x:ref> <x:ref>other-range-resp</x:ref>
     640  <x:ref>other-range-resp</x:ref>    = *<x:ref>CHAR</x:ref>
     641</artwork></figure>
     642<t>   
     643   Range units are defined in <xref target="range.units"/>. A recipient of a
     644   <x:ref>206 (Partial Content)</x:ref> response containing a
     645   <x:ref>Content-Range</x:ref> header field with a <x:ref>range unit</x:ref>
     646   that the recipient does not understand &MUST-NOT; attempt to recombine it
     647   with a stored representation. A proxy that receives such a message
     648   &SHOULD; forward it downstream.
     649</t>
     650<t>
     651   For byte ranges, a sender &SHOULD; indicate the complete length of the
     652   representation from which the range has been extracted unless the complete
     653   length is unknown or difficult to determine. An asterisk character ("*") in
     654   place of the complete-length indicates that the representation length was
     655   unknown when the header field was generated.
     656</t>
     657<t>
     658   A Content-Range field value with a <x:ref>byte-range-resp</x:ref> that has
     659   a <x:ref>last-byte-pos</x:ref> value less than its
     660   <x:ref>first-byte-pos</x:ref> value, or a <x:ref>complete-length</x:ref>
     661   value less than or equal to its <x:ref>last-byte-pos</x:ref> value, is
     662   invalid. The recipient of an invalid <x:ref>Content-Range</x:ref> &MUST-NOT;
     663   attempt to recombine the received content with a stored representation.
     664</t>
     665<t>
     666   A server generating a <x:ref>206 (Partial Content)</x:ref> response to a
     667   byte range request &MUST; send, in each body-part of a multipart response
     668   or in the header block of a single part response, a Content-Range header
     669   field containing a <x:ref>byte-range-resp</x:ref> value that reflects the
     670   corresponding range being sent. The following example would apply
     671   when the complete length of the selected representation is known by the
     672   sender to be 1234 bytes:
     673</t>
     674<figure><artwork type="example">
     675  Content-Range: bytes 42-1233/1234
     676</artwork></figure>
     677<t>
     678   or this second example would apply when the complete length is unknown:
     679</t>
     680<figure><artwork type="example">
     681  Content-Range: bytes 42-1233/*
     682</artwork></figure>
     683<t>
     684   A server generating a <x:ref>416 (Range Not Satisfiable)</x:ref> response
     685   to a byte range request &SHOULD; send a Content-Range header field with an
     686   <x:ref>unsatisfied-range</x:ref> value, as in the following example:
     687</t>
     688<figure><artwork type="example">
     689  Content-Range: bytes */1234
     690</artwork></figure>
     691<t>
     692   The complete-length in a 416 response indicates the current length of the
     693   selected representation, which will be known by the server generating the
     694   response because that is how it determined the range to be unsatisfiable.
     695</t>
     696<t>
     697   The "Content-Range" header field has no meaning for status codes that do
     698   not explicitly describe its semantic. For this specification, only the
     699   <x:ref>206 (Partial Content)</x:ref> and
     700   <x:ref>416 (Range Not Satisfiable)</x:ref> status codes describe a meaning
     701   for Content-Range.
     702</t>
     703<t>
     704   More examples of Content-Range values, assuming that the representation
     705   contains a total of 1234 bytes:
     706   <list style="symbols">
     707      <t>
     708        The first 500 bytes:
     709<figure><artwork type="example" x:indent-with="   ">
     710  Content-Range: bytes 0-499/1234
     711</artwork></figure>
     712      </t>   
     713      <t>
     714        The second 500 bytes:
     715<figure><artwork type="example" x:indent-with="   ">
     716  Content-Range: bytes 500-999/1234
     717</artwork></figure>
     718      </t>   
     719      <t>
     720        All except for the first 500 bytes:
     721<figure><artwork type="example" x:indent-with="   ">
     722  Content-Range: bytes 500-1233/1234
     723</artwork></figure>
     724      </t>   
     725      <t>
     726        The last 500 bytes:
     727<figure><artwork type="example" x:indent-with="   ">
     728  Content-Range: bytes 734-1233/1234
     729</artwork></figure>
     730      </t>   
     731   </list>
    468732</t>
    469733</section>
    … …  
    522786   continuous range that is indicated by a <x:ref>Content-Range</x:ref> header
    523787   field.
    524 </t>
    525 </section>
    526 </section>
    527 
    528 <section title="Header Field Definitions" anchor="header.field.definitions">
    529 <t>
    530    This section defines the syntax and semantics of HTTP/1.1 header fields
    531    related to range requests and partial responses.
    532 </t>
    533 
    534 <section title="Accept-Ranges" anchor="header.accept-ranges">
    535   <iref primary="true" item="Accept-Ranges header field" x:for-anchor=""/>
    536   <x:anchor-alias value="Accept-Ranges"/>
    537   <x:anchor-alias value="acceptable-ranges"/>
    538 <t>
    539    The "Accept-Ranges" header field allows a resource to indicate
    540    its acceptance of range requests.
    541 </t>
    542 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Ranges"/><iref primary="true" item="Grammar" subitem="acceptable-ranges"/>
    543   <x:ref>Accept-Ranges</x:ref>     = <x:ref>acceptable-ranges</x:ref>
    544   <x:ref>acceptable-ranges</x:ref> = 1#<x:ref>range-unit</x:ref> / "none"
    545 </artwork></figure>
    546 <t>
    547    Origin servers that accept byte-range requests &MAY; send
    548 </t>
    549 <figure><artwork type="example">
    550   Accept-Ranges: bytes
    551 </artwork></figure>
    552 <t>
    553    but are not required to do so. Clients &MAY; generate range
    554    requests without having received this header field for the resource
    555    involved. Range units are defined in <xref target="range.units"/>.
    556 </t>
    557 <t>
    558    Servers that do not accept any kind of range request for a
    559    resource &MAY; send
    560 </t>
    561 <figure><artwork type="example">
    562   Accept-Ranges: none
    563 </artwork></figure>
    564 <t>
    565    to advise the client not to attempt a range request.
    566 </t>
    567 </section>
    568 
    569 <section title="Content-Range" anchor="header.content-range">
    570   <iref primary="true" item="Content-Range header field" x:for-anchor=""/>
    571   <x:anchor-alias value="Content-Range"/>
    572   <x:anchor-alias value="byte-content-range"/>
    573   <x:anchor-alias value="byte-range-resp"/>
    574   <x:anchor-alias value="byte-range"/>
    575   <x:anchor-alias value="unsatisfied-range"/>
    576   <x:anchor-alias value="complete-length"/>
    577   <x:anchor-alias value="other-content-range"/>
    578   <x:anchor-alias value="other-range-resp"/>
    579 <t>
    580    The "Content-Range" header field is sent with a partial representation to
    581    specify where in the full representation the payload body is intended to be
    582    applied.
    583 </t>
    584 <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"/>
    585   <x:ref>Content-Range</x:ref>       = <x:ref>byte-content-range</x:ref>
    586                       / <x:ref>other-content-range</x:ref>
    587                          
    588   <x:ref>byte-content-range</x:ref>  = <x:ref>bytes-unit</x:ref> <x:ref>SP</x:ref>
    589                         ( <x:ref>byte-range-resp</x:ref> / <x:ref>unsatisfied-range</x:ref> )
    590 
    591   <x:ref>byte-range-resp</x:ref>     = <x:ref>byte-range</x:ref> "/" ( <x:ref>complete-length</x:ref> / "*" )
    592   <x:ref>byte-range</x:ref>          = <x:ref>first-byte-pos</x:ref> "-" <x:ref>last-byte-pos</x:ref>
    593   <x:ref>unsatisfied-range</x:ref>   = "*/" <x:ref>complete-length</x:ref>
    594                          
    595   <x:ref>complete-length</x:ref>     = 1*<x:ref>DIGIT</x:ref>
    596  
    597   <x:ref>other-content-range</x:ref> = <x:ref>other-range-unit</x:ref> <x:ref>SP</x:ref> <x:ref>other-range-resp</x:ref>
    598   <x:ref>other-range-resp</x:ref>    = *<x:ref>CHAR</x:ref>
    599 </artwork></figure>
    600 <t>   
    601    Range units are defined in <xref target="range.units"/>. A recipient of a
    602    <x:ref>206 (Partial Content)</x:ref> response containing a
    603    <x:ref>Content-Range</x:ref> header field with a <x:ref>range unit</x:ref>
    604    that the recipient does not understand &MUST-NOT; attempt to recombine it
    605    with a stored representation. A proxy that receives such a message
    606    &SHOULD; forward it downstream.
    607 </t>
    608 <t>
    609    For byte ranges, a sender &SHOULD; indicate the complete length of the
    610    representation from which the range has been extracted unless the complete
    611    length is unknown or difficult to determine. An asterisk character ("*") in
    612    place of the complete-length indicates that the representation length was
    613    unknown when the header field was generated.
    614 </t>
    615 <t>
    616    A Content-Range field value with a <x:ref>byte-range-resp</x:ref> that has
    617    a <x:ref>last-byte-pos</x:ref> value less than its
    618    <x:ref>first-byte-pos</x:ref> value, or a <x:ref>complete-length</x:ref>
    619    value less than or equal to its <x:ref>last-byte-pos</x:ref> value, is
    620    invalid. The recipient of an invalid <x:ref>Content-Range</x:ref> &MUST-NOT;
    621    attempt to recombine the received content with a stored representation.
    622 </t>
    623 <t>
    624    A server generating a <x:ref>206 (Partial Content)</x:ref> response to a
    625    byte range request &MUST; send, in each body-part of a multipart response
    626    or in the header block of a single part response, a Content-Range header
    627    field containing a <x:ref>byte-range-resp</x:ref> value that reflects the
    628    corresponding range being sent. The following example would apply
    629    when the complete length of the selected representation is known by the
    630    sender to be 1234 bytes:
    631 </t>
    632 <figure><artwork type="example">
    633   Content-Range: bytes 42-1233/1234
    634 </artwork></figure>
    635 <t>
    636    or this second example would apply when the complete length is unknown:
    637 </t>
    638 <figure><artwork type="example">
    639   Content-Range: bytes 42-1233/*
    640 </artwork></figure>
    641 <t>
    642    A server generating a <x:ref>416 (Range Not Satisfiable)</x:ref> response
    643    to a byte range request &SHOULD; send a Content-Range header field with an
    644    <x:ref>unsatisfied-range</x:ref> value, as in the following example:
    645 </t>
    646 <figure><artwork type="example">
    647   Content-Range: bytes */1234
    648 </artwork></figure>
    649 <t>
    650    The complete-length in a 416 response indicates the current length of the
    651    selected representation, which will be known by the server generating the
    652    response because that is how it determined the range to be unsatisfiable.
    653 </t>
    654 <t>
    655    The "Content-Range" header field has no meaning for status codes that do
    656    not explicitly describe its semantic. For this specification, only the
    657    <x:ref>206 (Partial Content)</x:ref> and
    658    <x:ref>416 (Range Not Satisfiable)</x:ref> status codes describe a meaning
    659    for Content-Range.
    660 </t>
    661 <t>
    662    More examples of Content-Range values, assuming that the representation
    663    contains a total of 1234 bytes:
    664    <list style="symbols">
    665       <t>
    666         The first 500 bytes:
    667 <figure><artwork type="example" x:indent-with="   ">
    668   Content-Range: bytes 0-499/1234
    669 </artwork></figure>
    670       </t>   
    671       <t>
    672         The second 500 bytes:
    673 <figure><artwork type="example" x:indent-with="   ">
    674   Content-Range: bytes 500-999/1234
    675 </artwork></figure>
    676       </t>   
    677       <t>
    678         All except for the first 500 bytes:
    679 <figure><artwork type="example" x:indent-with="   ">
    680   Content-Range: bytes 500-1233/1234
    681 </artwork></figure>
    682       </t>   
    683       <t>
    684         The last 500 bytes:
    685 <figure><artwork type="example" x:indent-with="   ">
    686   Content-Range: bytes 734-1233/1234
    687 </artwork></figure>
    688       </t>   
    689    </list>
    690 </t>
    691 </section>
    692 
    693 <section title="If-Range" anchor="header.if-range">
    694   <iref primary="true" item="If-Range header field" x:for-anchor=""/>
    695   <x:anchor-alias value="If-Range"/>
    696 <t>
    697    If a client has a partial copy of a representation and wishes
    698    to have an up-to-date copy of the entire representation, it could use the
    699    <x:ref>Range</x:ref> header field with a conditional GET (using
    700    either or both of <x:ref>If-Unmodified-Since</x:ref> and
    701    <x:ref>If-Match</x:ref>.) However, if the condition fails because the
    702    representation has been modified, the client would then have to make a
    703    second request to obtain the entire current representation.
    704 </t>
    705 <t>
    706    The "If-Range" header field allows a client to "short-circuit" the second
    707    request. Informally, its meaning is: if the representation is unchanged,
    708    send me the part(s) that I am requesting in Range; otherwise, send me the
    709    entire representation.
    710 </t>
    711 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Range"/>
    712   <x:ref>If-Range</x:ref> = <x:ref>entity-tag</x:ref> / <x:ref>HTTP-date</x:ref>
    713 </artwork></figure>
    714 <t>
    715    Clients &MUST-NOT; use an entity-tag marked as weak in an If-Range
    716    field value and &MUST-NOT; use a <x:ref>Last-Modified</x:ref> date in an
    717    If-Range field value unless it has no entity-tag for the representation and
    718    the Last-Modified date it does have for the representation is strong
    719    in the sense defined by &lastmod-comparison;.
    720 </t>
    721 <t>
    722    A server that evaluates a conditional range request that is applicable
    723    to one of its representations &MUST; evaluate the condition as false if
    724    the entity-tag used as a validator is marked as weak or, when an HTTP-date
    725    is used as the validator, if the date value is not strong in the sense
    726    defined by &lastmod-comparison;. (A server can distinguish between a
    727    valid HTTP-date and any form of entity-tag by examining the first
    728    two characters.)
    729 </t>
    730 <t>
    731    The If-Range header field &SHOULD; only be sent by clients together with
    732    a Range header field.  The If-Range header field &MUST; be ignored if it
    733    is received in a request that does not include a Range header field.
    734    The If-Range header field &MUST; be ignored by a server that does not
    735    support the sub-range operation.
    736 </t>
    737 <t>
    738    If the validator given in the If-Range header field matches the current
    739    validator for the selected representation of the target resource, then
    740    the server &SHOULD; send the specified sub-range of the representation
    741    using a <x:ref>206 (Partial Content)</x:ref> response. If the validator
    742    does not match, then the server &SHOULD; send the entire representation
    743    using a <x:ref>200 (OK)</x:ref> response.
    744 </t>
    745 </section>
    746 
    747 <section title="Range" anchor="header.range">
    748   <iref primary="true" item="Range header field" x:for-anchor=""/>
    749   <x:anchor-alias value="Range"/>
    750   <x:anchor-alias value="other-ranges-specifier"/>
    751   <x:anchor-alias value="other-range-set"/>
    752 <t>
    753    The "Range" header field on a GET request modifies the method semantics to
    754    request transfer of only one or more sub-ranges of the selected
    755    representation data in a successful response, rather than the entire
    756    representation data.
    757 </t>
    758 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Range"/>
    759   <x:ref>Range</x:ref> = <x:ref>byte-ranges-specifier</x:ref> / <x:ref>other-ranges-specifier</x:ref>
    760   <x:ref>other-ranges-specifier</x:ref> = <x:ref>other-range-unit</x:ref> "=" <x:ref>other-range-set</x:ref>
    761   <x:ref>other-range-set</x:ref> = 1*<x:ref>CHAR</x:ref>
    762 </artwork></figure>
    763 <t>
    764    A server &MAY; ignore the Range header field. However, origin servers and
    765    intermediate caches ought to support byte ranges when possible, since Range
    766    supports efficient recovery from partially failed transfers and partial
    767    retrieval of large representations. A server &MUST; ignore a Range header
    768    field received with a request method other than GET.
    769 </t>
    770 <t>
    771    An origin server &MUST; ignore a <x:ref>Range</x:ref> header field that
    772    contains a range unit it does not understand. A proxy &MAY; either discard
    773    a <x:ref>Range</x:ref> header field that contains a range unit it does not
    774    understand or pass it to the next inbound server when forwarding the
    775    request.
    776 </t>
    777 <t>
    778    The Range header field is evaluated after evaluating the preconditions of
    779    <xref target="Part4"/> and only if the result of their evaluation is
    780    leading toward a <x:ref>200 (OK)</x:ref> response. In other words, Range
    781    is ignored when a conditional GET would result in a
    782    <x:ref>304 (Not Modified)</x:ref> response.
    783 </t>
    784 <t>
    785    The If-Range header field (<xref target="header.if-range"/>) can be used as
    786    a precondition to applying the Range header field.
    787 </t>
    788 <t>
    789    If all of the preconditions are true, the server supports the Range header
    790    field for the target resource, the specified range(s) are syntactically
    791    correct (as defined in <xref target="byte.ranges"/>), and at least one of
    792    the ranges has a non-empty intersection with the current selected
    793    representation extent, then the server &MAY; respond with a status code of
    794    <x:ref>206 (Partial Content)</x:ref> and a payload containing one or more
    795    partial representations that correspond to those requested, as defined in
    796    <xref target="range.response"/>.
    797788</t>
    798789</section>
Note: See TracChangeset for help on using the changeset viewer.