Ignore:
Timestamp:
22/07/10 09:10:39 (12 years ago)
Author:
fielding@…
Message:

regenerate html

Location:
draft-ietf-httpbis/latest
Files:
6 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p1-messaging.html

    r865 r868  
    19781978      <p id="rfc.section.9.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to message framing and transport protocols.</p>
    19791979      <p id="rfc.section.9.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who
    1980          receives the entity.
     1980         receives the message.
    19811981      </p>
    19821982      <div id="rfc.iref.c.11"></div>
    … …  
    21722172      </p>
    21732173      <div id="rfc.figure.u.71"></div><pre class="text">  Transfer-Encoding: chunked
    2174 </pre><p id="rfc.section.9.7.p.5">If multiple encodings have been applied to an entity, the transfer-codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other entity-header fields not defined by this specification.
     2174</pre><p id="rfc.section.9.7.p.5">If multiple encodings have been applied to a representation, the transfer-codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other entity-header fields not defined by this specification.
    21752175      </p>
    21762176      <p id="rfc.section.9.7.p.6">Many older HTTP/1.0 applications do not understand the Transfer-Encoding header.</p>

  • draft-ietf-httpbis/latest/p2-semantics.html

    r865 r868  
    380380      <link rel="Chapter" title="4 Status Code and Reason Phrase" href="#rfc.section.4">
    381381      <link rel="Chapter" title="5 Response Header Fields" href="#rfc.section.5">
    382       <link rel="Chapter" title="6 Entity" href="#rfc.section.6">
     382      <link rel="Chapter" title="6 Representation" href="#rfc.section.6">
    383383      <link rel="Chapter" title="7 Method Definitions" href="#rfc.section.7">
    384384      <link rel="Chapter" title="8 Status Code Definitions" href="#rfc.section.8">
    … …  
    551551         </li>
    552552         <li class="tocline0">5.&nbsp;&nbsp;&nbsp;<a href="#response.header.fields">Response Header Fields</a></li>
    553          <li class="tocline0">6.&nbsp;&nbsp;&nbsp;<a href="#entity">Entity</a><ul class="toc">
     553         <li class="tocline0">6.&nbsp;&nbsp;&nbsp;<a href="#entity">Representation</a><ul class="toc">
    554554               <li class="tocline1">6.1&nbsp;&nbsp;&nbsp;<a href="#identifying.response.associated.with.representation">Identifying the Resource Associated with a Representation</a></li>
    555555            </ul>
    … …  
    875875         though such understanding is obviously desirable. However, applications <em class="bcp14">MUST</em> understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent
    876876         to the x00 status code of that class, with the exception that an unrecognized response <em class="bcp14">MUST NOT</em> be cached. For example, if an unrecognized status code of 431 is received by the client, it can safely assume that there was
    877          something wrong with its request and treat the response as if it had received a 400 status code. In such cases, user agents <em class="bcp14">SHOULD</em> present to the user the entity returned with the response, since that entity is likely to include human-readable information
    878          which will explain the unusual status.
     877         something wrong with its request and treat the response as if it had received a 400 status code. In such cases, user agents <em class="bcp14">SHOULD</em> present to the user the representation enclosed with the response, since that representation is likely to include human-readable
     878         information which will explain the unusual status.
    879879      </p>
    880880      <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="status.code.registry" href="#status.code.registry">Status Code Registry</a></h2>
    … …  
    903903         fields. Unrecognized header fields are treated as entity-header fields.
    904904      </p>
    905       <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="entity" href="#entity">Entity</a></h1>
    906       <p id="rfc.section.6.p.1">Request and Response messages <em class="bcp14">MAY</em> transfer an entity if not otherwise restricted by the request method or response status code. An entity consists of entity-header
    907          fields and an entity-body, although some responses will only include the entity-headers. HTTP entity-body and entity-header
    908          fields are defined in <a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
    909       </p>
    910       <p id="rfc.section.6.p.2">An entity-body is only present in a message when a message-body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The entity-body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied to ensure
    911          safe and proper transfer of the message.
     905      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="entity" href="#entity">Representation</a></h1>
     906      <p id="rfc.section.6.p.1">Request and Response messages <em class="bcp14">MAY</em> transfer a representation if not otherwise restricted by the request method or response status code. A representation consists
     907         of metadata (representation header fields) and data (representation body). When a complete or partial representation is enclosed
     908         in an HTTP message, it is referred to as the payload of the message. HTTP representations are defined in <a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
     909      </p>
     910      <p id="rfc.section.6.p.2">A representation body is only present in a message when a message-body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The representation body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied
     911         to ensure safe and proper transfer of the message.
    912912      </p>
    913913      <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="identifying.response.associated.with.representation" href="#identifying.response.associated.with.representation">Identifying the Resource Associated with a Representation</a></h2>
    … …  
    994994         by the Effective Request URI.
    995995      </p>
    996       <p id="rfc.section.7.3.p.2">If the Effective Request URI identifies a data-producing process, it is the produced data which shall be returned as the entity
     996      <p id="rfc.section.7.3.p.2">If the Effective Request URI identifies a data-producing process, it is the produced data which shall be returned as the representation
    997997         in the response and not the source text of the process, unless that text happens to be the output of the process.
    998998      </p>
    999999      <p id="rfc.section.7.3.p.3">The semantics of the GET method change to a "conditional GET" if the request message includes an If-Modified-Since, If-Unmodified-Since,
    1000          If-Match, If-None-Match, or If-Range header field. A conditional GET method requests that the entity be transferred only under
    1001          the circumstances described by the conditional header field(s). The conditional GET method is intended to reduce unnecessary
    1002          network usage by allowing cached entities to be refreshed without requiring multiple requests or transferring data already
    1003          held by the client.
     1000         If-Match, If-None-Match, or If-Range header field. A conditional GET method requests that the representation be transferred
     1001         only under the circumstances described by the conditional header field(s). The conditional GET method is intended to reduce
     1002         unnecessary network usage by allowing cached entities to be refreshed without requiring multiple requests or transferring
     1003         data already held by the client.
    10041004      </p>
    10051005      <p id="rfc.section.7.3.p.4">The semantics of the GET method change to a "partial GET" if the request message includes a Range header field. A partial
    1006          GET requests that only part of the entity be transferred, as described in <a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.10"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. The partial GET method is intended to reduce unnecessary network usage by allowing partially-retrieved entities to be completed
    1007          without transferring data already held by the client.
     1006         GET requests that only part of the representation be transferred, as described in <a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.10"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. The partial GET method is intended to reduce unnecessary network usage by allowing partially-retrieved representations to
     1007         be completed without transferring data already held by the client.
    10081008      </p>
    10091009      <p id="rfc.section.7.3.p.5">The response to a GET request is cacheable if and only if it meets the requirements for HTTP caching described in <a href="#Part6" id="rfc.xref.Part6.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.
    … …  
    10141014      <div id="rfc.iref.h.1"></div>
    10151015      <div id="rfc.iref.m.3"></div>
    1016       <p id="rfc.section.7.4.p.1">The HEAD method is identical to GET except that the server <em class="bcp14">MUST NOT</em> return a message-body in the response. The metainformation contained in the HTTP headers in response to a HEAD request <em class="bcp14">SHOULD</em> be identical to the information sent in response to a GET request. This method can be used for obtaining metainformation about
    1017          the entity implied by the request without transferring the entity-body itself. This method is often used for testing hypertext
    1018          links for validity, accessibility, and recent modification.
     1016      <p id="rfc.section.7.4.p.1">The HEAD method is identical to GET except that the server <em class="bcp14">MUST NOT</em> return a message-body in the response. The metadata contained in the HTTP headers in response to a HEAD request <em class="bcp14">SHOULD</em> be identical to the information sent in response to a GET request. This method can be used for obtaining metadata about the
     1017         representation implied by the request without transferring the representation body. This method is often used for testing
     1018         hypertext links for validity, accessibility, and recent modification.
    10191019      </p>
    10201020      <p id="rfc.section.7.4.p.2">The response to a HEAD request <em class="bcp14">MAY</em> be cacheable in the sense that the information contained in the response <em class="bcp14">MAY</em> be used to update a previously cached entity from that resource. If the new field values indicate that the cached entity differs
    … …  
    10511051      <div id="rfc.iref.m.5"></div>
    10521052      <h2 id="rfc.section.7.6"><a href="#rfc.section.7.6">7.6</a>&nbsp;<a id="PUT" href="#PUT">PUT</a></h2>
    1053       <p id="rfc.section.7.6.p.1">The PUT method requests that the enclosed entity be stored at the Effective Request URI. If the Effective Request URI refers
    1054          to an already existing resource, the enclosed entity <em class="bcp14">SHOULD</em> be considered as a modified version of the one residing on the origin server. Otherwise, if the Effective Request URI does
    1055          not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent,
    1056          the origin server can create the resource with that URI.
     1053      <p id="rfc.section.7.6.p.1">The PUT method requests that the enclosed representation be stored at the Effective Request URI. If the Effective Request
     1054         URI refers to an already existing resource, the enclosed representation <em class="bcp14">SHOULD</em> be considered a modified version of the one residing on the origin server. Otherwise, if the Effective Request URI does not
     1055         point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the
     1056         origin server can create the resource with that URI.
    10571057      </p>
    10581058      <p id="rfc.section.7.6.p.2">If a new resource is created at the Effective Request URI, the origin server <em class="bcp14">MUST</em> inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No
    10591059         Content) response codes <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request.
    10601060      </p>
    1061       <p id="rfc.section.7.6.p.3">If the resource could not be created or modified with the Effective Request URI, an appropriate error response <em class="bcp14">SHOULD</em> be given that reflects the nature of the problem. The recipient of the entity <em class="bcp14">MUST NOT</em> ignore any Content-* headers (headers starting with the prefix "Content-") that it does not understand or implement and <em class="bcp14">MUST</em> return a 501 (Not Implemented) response in such cases.
    1062       </p>
    1063       <p id="rfc.section.7.6.p.4">If the request passes through a cache and the Effective Request URI identifies one or more currently cached entities, those
    1064          entries <em class="bcp14">SHOULD</em> be treated as stale. Responses to this method are not cacheable.
     1061      <p id="rfc.section.7.6.p.3">If the resource identified by the Effective Request URI could not be created or modified, an appropriate error response <em class="bcp14">SHOULD</em> be given that reflects the nature of the problem. The recipient of the representation <em class="bcp14">MUST NOT</em> ignore any Content-* headers (headers starting with the prefix "Content-") that it does not understand or implement and <em class="bcp14">MUST</em> return a 501 (Not Implemented) response in such cases.
     1062      </p>
     1063      <p id="rfc.section.7.6.p.4">If the request passes through a cache that has one or more stored responses for the Effective Request URI, those stored responses <em class="bcp14">SHOULD</em> be marked as stale if the response to the PUT request is a success status. Responses to the PUT method are not cacheable.
    10651064      </p>
    10661065      <p id="rfc.section.7.6.p.5">The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Effective Request
    1067          URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting
    1068          process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request
    1069          identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server <em class="bcp14">MUST NOT</em> attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI,
     1066         URI. The URI in a POST request identifies the resource that will handle the enclosed representation. That resource might be
     1067         a data-accepting process, a gateway to some other protocol, or a document that accepts annotations. In contrast, the URI in
     1068         a PUT request identifies the resource for which enclosed representation is a new or replacement value; the user agent knows
     1069         what URI is intended and the server <em class="bcp14">MUST NOT</em> attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI,
    10701070         it <em class="bcp14">MUST</em> send a 301 (Moved Permanently) response; the user agent <em class="bcp14">MAY</em> then make its own decision regarding whether or not to redirect the request.
    10711071      </p>
    … …  
    10861086      </p>
    10871087      <p id="rfc.section.7.7.p.2">A successful response <em class="bcp14">SHOULD</em> be 200 (OK) if the response includes an entity describing the status, 202 (Accepted) if the action has not yet been enacted,
    1088          or 204 (No Content) if the action has been enacted but the response does not include an entity.
     1088         or 204 (No Content) if the action has been enacted but the response does not include a representation.
    10891089      </p>
    10901090      <p id="rfc.section.7.7.p.3">If the request passes through a cache and the Effective Request URI identifies one or more currently cached entities, those
    … …  
    10961096      <p id="rfc.section.7.8.p.1">The TRACE method is used to invoke a remote, application-layer loop-back of the request message. The final recipient of the
    10971097         request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the entity-body of a 200 (OK) response. The final recipient is either the
    1098          origin server or the first proxy or gateway to receive a Max-Forwards value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section&nbsp;9.5</a>). A TRACE request <em class="bcp14">MUST NOT</em> include an entity.
     1098         origin server or the first proxy or gateway to receive a Max-Forwards value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section&nbsp;9.5</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message-body.
    10991099      </p>
    11001100      <p id="rfc.section.7.8.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing
    … …  
    11121112      </p>
    11131113      <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="status.codes" href="#status.codes">Status Code Definitions</a></h1>
    1114       <p id="rfc.section.8.p.1">Each Status-Code is described below, including any metainformation required in the response.</p>
     1114      <p id="rfc.section.8.p.1">Each Status-Code is described below, including any metadata required in the response.</p>
    11151115      <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a>&nbsp;<a id="status.1xx" href="#status.1xx">Informational 1xx</a></h2>
    11161116      <p id="rfc.section.8.1.p.1">This class of status code indicates a provisional response, consisting only of the Status-Line and optional headers, and is
    … …  
    11811181      <p id="rfc.section.8.2.3.p.2">The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process
    11821182         (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the
    1183          server persist until the process is completed. The entity returned with this response <em class="bcp14">SHOULD</em> include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the
     1183         server persist until the process is completed. The representation returned with this response <em class="bcp14">SHOULD</em> include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the
    11841184         user can expect the request to be fulfilled.
    11851185      </p>
    … …  
    11871187      <div id="rfc.iref.s.7"></div>
    11881188      <h3 id="rfc.section.8.2.4"><a href="#rfc.section.8.2.4">8.2.4</a>&nbsp;<a id="status.203" href="#status.203">203 Non-Authoritative Information</a></h3>
    1189       <p id="rfc.section.8.2.4.p.1">The returned metainformation in the entity-header is not the definitive set as available from the origin server, but is gathered
     1189      <p id="rfc.section.8.2.4.p.1">The returned metadata in the entity-header is not the definitive set as available from the origin server, but is gathered
    11901190         from a local or a third-party copy. The set presented <em class="bcp14">MAY</em> be a subset or superset of the original version. For example, including local annotation information about the resource might
    1191          result in a superset of the metainformation known by the origin server. Use of this response code is not required and is only
    1192          appropriate when the response would otherwise be 200 (OK).
     1191         result in a superset of the metadata known by the origin server. Use of this response code is not required and is only appropriate
     1192         when the response would otherwise be 200 (OK).
    11931193      </p>
    11941194      <div id="rfc.iref.31"></div>
    … …  
    12111211      <p id="rfc.section.8.2.6.p.1">The server has fulfilled the request and the user agent <em class="bcp14">SHOULD</em> reset the document view which caused the request to be sent. This response is primarily intended to allow input for actions
    12121212         to take place via user input, followed by a clearing of the form in which the input is given so that the user can easily initiate
    1213          another input action. The response <em class="bcp14">MUST NOT</em> include an entity.
     1213         another input action. The response <em class="bcp14">MUST NOT</em> include a message-body.
    12141214      </p>
    12151215      <div id="rfc.iref.33"></div>
    … …  
    12351235         location.
    12361236      </p>
    1237       <p id="rfc.section.8.3.1.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose
    1238          the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. Depending
     1237      <p id="rfc.section.8.3.1.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include a representation containing a list of resource characteristics and location(s) from which the user or user agent can
     1238         choose the one most appropriate. The data format is specified by the media type given in the Content-Type header field. Depending
    12391239         upon the format and the capabilities of the user agent, selection of the most appropriate choice <em class="bcp14">MAY</em> be performed automatically. However, this specification does not define any standard for such automatic selection.
    12401240      </p>
    … …  
    12481248         indicated otherwise.
    12491249      </p>
    1250       <p id="rfc.section.8.3.2.p.2">The new permanent URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the entity of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s).
     1250      <p id="rfc.section.8.3.2.p.2">The new permanent URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the representation of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s).
    12511251      </p>
    12521252      <p id="rfc.section.8.3.2.p.3">If the 301 status code is received in response to a request method that is known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section&nbsp;7.1.1</a>, then the request <em class="bcp14">MAY</em> be automatically redirected by the user agent without confirmation. Otherwise, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which
    … …  
    12651265         or Expires header field.
    12661266      </p>
    1267       <p id="rfc.section.8.3.3.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the entity of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s).
     1267      <p id="rfc.section.8.3.3.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the representation of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s).
    12681268      </p>
    12691269      <p id="rfc.section.8.3.3.p.3">If the 302 status code is received in response to a request method that is known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section&nbsp;7.1.1</a>, then the request <em class="bcp14">MAY</em> be automatically redirected by the user agent without confirmation. Otherwise, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which
    … …  
    12951295      </p>
    12961296      <p id="rfc.section.8.3.4.p.4">A 303 response <em class="bcp14">SHOULD NOT</em> be cached unless it is indicated as cacheable by Cache-Control or Expires header fields. Except for responses to a HEAD request,
    1297          the entity of a 303 response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the Location URI.
     1297         the representation of a 303 response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the Location URI.
    12981298      </p>
    12991299      <div id="rfc.iref.38"></div>
    … …  
    13181318         or Expires header field.
    13191319      </p>
    1320       <p id="rfc.section.8.3.8.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the entity of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s) , since many pre-HTTP/1.1 user agents do not understand
     1320      <p id="rfc.section.8.3.8.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the representation of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s) , since many pre-HTTP/1.1 user agents do not understand
    13211321         the 307 status. Therefore, the note <em class="bcp14">SHOULD</em> contain the information necessary for a user to repeat the original request on the new URI.
    13221322      </p>
    … …  
    13521352      <h3 id="rfc.section.8.4.4"><a href="#rfc.section.8.4.4">8.4.4</a>&nbsp;<a id="status.403" href="#status.403">403 Forbidden</a></h3>
    13531353      <p id="rfc.section.8.4.4.p.1">The server understood the request, but is refusing to fulfill it. Authorization will not help and the request <em class="bcp14">SHOULD NOT</em> be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled,
    1354          it <em class="bcp14">SHOULD</em> describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client,
    1355          the status code 404 (Not Found) can be used instead.
     1354         it <em class="bcp14">SHOULD</em> describe the reason for the refusal in the representation. If the server does not wish to make this information available
     1355         to the client, the status code 404 (Not Found) can be used instead.
    13561356      </p>
    13571357      <div id="rfc.iref.46"></div>
    … …  
    13741374         not acceptable according to the accept headers sent in the request.
    13751375      </p>
    1376       <p id="rfc.section.8.4.7.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include an entity containing a list of available entity characteristics and location(s) from which the user or user agent
    1377          can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field.
    1378          Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice <em class="bcp14">MAY</em> be performed automatically. However, this specification does not define any standard for such automatic selection.
     1376      <p id="rfc.section.8.4.7.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include a representation containing a list of available representation characteristics and location(s) from which the user
     1377         or user agent can choose the one most appropriate. The data format is specified by the media type given in the Content-Type
     1378         header field. Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice <em class="bcp14">MAY</em> be performed automatically. However, this specification does not define any standard for such automatic selection.
    13791379      </p>
    13801380      <div class="note" id="rfc.section.8.4.7.p.3">
    … …  
    14041404         enough information for the user or user agent to fix the problem; however, that might not be possible and is not required.
    14051405      </p>
    1406       <p id="rfc.section.8.4.10.p.2">Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the entity
     1406      <p id="rfc.section.8.4.10.p.2">Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the representation
    14071407         being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might
    1408          use the 409 response to indicate that it can't complete the request. In this case, the response entity would likely contain
    1409          a list of the differences between the two versions in a format defined by the response Content-Type.
     1408         use the 409 response to indicate that it can't complete the request. In this case, the response representation would likely
     1409         contain a list of the differences between the two versions in a format defined by the response Content-Type.
    14101410      </p>
    14111411      <div id="rfc.iref.52"></div>
    … …  
    14541454      <div id="rfc.iref.s.34"></div>
    14551455      <h3 id="rfc.section.8.4.16"><a href="#rfc.section.8.4.16">8.4.16</a>&nbsp;<a id="status.415" href="#status.415">415 Unsupported Media Type</a></h3>
    1456       <p id="rfc.section.8.4.16.p.1">The server is refusing to service the request because the entity of the request is in a format not supported by the requested
    1457          resource for the requested method.
     1456      <p id="rfc.section.8.4.16.p.1">The server is refusing to service the request because the representation of the request is in a format not supported by the
     1457         requested resource for the requested method.
    14581458      </p>
    14591459      <div id="rfc.iref.58"></div>
    … …  
    15201520      <p id="rfc.section.9.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to request and response semantics.</p>
    15211521      <p id="rfc.section.9.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who
    1522          receives the entity.
     1522         receives the message.
    15231523      </p>
    15241524      <div id="rfc.iref.a.1"></div>
    … …  
    16111611      </div>
    16121612      <div class="note" id="rfc.section.9.4.p.9">
    1613          <p> <b>Note:</b> The Content-Location header field (<a href="p3-payload.html#header.content-location" title="Content-Location">Section 5.7</a> of <a href="#Part3" id="rfc.xref.Part3.11"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) differs from Location in that the Content-Location identifies the original location of the entity enclosed in the response.
     1613         <p> <b>Note:</b> The Content-Location header field (<a href="p3-payload.html#header.content-location" title="Content-Location">Section 5.7</a> of <a href="#Part3" id="rfc.xref.Part3.11"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation.
    16141614            It is therefore possible for a response to contain header fields for both Location and Content-Location.
    16151615         </p>
    … …  
    21192119         has no better mechanism.
    21202120      </p>
    2121       <p id="rfc.section.11.1.p.8">Some methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section&nbsp;7.8</a>) may expose information sent in request headers in the response entity. Clients <em class="bcp14">SHOULD</em> be careful with sensitive information, like Cookies, Authorization credentials and other headers that might be used to collect
     2121      <p id="rfc.section.11.1.p.8">Some methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section&nbsp;7.8</a>) may expose information sent in request headers in the response. Clients <em class="bcp14">SHOULD</em> be careful with sensitive information, like Cookies, Authorization credentials and other headers that might be used to collect
    21222122         data from the client.
    21232123      </p>

  • draft-ietf-httpbis/latest/p3-payload.html

    r865 r868  
    742742      </p>
    743743      <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="content.codings" href="#content.codings">Content Codings</a></h2>
    744       <p id="rfc.section.2.2.p.1">Content coding values indicate an encoding transformation that has been or can be applied to an entity. Content codings are
    745          primarily used to allow a document to be compressed or otherwise usefully transformed without losing the identity of its underlying
    746          media type and without loss of information. Frequently, the entity is stored in coded form, transmitted directly, and only
    747          decoded by the recipient.
     744      <p id="rfc.section.2.2.p.1">Content coding values indicate an encoding transformation that has been or can be applied to a representation. Content codings
     745         are primarily used to allow a representation to be compressed or otherwise usefully transformed without losing the identity
     746         of its underlying media type and without loss of information. Frequently, the representation is stored in coded form, transmitted
     747         directly, and only decoded by the recipient.
    748748      </p>
    749749      <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.2"></span>  <a href="#content.codings" class="smpl">content-coding</a>   = <a href="#core.rules" class="smpl">token</a>
    … …  
    867867      </p>
    868868      <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="entity" href="#entity">Entity</a></h1>
    869       <p id="rfc.section.3.p.1">Request and Response messages <em class="bcp14">MAY</em> transfer an entity if not otherwise restricted by the request method or response status code. An entity consists of entity-header
    870          fields and an entity-body, although some responses will only include the entity-headers.
     869      <p id="rfc.section.3.p.1">Request and Response messages <em class="bcp14">MAY</em> transfer a representation if not otherwise restricted by the request method or response status code. A representation consists
     870         of entity-header fields and a representation body, although some responses will only include the entity-headers.
    871871      </p>
    872872      <p id="rfc.section.3.p.2">In this section, both sender and recipient refer to either the client or the server, depending on who sends and who receives
    873          the entity.
     873         the message.
    874874      </p>
    875875      <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="entity.header.fields" href="#entity.header.fields">Entity Header Fields</a></h2>
    876       <p id="rfc.section.3.1.p.1">Entity-header fields define metainformation about the entity-body or, if no body is present, about the resource identified
    877          by the request.
     876      <p id="rfc.section.3.1.p.1">Entity-header fields define metadata about the entity-body or, if no body is present, about the resource identified by the
     877         request.
    878878      </p>
    879879      <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span>  <a href="#entity.header.fields" class="smpl">entity-header</a>  = <a href="#header.content-encoding" class="smpl">Content-Encoding</a>         ; <a href="#header.content-encoding" id="rfc.xref.header.content-encoding.2" title="Content-Encoding">Section&nbsp;5.5</a>
    … …  
    996996      <p id="rfc.section.5.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to the payload of messages.</p>
    997997      <p id="rfc.section.5.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who
    998          receives the entity.
     998         receives the message.
    999999      </p>
    10001000      <div id="rfc.iref.a.1"></div>
    … …  
    10421042          text/x-dvi; q=0.8, text/x-c
    10431043</pre><p id="rfc.section.5.1.p.12">Verbally, this would be interpreted as "text/html and text/x-c are the preferred media types, but if they do not exist, then
    1044          send the text/x-dvi entity, and if that does not exist, send the text/plain entity."
     1044         send the text/x-dvi representation, and if that does not exist, send the text/plain representation."
    10451045      </p>
    10461046      <p id="rfc.section.5.1.p.13">Media ranges can be overridden by more specific media ranges or specific media types. If more than one media range applies
    … …  
    12141214      <div id="rfc.iref.h.5"></div>
    12151215      <h2 id="rfc.section.5.5"><a href="#rfc.section.5.5">5.5</a>&nbsp;<a id="header.content-encoding" href="#header.content-encoding">Content-Encoding</a></h2>
    1216       <p id="rfc.section.5.5.p.1">The "Content-Encoding" entity-header field indicates what content-codings have been applied to the entity-body, and thus what
    1217          decoding mechanisms must be applied in order to obtain the media-type referenced by the Content-Type header field. Content-Encoding
    1218          is primarily used to allow a document to be compressed without losing the identity of its underlying media type.
     1216      <p id="rfc.section.5.5.p.1">The "Content-Encoding" entity-header field indicates what content-codings have been applied to the representation, and thus
     1217         what decoding mechanisms must be applied in order to obtain the media-type referenced by the Content-Type header field. Content-Encoding
     1218         is primarily used to allow a representation to be compressed without losing the identity of its underlying media type.
    12191219      </p>
    12201220      <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.27"></span><span id="rfc.iref.g.28"></span>  <a href="#header.content-encoding" class="smpl">Content-Encoding</a>   = "Content-Encoding" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-encoding" class="smpl">Content-Encoding-v</a>
    … …  
    12231223      </p>
    12241224      <div id="rfc.figure.u.27"></div><pre class="text">  Content-Encoding: gzip
    1225 </pre><p id="rfc.section.5.5.p.5">The content-coding is a characteristic of the entity identified by the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Typically, the entity-body is stored with this encoding and is only decoded before rendering or analogous usage. However,
    1226          a non-transparent proxy <em class="bcp14">MAY</em> modify the content-coding if the new coding is known to be acceptable to the recipient, unless the "no-transform" cache-control
     1225</pre><p id="rfc.section.5.5.p.5">The content-coding is a characteristic of the representation. Typically, the representation body is stored with this encoding
     1226         and is only decoded before rendering or analogous usage. However, a non-transparent proxy <em class="bcp14">MAY</em> modify the content-coding if the new coding is known to be acceptable to the recipient, unless the "no-transform" cache-control
    12271227         directive is present in the message.
    12281228      </p>
    1229       <p id="rfc.section.5.5.p.6">If the content-coding of an entity is not "identity", then the response <em class="bcp14">MUST</em> include a Content-Encoding entity-header (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.3" title="Content-Encoding">Section&nbsp;5.5</a>) that lists the non-identity content-coding(s) used.
     1229      <p id="rfc.section.5.5.p.6">If the content-coding of a representation is not "identity", then the representation metadata <em class="bcp14">MUST</em> include a Content-Encoding header field (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.3" title="Content-Encoding">Section&nbsp;5.5</a>) that lists the non-identity content-coding(s) used.
    12301230      </p>
    12311231      <p id="rfc.section.5.5.p.7">If the content-coding of an entity in a request message is not acceptable to the origin server, the server <em class="bcp14">SHOULD</em> respond with a status code of 415 (Unsupported Media Type).
    12321232      </p>
    1233       <p id="rfc.section.5.5.p.8">If multiple encodings have been applied to an entity, the content codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other entity-header fields not defined by this specification.
     1233      <p id="rfc.section.5.5.p.8">If multiple encodings have been applied to a representation, the content codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
    12341234      </p>
    12351235      <div id="rfc.iref.c.8"></div>
    12361236      <div id="rfc.iref.h.6"></div>
    12371237      <h2 id="rfc.section.5.6"><a href="#rfc.section.5.6">5.6</a>&nbsp;<a id="header.content-language" href="#header.content-language">Content-Language</a></h2>
    1238       <p id="rfc.section.5.6.p.1">The "Content-Language" entity-header field describes the natural language(s) of the intended audience for the entity. Note
    1239          that this might not be equivalent to all the languages used within the entity-body.
     1238      <p id="rfc.section.5.6.p.1">The "Content-Language" entity-header field describes the natural language(s) of the intended audience for the representation.
     1239         Note that this might not be equivalent to all the languages used within the entity-body.
    12401240      </p>
    12411241      <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span>  <a href="#header.content-language" class="smpl">Content-Language</a>   = "Content-Language" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-language" class="smpl">Content-Language-v</a>
    12421242  <a href="#header.content-language" class="smpl">Content-Language-v</a> = 1#<a href="#language.tags" class="smpl">language-tag</a>
    1243 </pre><p id="rfc.section.5.6.p.3">Language tags are defined in <a href="#language.tags" title="Language Tags">Section&nbsp;2.4</a>. The primary purpose of Content-Language is to allow a user to identify and differentiate entities according to the user's
    1244          own preferred language. Thus, if the body content is intended only for a Danish-literate audience, the appropriate field is
     1243</pre><p id="rfc.section.5.6.p.3">Language tags are defined in <a href="#language.tags" title="Language Tags">Section&nbsp;2.4</a>. The primary purpose of Content-Language is to allow a user to identify and differentiate representations according to the
     1244         user's own preferred language. Thus, if the body content is intended only for a Danish-literate audience, the appropriate
     1245         field is
    12451246      </p>
    12461247      <div id="rfc.figure.u.29"></div><pre class="text">  Content-Language: da
    … …  
    12531254      </p>
    12541255      <div id="rfc.figure.u.30"></div><pre class="text">  Content-Language: mi, en
    1255 </pre><p id="rfc.section.5.6.p.8">However, just because multiple languages are present within an entity does not mean that it is intended for multiple linguistic
    1256          audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin," which is clearly intended
    1257          to be used by an English-literate audience. In this case, the Content-Language would properly only include "en".
     1256</pre><p id="rfc.section.5.6.p.8">However, just because multiple languages are present within a representation does not mean that it is intended for multiple
     1257         linguistic audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin," which is clearly
     1258         intended to be used by an English-literate audience. In this case, the Content-Language would properly only include "en".
    12581259      </p>
    12591260      <p id="rfc.section.5.6.p.9">Content-Language <em class="bcp14">MAY</em> be applied to any media type -- it is not limited to textual documents.
    … …  
    12701271  <a href="#header.content-location" class="smpl">Content-Location-v</a> =
    12711272                    <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a>
    1272 </pre><p id="rfc.section.5.7.p.3">The Content-Location value is not a replacement for the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME
     1273</pre><p id="rfc.section.5.7.p.3">The Content-Location value is not a replacement for the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME
    12731274         body parts in <a href="http://tools.ietf.org/html/rfc2557#section-4">Section 4</a> of <a href="#RFC2557" id="rfc.xref.RFC2557.1"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a>. However, its appearance in an HTTP message has some special implications for HTTP recipients.
    12741275      </p>
    … …  
    13171318      <p id="rfc.section.5.8.p.4">The MD5 digest is computed based on the content of the entity-body, including any content-coding that has been applied, but
    13181319         not including any transfer-encoding applied to the message-body. If the message is received with a transfer-encoding, that
    1319          encoding <em class="bcp14">MUST</em> be removed prior to checking the Content-MD5 value against the received entity.
     1320         encoding <em class="bcp14">MUST</em> be removed prior to checking the Content-MD5 value against the received representation.
    13201321      </p>
    13211322      <p id="rfc.section.5.8.p.5">This has the result that the digest is computed on the octets of the entity-body exactly as, and in the order that, they would
    … …  
    14701471                  <td class="left">compress</td>
    14711472                  <td class="left">UNIX "compress" program method</td>
    1472                   <td class="left"> <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 6.2.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>
     1473                  <td class="left"> <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 6.2.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>
    14731474                  </td>
    14741475               </tr>
    … …  
    14771478                  <td class="left">"deflate" compression mechanism (<a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>) used inside the "zlib" data format (<a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a>)
    14781479                  </td>
    1479                   <td class="left"> <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 6.2.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>
     1480                  <td class="left"> <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 6.2.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>
    14801481                  </td>
    14811482               </tr>
    … …  
    14831484                  <td class="left">gzip</td>
    14841485                  <td class="left">Same as GNU zip <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a></td>
    1485                   <td class="left"> <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 6.2.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>
     1486                  <td class="left"> <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 6.2.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>
    14861487                  </td>
    14871488               </tr>
    … …  
    17501751      </p>
    17511752      <h2 id="rfc.section.A.3"><a href="#rfc.section.A.3">A.3</a>&nbsp;<a id="conversion.of.date.formats" href="#conversion.of.date.formats">Conversion of Date Formats</a></h2>
    1752       <p id="rfc.section.A.3.p.1">HTTP/1.1 uses a restricted set of date formats (<a href="p1-messaging.html#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) to simplify the process of date comparison. Proxies and gateways from other protocols <em class="bcp14">SHOULD</em> ensure that any Date header field present in a message conforms to one of the HTTP/1.1 formats and rewrite the date if necessary.
     1753      <p id="rfc.section.A.3.p.1">HTTP/1.1 uses a restricted set of date formats (<a href="p1-messaging.html#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) to simplify the process of date comparison. Proxies and gateways from other protocols <em class="bcp14">SHOULD</em> ensure that any Date header field present in a message conforms to one of the HTTP/1.1 formats and rewrite the date if necessary.
    17531754      </p>
    17541755      <h2 id="rfc.section.A.4"><a href="#rfc.section.A.4">A.4</a>&nbsp;<a id="introduction.of.content-encoding" href="#introduction.of.content-encoding">Introduction of Content-Encoding</a></h2>
    … …  
    17671768      </p>
    17681769      <h2 id="rfc.section.A.6"><a href="#rfc.section.A.6">A.6</a>&nbsp;<a id="introduction.of.transfer-encoding" href="#introduction.of.transfer-encoding">Introduction of Transfer-Encoding</a></h2>
    1769       <p id="rfc.section.A.6.p.1">HTTP/1.1 introduces the Transfer-Encoding header field (<a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 9.7</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Proxies/gateways <em class="bcp14">MUST</em> remove any transfer-coding prior to forwarding a message via a MIME-compliant protocol.
     1770      <p id="rfc.section.A.6.p.1">HTTP/1.1 introduces the Transfer-Encoding header field (<a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 9.7</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Proxies/gateways <em class="bcp14">MUST</em> remove any transfer-coding prior to forwarding a message via a MIME-compliant protocol.
    17701771      </p>
    17711772      <h2 id="rfc.section.A.7"><a href="#rfc.section.A.7">A.7</a>&nbsp;<a id="mhtml.line.length" href="#mhtml.line.length">MHTML and Line Length Limitations</a></h2>
    … …  
    22272228            </li>
    22282229            <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind">
    2229                   <li class="indline1"><em>Part1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">1.3</a>, <a class="iref" href="#rfc.xref.Part1.2">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.7">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.8">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.9">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.11">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.12">2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">2.2</a>, <a class="iref" href="#rfc.xref.Part1.14">2.2</a>, <a class="iref" href="#rfc.xref.Part1.15">2.2.1</a>, <a class="iref" href="#rfc.xref.Part1.16">2.2.1</a>, <a class="iref" href="#rfc.xref.Part1.17">3.1</a>, <a class="iref" href="#rfc.xref.Part1.18">3.2</a>, <a class="iref" href="#rfc.xref.Part1.19">5.1</a>, <a class="iref" href="#rfc.xref.Part1.20">5.3</a>, <a class="iref" href="#rfc.xref.Part1.21">5.5</a>, <a class="iref" href="#rfc.xref.Part1.22">5.7</a>, <a class="iref" href="#rfc.xref.Part1.23">6.2</a>, <a class="iref" href="#rfc.xref.Part1.24">6.2</a>, <a class="iref" href="#rfc.xref.Part1.25">6.2</a>, <a class="iref" href="#Part1"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.Part1.26">A.3</a>, <a class="iref" href="#rfc.xref.Part1.27">A.6</a><ul class="ind">
     2230                  <li class="indline1"><em>Part1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">1.3</a>, <a class="iref" href="#rfc.xref.Part1.2">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.7">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.8">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.9">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.11">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.12">2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">2.2</a>, <a class="iref" href="#rfc.xref.Part1.14">2.2</a>, <a class="iref" href="#rfc.xref.Part1.15">2.2.1</a>, <a class="iref" href="#rfc.xref.Part1.16">2.2.1</a>, <a class="iref" href="#rfc.xref.Part1.17">3.1</a>, <a class="iref" href="#rfc.xref.Part1.18">3.2</a>, <a class="iref" href="#rfc.xref.Part1.19">5.1</a>, <a class="iref" href="#rfc.xref.Part1.20">5.3</a>, <a class="iref" href="#rfc.xref.Part1.21">5.7</a>, <a class="iref" href="#rfc.xref.Part1.22">6.2</a>, <a class="iref" href="#rfc.xref.Part1.23">6.2</a>, <a class="iref" href="#rfc.xref.Part1.24">6.2</a>, <a class="iref" href="#Part1"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.Part1.25">A.3</a>, <a class="iref" href="#rfc.xref.Part1.26">A.6</a><ul class="ind">
    22302231                        <li class="indline1"><em>Section 1.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">1.3</a></li>
    22312232                        <li class="indline1"><em>Section 1.2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.2">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.3.1</a></li>
    … …  
    22332234                        <li class="indline1"><em>Section 3.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.9">1.3.2</a></li>
    22342235                        <li class="indline1"><em>Section 3.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.18">3.2</a></li>
    2235                         <li class="indline1"><em>Section 4.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.21">5.5</a>, <a class="iref" href="#rfc.xref.Part1.22">5.7</a></li>
    2236                         <li class="indline1"><em>Section 6.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.26">A.3</a></li>
     2236                        <li class="indline1"><em>Section 4.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.21">5.7</a></li>
     2237                        <li class="indline1"><em>Section 6.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.25">A.3</a></li>
    22372238                        <li class="indline1"><em>Section 6.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.15">2.2.1</a></li>
    2238                         <li class="indline1"><em>Section 6.2.2.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.12">2.2</a>, <a class="iref" href="#rfc.xref.Part1.23">6.2</a></li>
     2239                        <li class="indline1"><em>Section 6.2.2.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.12">2.2</a>, <a class="iref" href="#rfc.xref.Part1.22">6.2</a></li>
    22392240                        <li class="indline1"><em>Section 6.2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.16">2.2.1</a></li>
    2240                         <li class="indline1"><em>Section 6.2.2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.13">2.2</a>, <a class="iref" href="#rfc.xref.Part1.24">6.2</a></li>
    2241                         <li class="indline1"><em>Section 6.2.2.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.14">2.2</a>, <a class="iref" href="#rfc.xref.Part1.25">6.2</a></li>
     2241                        <li class="indline1"><em>Section 6.2.2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.13">2.2</a>, <a class="iref" href="#rfc.xref.Part1.23">6.2</a></li>
     2242                        <li class="indline1"><em>Section 6.2.2.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.14">2.2</a>, <a class="iref" href="#rfc.xref.Part1.24">6.2</a></li>
    22422243                        <li class="indline1"><em>Section 6.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.11">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.19">5.1</a>, <a class="iref" href="#rfc.xref.Part1.20">5.3</a></li>
    22432244                        <li class="indline1"><em>Section 9.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.8">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.17">3.1</a></li>
    2244                         <li class="indline1"><em>Section 9.7</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.27">A.6</a></li>
     2245                        <li class="indline1"><em>Section 9.7</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.26">A.6</a></li>
    22452246                     </ul>
    22462247                  </li>

  • draft-ietf-httpbis/latest/p4-conditional.html

    r863 r868  
    704704      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="status.412" href="#status.412">412 Precondition Failed</a></h2>
    705705      <p id="rfc.section.3.2.p.1">The precondition given in one or more of the request-header fields evaluated to false when it was tested on the server. This
    706          response code allows the client to place preconditions on the current resource metainformation (header field data) and thus
    707          prevent the requested method from being applied to a resource other than the one intended.
     706         response code allows the client to place preconditions on the current resource metadata (header field data) and thus prevent
     707         the requested method from being applied to a resource other than the one intended.
    708708      </p>
    709709      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="weak.and.strong.validators" href="#weak.and.strong.validators">Weak and Strong Validators</a></h1>
    710       <p id="rfc.section.4.p.1">Since both origin servers and caches will compare two validators to decide if they represent the same or different entities,
    711          one normally would expect that if the entity (the entity-body or any entity-headers) changes in any way, then the associated
    712          validator would change as well. If this is true, then we call this validator a "strong validator."
     710      <p id="rfc.section.4.p.1">Since both origin servers and caches will compare two validators to decide if they represent the same or different representations,
     711         one normally would expect that if the representation (including both representation header fields and representation body)
     712         changes in any way, then the associated validator would change as well. If this is true, then we call this validator a "strong
     713         validator."
    713714      </p>
    714715      <p id="rfc.section.4.p.2">However, there might be cases when a server prefers to change the validator only on semantically significant changes, and
    715          not when insignificant aspects of the entity change. A validator that does not always change when the resource changes is
    716          a "weak validator."
     716         not when insignificant aspects of the representation change. A validator that does not always change when the representation
     717         changes is a "weak validator."
    717718      </p>
    718719      <p id="rfc.section.4.p.3">Entity tags are normally "strong validators," but the protocol provides a mechanism to tag an entity tag as "weak." One can
    719          think of a strong validator as one that changes whenever the bits of an entity changes, while a weak value changes whenever
    720          the meaning of an entity changes. Alternatively, one can think of a strong validator as part of an identifier for a specific
    721          entity, while a weak validator is part of an identifier for a set of semantically equivalent entities.
     720         think of a strong validator as one that changes whenever the sequence of bits in a representation changes, while a weak value
     721         changes whenever the meaning of a representation changes. Alternatively, one can think of a strong validator as part of an
     722         identifier for a specific representation, whereas a weak validator is part of an identifier for a set of semantically equivalent
     723         representations.
    722724      </p>
    723725      <ul class="empty">
    724          <li> <b>Note:</b> One example of a strong validator is an integer that is incremented in stable storage every time an entity is changed.
    725          </li>
    726          <li>An entity's modification time, if represented with one-second resolution, could be a weak validator, since it is possible
    727             that the resource might be modified twice during a single second.
     726         <li> <b>Note:</b> One example of a strong validator is an integer that is incremented in stable storage every time a representation is changed.
     727         </li>
     728         <li>An entity's modification time, if defined with only one-second resolution, could be a weak validator, since it is possible
     729            that the representation might be modified twice during a single second.
    728730         </li>
    729731         <li>Support for weak validators is optional. However, weak validators allow for more efficient caching of equivalent objects;
    … …  
    736738      </p>
    737739      <p id="rfc.section.4.p.5">Strong validators are usable in any context. Weak validators are only usable in contexts that do not depend on exact equality
    738          of an entity. For example, either kind is usable for a conditional GET of a full entity. However, only a strong validator
    739          is usable for a sub-range retrieval, since otherwise the client might end up with an internally inconsistent entity.
     740         of a representation. For example, either kind is usable for a normal conditional GET. However, only a strong validator is
     741         usable for a sub-range retrieval, since otherwise the client might end up with an internally inconsistent representation.
    740742      </p>
    741743      <p id="rfc.section.4.p.6">Clients <em class="bcp14">MUST NOT</em> use weak validators in range requests (<a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>).
    … …  
    795797      </p>
    796798      <ul>
    797          <li>The validator is being compared by an origin server to the actual current validator for the entity and,</li>
    798          <li>That origin server reliably knows that the associated entity did not change twice during the second covered by the presented
    799             validator.
     799         <li>The validator is being compared by an origin server to the actual current validator for the representation and,</li>
     800         <li>That origin server reliably knows that the associated representation did not change twice during the second covered by the
     801            presented validator.
    800802         </li>
    801803      </ul>
    … …  
    803805      <ul>
    804806         <li>The validator is about to be used by a client in an If-Modified-Since or If-Unmodified-Since header, because the client has
    805             a cache entry for the associated entity, and
     807            a cache entry for the associated representation, and
    806808         </li>
    807809         <li>That cache entry includes a Date value, which gives the time when the origin server sent the original response, and</li>
    … …  
    810812      <p id="rfc.section.4.p.12">or </p>
    811813      <ul>
    812          <li>The validator is being compared by an intermediate cache to the validator stored in its cache entry for the entity, and</li>
     814         <li>The validator is being compared by an intermediate cache to the validator stored in its cache entry for the representation,
     815            and
     816         </li>
    813817         <li>That cache entry includes a Date value, which gives the time when the origin server sent the original response, and</li>
    814818         <li>The presented Last-Modified time is at least 60 seconds before the Date value.</li>
    … …  
    892896      <p id="rfc.section.6.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to conditional requests.</p>
    893897      <p id="rfc.section.6.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who
    894          receives the entity.
     898         receives the message.
    895899      </p>
    896900      <div id="rfc.iref.e.1"></div>
    … …  
    929933      <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.6"></span><span id="rfc.iref.g.7"></span>  <a href="#header.if-match" class="smpl">If-Match</a>   = "If-Match" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.if-match" class="smpl">If-Match-v</a>
    930934  <a href="#header.if-match" class="smpl">If-Match-v</a> = "*" / 1#<a href="#entity.tags" class="smpl">entity-tag</a>
    931 </pre><p id="rfc.section.6.2.p.4">If any of the entity tags match the entity tag of the entity that would have been returned in the response to a similar GET
    932          request (without the If-Match header) on that resource, or if "*" is given and any current entity exists for that resource,
     935</pre><p id="rfc.section.6.2.p.4">If any of the entity tags match the entity tag of the representation that would have been returned in the response to a similar
     936         GET request (without the If-Match header) on that resource, or if "*" is given and any current entity exists for that resource,
    933937         then the server <em class="bcp14">MAY</em> perform the requested method as if the If-Match header field did not exist.
    934938      </p>
    935       <p id="rfc.section.6.2.p.5">If none of the entity tags match, or if "*" is given and no current entity exists, the server <em class="bcp14">MUST NOT</em> perform the requested method, and <em class="bcp14">MUST</em> return a 412 (Precondition Failed) response. This behavior is most useful when the client wants to prevent an updating method,
     939      <p id="rfc.section.6.2.p.5">If none of the entity tags match, or if "*" is given and no current representation exists, the server <em class="bcp14">MUST NOT</em> perform the requested method, and <em class="bcp14">MUST</em> return a 412 (Precondition Failed) response. This behavior is most useful when the client wants to prevent an updating method,
    936940         such as PUT, from modifying a resource that has changed since the client last retrieved it.
    937941      </p>
    … …  
    941945      <p id="rfc.section.6.2.p.7">The meaning of "If-Match: *" is that the method <em class="bcp14">SHOULD</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">MUST NOT</em> be performed if the representation does not exist.
    942946      </p>
    943       <p id="rfc.section.6.2.p.8">A request intended to update a resource (e.g., a PUT) <em class="bcp14">MAY</em> include an If-Match header field to signal that the request method <em class="bcp14">MUST NOT</em> be applied if the entity corresponding to the If-Match value (a single entity tag) is no longer a representation of that resource.
    944          This allows the user to indicate that they do not wish the request to be successful if the resource has been changed without
    945          their knowledge. Examples:
     947      <p id="rfc.section.6.2.p.8">A request intended to update a resource (e.g., a PUT) <em class="bcp14">MAY</em> include an If-Match header field to signal that the request method <em class="bcp14">MUST NOT</em> be applied if the representation corresponding to the If-Match value (a single entity tag) is no longer a representation of
     948         that resource. This allows the user to indicate that they do not wish the request to be successful if the resource has been
     949         changed without their knowledge. Examples:
    946950      </p>
    947951      <div id="rfc.figure.u.10"></div><pre class="text">  If-Match: "xyzzy"
    … …  
    10141018      <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.10"></span><span id="rfc.iref.g.11"></span>  <a href="#header.if-none-match" class="smpl">If-None-Match</a>   = "If-None-Match" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.if-none-match" class="smpl">If-None-Match-v</a>
    10151019  <a href="#header.if-none-match" class="smpl">If-None-Match-v</a> = "*" / 1#<a href="#entity.tags" class="smpl">entity-tag</a>
    1016 </pre><p id="rfc.section.6.4.p.5">If any of the entity tags match the entity tag of the entity that would have been returned in the response to a similar GET
    1017          request (without the If-None-Match header) on that resource, or if "*" is given and any current entity exists for that resource,
    1018          then the server <em class="bcp14">MUST NOT</em> perform the requested method, unless required to do so because the resource's modification date fails to match that supplied
    1019          in an If-Modified-Since header field in the request. Instead, if the request method was GET or HEAD, the server <em class="bcp14">SHOULD</em> respond with a 304 (Not Modified) response, including the cache-related header fields (particularly ETag) of one of the entities
     1020</pre><p id="rfc.section.6.4.p.5">If any of the entity tags match the entity tag of the representation that would have been returned in the response to a similar
     1021         GET request (without the If-None-Match header) on that resource, or if "*" is given and any current representation exists
     1022         for that resource, then the server <em class="bcp14">MUST NOT</em> perform the requested method, unless required to do so because the resource's modification date fails to match that supplied
     1023         in an If-Modified-Since header field in the request. Instead, if the request method was GET or HEAD, the server <em class="bcp14">SHOULD</em> respond with a 304 (Not Modified) response, including the cache-related header fields (particularly ETag) of one of the representations
    10201024         that matched. For all other request methods, the server <em class="bcp14">MUST</em> respond with a status of 412 (Precondition Failed).
    10211025      </p>
    … …  
    10751079         last modification would indicate some time in the future, the server <em class="bcp14">MUST</em> replace that date with the message origination date.
    10761080      </p>
    1077       <p id="rfc.section.6.6.p.7">An origin server <em class="bcp14">SHOULD</em> obtain the Last-Modified value of the entity as close as possible to the time that it generates the Date value of its response.
    1078          This allows a recipient to make an accurate assessment of the entity's modification time, especially if the entity changes
    1079          near the time that the response is generated.
     1081      <p id="rfc.section.6.6.p.7">An origin server <em class="bcp14">SHOULD</em> obtain the Last-Modified value of the representation as close as possible to the time that it generates the Date value of
     1082         its response. This allows a recipient to make an accurate assessment of the entity's modification time, especially if the
     1083         representation changes near the time that the response is generated.
    10801084      </p>
    10811085      <p id="rfc.section.6.6.p.8">HTTP/1.1 servers <em class="bcp14">SHOULD</em> send Last-Modified whenever feasible.

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

    r863 r868  
    681681         the same entity-body.
    682682      </p>
    683       <p id="rfc.section.4.p.2">If a cache has a stored non-empty set of subranges for an entity, and an incoming response transfers another subrange, the
    684          cache <em class="bcp14">MAY</em> combine the new subrange with the existing set if both the following conditions are met:
     683      <p id="rfc.section.4.p.2">If a cache has a stored non-empty set of subranges for a representation, and an incoming response transfers another subrange,
     684         the cache <em class="bcp14">MAY</em> combine the new subrange with the existing set if both the following conditions are met:
    685685      </p>
    686686      <ul>
    … …  
    695695      <p id="rfc.section.5.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to range requests and partial responses.</p>
    696696      <p id="rfc.section.5.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who
    697          receives the entity.
     697         receives the message.
    698698      </p>
    699699      <div id="rfc.iref.a.1"></div>
    … …  
    747747         selected resource. A response with status code 206 (Partial Content) <em class="bcp14">MUST NOT</em> include a Content-Range field with a byte-range-resp-spec of "*".
    748748      </p>
    749       <p id="rfc.section.5.2.p.7">Examples of byte-content-range-spec values, assuming that the entity contains a total of 1234 bytes: </p>
     749      <p id="rfc.section.5.2.p.7">Examples of byte-content-range-spec values, assuming that the representation contains a total of 1234 bytes: </p>
    750750      <ul>
    751751         <li>The first 500 bytes:
    … …  
    797797      <p id="rfc.section.5.3.p.1">If a client has a partial copy of an entity in its cache, and wishes to have an up-to-date copy of the entire entity in its
    798798         cache, it could use the Range request-header with a conditional GET (using either or both of If-Unmodified-Since and If-Match.)
    799          However, if the condition fails because the entity has been modified, the client would then have to make a second request
    800          to obtain the entire current entity-body.
     799         However, if the condition fails because the representation has been modified, the client would then have to make a second
     800         request to obtain the entire current representation.
    801801      </p>
    802802      <p id="rfc.section.5.3.p.2">The "If-Range" request-header field allows a client to "short-circuit" the second request. Informally, its meaning is "if
    803          the entity is unchanged, send me the part(s) that I am missing; otherwise, send me the entire new entity".
     803         the representation is unchanged, send me the part(s) that I am missing; otherwise, send me the entire new representation".
    804804      </p>
    805805      <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span>  <a href="#header.if-range" class="smpl">If-Range</a>   = "If-Range" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.if-range" class="smpl">If-Range-v</a>
    806806  <a href="#header.if-range" class="smpl">If-Range-v</a> = <a href="#abnf.dependencies" class="smpl">entity-tag</a> / <a href="#abnf.dependencies" class="smpl">HTTP-date</a>
    807 </pre><p id="rfc.section.5.3.p.4">If the client has no entity tag for an entity, but does have a Last-Modified date, it <em class="bcp14">MAY</em> use that date in an If-Range header. (The server can distinguish between a valid HTTP-date and any form of entity-tag by examining
     807</pre><p id="rfc.section.5.3.p.4">If the client has no entity tag for a representation, but does have a Last-Modified date, it <em class="bcp14">MAY</em> use that date in an If-Range header. (The server can distinguish between a valid HTTP-date and any form of entity-tag by examining
    808808         no more than two characters.) The If-Range header <em class="bcp14">SHOULD</em> only be used together with a Range header, and <em class="bcp14">MUST</em> be ignored if the request does not include a Range header, or if the server does not support the sub-range operation.
    809809      </p>
    810       <p id="rfc.section.5.3.p.5">If the entity tag given in the If-Range header matches the current cache validator for the entity, then the server <em class="bcp14">SHOULD</em> provide the specified sub-range of the entity using a 206 (Partial Content) response. If the cache validator does not match,
    811          then the server <em class="bcp14">SHOULD</em> return the entire entity using a 200 (OK) response.
     810      <p id="rfc.section.5.3.p.5">If the entity tag given in the If-Range header matches the current cache validator for the representation, then the server <em class="bcp14">SHOULD</em> provide the specified sub-range of the representation using a 206 (Partial Content) response. If the cache validator does
     811         not match, then the server <em class="bcp14">SHOULD</em> return the entire representation using a 200 (OK) response.
    812812      </p>
    813813      <div id="rfc.iref.r.1"></div>
    … …  
    815815      <h2 id="rfc.section.5.4"><a href="#rfc.section.5.4">5.4</a>&nbsp;<a id="header.range" href="#header.range">Range</a></h2>
    816816      <h3 id="rfc.section.5.4.1"><a href="#rfc.section.5.4.1">5.4.1</a>&nbsp;<a id="byte.ranges" href="#byte.ranges">Byte Ranges</a></h3>
    817       <p id="rfc.section.5.4.1.p.1">Since all HTTP entities are represented in HTTP messages as sequences of bytes, the concept of a byte range is meaningful
    818          for any HTTP entity. (However, not all clients and servers need to support byte-range operations.)
    819       </p>
    820       <p id="rfc.section.5.4.1.p.2">Byte range specifications in HTTP apply to the sequence of bytes in the entity-body (not necessarily the same as the message-body).</p>
     817      <p id="rfc.section.5.4.1.p.1">Since all HTTP representations are transferred as sequences of bytes, the concept of a byte range is meaningful for any HTTP
     818         representation. (However, not all clients and servers need to support byte-range operations.)
     819      </p>
     820      <p id="rfc.section.5.4.1.p.2">Byte range specifications in HTTP apply to the sequence of bytes in the representation body (not necessarily the same as the
     821         message-body).
     822      </p>
    821823      <div id="rule.ranges-specifier">
    822          <p id="rfc.section.5.4.1.p.3">                A byte range operation <em class="bcp14">MAY</em> specify a single range of bytes, or a set of ranges within a single entity.
     824         <p id="rfc.section.5.4.1.p.3">                A byte range operation <em class="bcp14">MAY</em> specify a single range of bytes, or a set of ranges within a single representation.
    823825         </p>
    824826      </div>
    … …  
    835837         recipient of a byte-range-set that includes one or more syntactically invalid byte-range-spec values <em class="bcp14">MUST</em> ignore the header field that includes that byte-range-set.
    836838      </p>
    837       <p id="rfc.section.5.4.1.p.7">If the last-byte-pos value is absent, or if the value is greater than or equal to the current length of the entity-body, last-byte-pos
    838          is taken to be equal to one less than the current length of the entity-body in bytes.
    839       </p>
    840       <p id="rfc.section.5.4.1.p.8">By its choice of last-byte-pos, a client can limit the number of bytes retrieved without knowing the size of the entity.</p>
     839      <p id="rfc.section.5.4.1.p.7">If the last-byte-pos value is absent, or if the value is greater than or equal to the current length of the representation
     840         body, last-byte-pos is taken to be equal to one less than the current length of the representation in bytes.
     841      </p>
     842      <p id="rfc.section.5.4.1.p.8">By its choice of last-byte-pos, a client can limit the number of bytes retrieved without knowing the size of the representation.</p>
    841843      <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span>  <a href="#rule.ranges-specifier" class="smpl">suffix-byte-range-spec</a> = "-" <a href="#rule.ranges-specifier" class="smpl">suffix-length</a>
    842844  <a href="#rule.ranges-specifier" class="smpl">suffix-length</a> = 1*<a href="#notation" class="smpl">DIGIT</a>
    843 </pre><p id="rfc.section.5.4.1.p.10">A suffix-byte-range-spec is used to specify the suffix of the entity-body, of a length given by the suffix-length value. (That
    844          is, this form specifies the last N bytes of an entity-body.) If the entity is shorter than the specified suffix-length, the
    845          entire entity-body is used.
     845</pre><p id="rfc.section.5.4.1.p.10">A suffix-byte-range-spec is used to specify the suffix of the representation body, of a length given by the suffix-length
     846         value. (That is, this form specifies the last N bytes of an entity-body.) If the representation is shorter than the specified
     847         suffix-length, the entire representation is used.
    846848      </p>
    847849      <p id="rfc.section.5.4.1.p.11">If a syntactically valid byte-range-set includes at least one byte-range-spec whose first-byte-pos is less than the current
    848850         length of the entity-body, or at least one suffix-byte-range-spec with a non-zero suffix-length, then the byte-range-set is
    849          satisfiable. Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set is unsatisfiable, the server <em class="bcp14">SHOULD</em> return a response with a status of 416 (Requested range not satisfiable). Otherwise, the server <em class="bcp14">SHOULD</em> return a response with a status of 206 (Partial Content) containing the satisfiable ranges of the entity-body.
     851         satisfiable. Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set is unsatisfiable, the server <em class="bcp14">SHOULD</em> return a response with a status of 416 (Requested range not satisfiable). Otherwise, the server <em class="bcp14">SHOULD</em> return a response with a status of 206 (Partial Content) containing the satisfiable ranges of the representation.
    850852      </p>
    851853      <p id="rfc.section.5.4.1.p.12">Examples of byte-ranges-specifier values (assuming an entity-body of length 10000): </p>
    … …  
    871873      <h3 id="rfc.section.5.4.2"><a href="#rfc.section.5.4.2">5.4.2</a>&nbsp;<a id="range.retrieval.requests" href="#range.retrieval.requests">Range Retrieval Requests</a></h3>
    872874      <p id="rfc.section.5.4.2.p.1">The "Range" request-header field defines the GET method (conditional or not) to request one or more sub-ranges of the response
    873          entity-body, instead of the entire entity body.
     875         representation body, instead of the entire representation body.
    874876      </p>
    875877      <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.23"></span>  <a href="#range.retrieval.requests" class="smpl">Range</a>   = "Range" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#range.retrieval.requests" class="smpl">Range-v</a>
    … …  
    11391141</pre> <p id="rfc.section.A.p.7">Notes: </p>
    11401142      <ol>
    1141          <li>Additional CRLFs may precede the first boundary string in the entity.</li>
     1143         <li>Additional CRLFs may precede the first boundary string in the body.</li>
    11421144         <li>Although <a href="#RFC2046" id="rfc.xref.RFC2046.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> permits the boundary string to be quoted, some existing implementations handle a quoted boundary string incorrectly.
    11431145         </li>

  • draft-ietf-httpbis/latest/p6-cache.html

    r865 r868  
    680680      </p>
    681681      <ul class="empty">
    682          <li>A protocol element (e.g., an entity tag or a Last-Modified time) that is used to find out whether a stored response is an
    683             equivalent copy of an entity.
     682         <li>A protocol element (e.g., an entity tag or a Last-Modified time) that is used to find out whether a stored response has an
     683            equivalent copy of a representation.
    684684         </li>
    685685      </ul>
    … …  
    799799      </p>
    800800      <p id="rfc.section.2.3.p.2">The primary mechanism for determining freshness is for an origin server to provide an explicit expiration time in the future,
    801          using either the Expires header (<a href="#header.expires" id="rfc.xref.header.expires.2" title="Expires">Section&nbsp;3.3</a>) or the max-age response cache directive (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>). Generally, origin servers will assign future explicit expiration times to responses in the belief that the entity is not
    802          likely to change in a semantically significant way before the expiration time is reached.
     801         using either the Expires header (<a href="#header.expires" id="rfc.xref.header.expires.2" title="Expires">Section&nbsp;3.3</a>) or the max-age response cache directive (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>). Generally, origin servers will assign future explicit expiration times to responses in the belief that the representation
     802         is not likely to change in a semantically significant way before the expiration time is reached.
    803803      </p>
    804804      <p id="rfc.section.2.3.p.3">If an origin server wishes to force a cache to validate every request, it can assign an explicit expiration time in the past.
    … …  
    10251025      <p id="rfc.section.3.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to caching.</p>
    10261026      <p id="rfc.section.3.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who
    1027          receives the entity.
     1027         receives the message.
    10281028      </p>
    10291029      <div id="rfc.iref.a.2"></div>
    … …  
    11961196            an HTTP/1.1 cache <em class="bcp14">MUST</em> obey the must-revalidate directive; in particular, if the cache cannot reach the origin server for any reason, it <em class="bcp14">MUST</em> generate a 504 (Gateway Timeout) response.
    11971197         </li>
    1198          <li>Servers <em class="bcp14">SHOULD</em> send the must-revalidate directive if and only if failure to validate a request on the entity could result in incorrect operation,
    1199             such as a silently unexecuted financial transaction.
     1198         <li>Servers <em class="bcp14">SHOULD</em> send the must-revalidate directive if and only if failure to validate a request on the representation could result in incorrect
     1199            operation, such as a silently unexecuted financial transaction.
    12001200         </li>
    12011201      </ul>
    … …  
    13361336      <p id="rfc.section.3.6.p.1">The "Warning" general-header field is used to carry additional information about the status or transformation of a message
    13371337         that might not be reflected in the message. This information is typically used to warn about possible incorrectness introduced
    1338          by caching operations or transformations applied to the entity body of the message.
     1338         by caching operations or transformations applied to the payload of the message.
    13391339      </p>
    13401340      <p id="rfc.section.3.6.p.2">Warnings can be used for other purposes, both cache-related and otherwise. The use of a warning, rather than an error status
    … …  
    13691369         <li>1xx Warnings describe the freshness or validation status of the response, and so <em class="bcp14">MUST</em> be deleted by caches after validation. They can only be generated by a cache when validating a cached entry, and <em class="bcp14">MUST NOT</em> be generated in any other situation.
    13701370         </li>
    1371          <li>2xx Warnings describe some aspect of the entity body or entity headers that is not rectified by a validation (for example,
    1372             a lossy compression of the entity bodies) and <em class="bcp14">MUST NOT</em> be deleted by caches after validation, unless a full response is returned, in which case they <em class="bcp14">MUST</em> be.
     1371         <li>2xx Warnings describe some aspect of the representation that is not rectified by a validation (for example, a lossy compression
     1372            of the representation) and <em class="bcp14">MUST NOT</em> be deleted by caches after validation, unless a full response is returned, in which case they <em class="bcp14">MUST</em> be.
    13731373         </li>
    13741374      </ul>
Note: See TracChangeset for help on using the changeset viewer.