Ignore:
Timestamp:
Jul 22, 2010, 2:10:39 AM (9 years ago)
Author:
fielding@…
Message:

regenerate html

File:
1 edited

Legend:

Unmodified
Added
Removed
  • 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>
Note: See TracChangeset for help on using the changeset viewer.