Changeset 868 for draft-ietf-httpbis/latest
- Timestamp:
- 22/07/10 09:10:39 (12 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 6 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r865 r868 1978 1978 <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> 1979 1979 <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. 1981 1981 </p> 1982 1982 <div id="rfc.iref.c.11"></div> … … 2172 2172 </p> 2173 2173 <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 a n 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. 2175 2175 </p> 2176 2176 <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 380 380 <link rel="Chapter" title="4 Status Code and Reason Phrase" href="#rfc.section.4"> 381 381 <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"> 383 383 <link rel="Chapter" title="7 Method Definitions" href="#rfc.section.7"> 384 384 <link rel="Chapter" title="8 Status Code Definitions" href="#rfc.section.8"> … … 551 551 </li> 552 552 <li class="tocline0">5. <a href="#response.header.fields">Response Header Fields</a></li> 553 <li class="tocline0">6. <a href="#entity"> Entity</a><ul class="toc">553 <li class="tocline0">6. <a href="#entity">Representation</a><ul class="toc"> 554 554 <li class="tocline1">6.1 <a href="#identifying.response.associated.with.representation">Identifying the Resource Associated with a Representation</a></li> 555 555 </ul> … … 875 875 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 876 876 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 information878 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. 879 879 </p> 880 880 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="status.code.registry" href="#status.code.registry">Status Code Registry</a></h2> … … 903 903 fields. Unrecognized header fields are treated as entity-header fields. 904 904 </p> 905 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <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 a n entity if not otherwise restricted by the request method or response status code. An entity consists of entity-header907 fields and an entity-body, although some responses will only include the entity-headers. HTTP entity-body and entity-header908 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">A n 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 ensure911 safe and proper transfer of the message.905 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <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. 912 912 </p> 913 913 <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="identifying.response.associated.with.representation" href="#identifying.response.associated.with.representation">Identifying the Resource Associated with a Representation</a></h2> … … 994 994 by the Effective Request URI. 995 995 </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 entity996 <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 997 997 in the response and not the source text of the process, unless that text happens to be the output of the process. 998 998 </p> 999 999 <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 under1001 the circumstances described by the conditional header field(s). The conditional GET method is intended to reduce unnecessary1002 network usage by allowing cached entities to be refreshed without requiring multiple requests or transferring data already1003 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. 1004 1004 </p> 1005 1005 <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 completed1007 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. 1008 1008 </p> 1009 1009 <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>. … … 1014 1014 <div id="rfc.iref.h.1"></div> 1015 1015 <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 meta information 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 about1017 the entity implied by the request without transferring the entity-body itself. This method is often used for testing hypertext1018 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. 1019 1019 </p> 1020 1020 <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 … … 1051 1051 <div id="rfc.iref.m.5"></div> 1052 1052 <h2 id="rfc.section.7.6"><a href="#rfc.section.7.6">7.6</a> <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 refers1054 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 does1055 not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent,1056 theorigin 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. 1057 1057 </p> 1058 1058 <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 1059 1059 Content) response codes <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request. 1060 1060 </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. 1065 1064 </p> 1066 1065 <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, 1070 1070 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. 1071 1071 </p> … … 1086 1086 </p> 1087 1087 <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 a n entity.1088 or 204 (No Content) if the action has been enacted but the response does not include a representation. 1089 1089 </p> 1090 1090 <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 … … 1096 1096 <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 1097 1097 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 9.5</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a n 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 9.5</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message-body. 1099 1099 </p> 1100 1100 <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 … … 1112 1112 </p> 1113 1113 <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <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 meta informationrequired 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> 1115 1115 <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a> <a id="status.1xx" href="#status.1xx">Informational 1xx</a></h2> 1116 1116 <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 … … 1181 1181 <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 1182 1182 (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 entityreturned 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 the1183 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 1184 1184 user can expect the request to be fulfilled. 1185 1185 </p> … … 1187 1187 <div id="rfc.iref.s.7"></div> 1188 1188 <h3 id="rfc.section.8.2.4"><a href="#rfc.section.8.2.4">8.2.4</a> <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 meta informationin the entity-header is not the definitive set as available from the origin server, but is gathered1189 <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 1190 1190 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 meta information known by the origin server. Use of this response code is not required and is only1192 appropriatewhen 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). 1193 1193 </p> 1194 1194 <div id="rfc.iref.31"></div> … … 1211 1211 <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 1212 1212 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 a n entity.1213 another input action. The response <em class="bcp14">MUST NOT</em> include a message-body. 1214 1214 </p> 1215 1215 <div id="rfc.iref.33"></div> … … 1235 1235 location. 1236 1236 </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 a n entity containing a list of resource characteristics and location(s) from which the user or user agent can choose1238 the one most appropriate. The entityformat is specified by the media type given in the Content-Type header field. Depending1237 <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 1239 1239 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. 1240 1240 </p> … … 1248 1248 indicated otherwise. 1249 1249 </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 entityof 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). 1251 1251 </p> 1252 1252 <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 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 … … 1265 1265 or Expires header field. 1266 1266 </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 entityof 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). 1268 1268 </p> 1269 1269 <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 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 … … 1295 1295 </p> 1296 1296 <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 entityof 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. 1298 1298 </p> 1299 1299 <div id="rfc.iref.38"></div> … … 1318 1318 or Expires header field. 1319 1319 </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 entityof 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 understand1320 <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 1321 1321 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. 1322 1322 </p> … … 1352 1352 <h3 id="rfc.section.8.4.4"><a href="#rfc.section.8.4.4">8.4.4</a> <a id="status.403" href="#status.403">403 Forbidden</a></h3> 1353 1353 <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 t he 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. 1356 1356 </p> 1357 1357 <div id="rfc.iref.46"></div> … … 1374 1374 not acceptable according to the accept headers sent in the request. 1375 1375 </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 a n entity containing a list of available entity characteristics and location(s) from which the user or user agent1377 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. 1379 1379 </p> 1380 1380 <div class="note" id="rfc.section.8.4.7.p.3"> … … 1404 1404 enough information for the user or user agent to fix the problem; however, that might not be possible and is not required. 1405 1405 </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 entity1406 <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 1407 1407 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 contain1409 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. 1410 1410 </p> 1411 1411 <div id="rfc.iref.52"></div> … … 1454 1454 <div id="rfc.iref.s.34"></div> 1455 1455 <h3 id="rfc.section.8.4.16"><a href="#rfc.section.8.4.16">8.4.16</a> <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 requested1457 re source 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. 1458 1458 </p> 1459 1459 <div id="rfc.iref.58"></div> … … 1520 1520 <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> 1521 1521 <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. 1523 1523 </p> 1524 1524 <div id="rfc.iref.a.1"></div> … … 1611 1611 </div> 1612 1612 <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. 1614 1614 It is therefore possible for a response to contain header fields for both Location and Content-Location. 1615 1615 </p> … … 2119 2119 has no better mechanism. 2120 2120 </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 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 collect2121 <p id="rfc.section.11.1.p.8">Some methods, like TRACE (<a href="#TRACE" id="rfc.xref.TRACE.4" title="TRACE">Section 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 2122 2122 data from the client. 2123 2123 </p> -
draft-ietf-httpbis/latest/p3-payload.html
r865 r868 742 742 </p> 743 743 <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> <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 a n entity. Content codings are745 primarily used to allow a document to be compressed or otherwise usefully transformed without losing the identity of its underlying746 media type and without loss of information. Frequently, the entity is stored in coded form, transmitted directly, and only747 d ecoded 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. 748 748 </p> 749 749 <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> … … 867 867 </p> 868 868 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <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 a n entity if not otherwise restricted by the request method or response status code. An entity consists of entity-header870 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. 871 871 </p> 872 872 <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. 874 874 </p> 875 875 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <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 meta information about the entity-body or, if no body is present, about the resource identified877 by therequest.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. 878 878 </p> 879 879 <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 5.5</a> … … 996 996 <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> 997 997 <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. 999 999 </p> 1000 1000 <div id="rfc.iref.a.1"></div> … … 1042 1042 text/x-dvi; q=0.8, text/x-c 1043 1043 </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." 1045 1045 </p> 1046 1046 <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 … … 1214 1214 <div id="rfc.iref.h.5"></div> 1215 1215 <h2 id="rfc.section.5.5"><a href="#rfc.section.5.5">5.5</a> <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 what1217 decoding mechanisms must be applied in order to obtain the media-type referenced by the Content-Type header field. Content-Encoding1218 is primarily used to allow a documentto 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. 1219 1219 </p> 1220 1220 <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> … … 1223 1223 </p> 1224 1224 <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-control1225 </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 1227 1227 directive is present in the message. 1228 1228 </p> 1229 <p id="rfc.section.5.5.p.6">If the content-coding of a n 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 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 5.5</a>) that lists the non-identity content-coding(s) used. 1230 1230 </p> 1231 1231 <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). 1232 1232 </p> 1233 <p id="rfc.section.5.5.p.8">If multiple encodings have been applied to a n 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. 1234 1234 </p> 1235 1235 <div id="rfc.iref.c.8"></div> 1236 1236 <div id="rfc.iref.h.6"></div> 1237 1237 <h2 id="rfc.section.5.6"><a href="#rfc.section.5.6">5.6</a> <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. Note1239 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. 1240 1240 </p> 1241 1241 <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> 1242 1242 <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 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 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 1245 1246 </p> 1246 1247 <div id="rfc.figure.u.29"></div><pre class="text"> Content-Language: da … … 1253 1254 </p> 1254 1255 <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 a n entity does not mean that it is intended for multiple linguistic1256 audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin," which is clearly intended1257 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". 1258 1259 </p> 1259 1260 <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. … … 1270 1271 <a href="#header.content-location" class="smpl">Content-Location-v</a> = 1271 1272 <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.2 2"><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 MIME1273 </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 1273 1274 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. 1274 1275 </p> … … 1317 1318 <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 1318 1319 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. 1320 1321 </p> 1321 1322 <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 … … 1470 1471 <td class="left">compress</td> 1471 1472 <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.2 3"><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> 1473 1474 </td> 1474 1475 </tr> … … 1477 1478 <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>) 1478 1479 </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.2 4"><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> 1480 1481 </td> 1481 1482 </tr> … … 1483 1484 <td class="left">gzip</td> 1484 1485 <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.2 5"><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> 1486 1487 </td> 1487 1488 </tr> … … 1750 1751 </p> 1751 1752 <h2 id="rfc.section.A.3"><a href="#rfc.section.A.3">A.3</a> <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.2 6"><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. 1753 1754 </p> 1754 1755 <h2 id="rfc.section.A.4"><a href="#rfc.section.A.4">A.4</a> <a id="introduction.of.content-encoding" href="#introduction.of.content-encoding">Introduction of Content-Encoding</a></h2> … … 1767 1768 </p> 1768 1769 <h2 id="rfc.section.A.6"><a href="#rfc.section.A.6">A.6</a> <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.2 7"><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. 1770 1771 </p> 1771 1772 <h2 id="rfc.section.A.7"><a href="#rfc.section.A.7">A.7</a> <a id="mhtml.line.length" href="#mhtml.line.length">MHTML and Line Length Limitations</a></h2> … … 2227 2228 </li> 2228 2229 <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> <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> <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"> 2230 2231 <li class="indline1"><em>Section 1.2</em> <a class="iref" href="#rfc.xref.Part1.1">1.3</a></li> 2231 2232 <li class="indline1"><em>Section 1.2.2</em> <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> … … 2233 2234 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.Part1.9">1.3.2</a></li> 2234 2235 <li class="indline1"><em>Section 3.3</em> <a class="iref" href="#rfc.xref.Part1.18">3.2</a></li> 2235 <li class="indline1"><em>Section 4.3</em> <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> <a class="iref" href="#rfc.xref.Part1.2 6">A.3</a></li>2236 <li class="indline1"><em>Section 4.3</em> <a class="iref" href="#rfc.xref.Part1.21">5.7</a></li> 2237 <li class="indline1"><em>Section 6.1</em> <a class="iref" href="#rfc.xref.Part1.25">A.3</a></li> 2237 2238 <li class="indline1"><em>Section 6.2</em> <a class="iref" href="#rfc.xref.Part1.15">2.2.1</a></li> 2238 <li class="indline1"><em>Section 6.2.2.1</em> <a class="iref" href="#rfc.xref.Part1.12">2.2</a>, <a class="iref" href="#rfc.xref.Part1.2 3">6.2</a></li>2239 <li class="indline1"><em>Section 6.2.2.1</em> <a class="iref" href="#rfc.xref.Part1.12">2.2</a>, <a class="iref" href="#rfc.xref.Part1.22">6.2</a></li> 2239 2240 <li class="indline1"><em>Section 6.2.2</em> <a class="iref" href="#rfc.xref.Part1.16">2.2.1</a></li> 2240 <li class="indline1"><em>Section 6.2.2.2</em> <a class="iref" href="#rfc.xref.Part1.13">2.2</a>, <a class="iref" href="#rfc.xref.Part1.2 4">6.2</a></li>2241 <li class="indline1"><em>Section 6.2.2.3</em> <a class="iref" href="#rfc.xref.Part1.14">2.2</a>, <a class="iref" href="#rfc.xref.Part1.2 5">6.2</a></li>2241 <li class="indline1"><em>Section 6.2.2.2</em> <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> <a class="iref" href="#rfc.xref.Part1.14">2.2</a>, <a class="iref" href="#rfc.xref.Part1.24">6.2</a></li> 2242 2243 <li class="indline1"><em>Section 6.4</em> <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> 2243 2244 <li class="indline1"><em>Section 9.2</em> <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> <a class="iref" href="#rfc.xref.Part1.2 7">A.6</a></li>2245 <li class="indline1"><em>Section 9.7</em> <a class="iref" href="#rfc.xref.Part1.26">A.6</a></li> 2245 2246 </ul> 2246 2247 </li> -
draft-ietf-httpbis/latest/p4-conditional.html
r863 r868 704 704 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="status.412" href="#status.412">412 Precondition Failed</a></h2> 705 705 <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 meta information (header field data) and thus707 preventthe 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. 708 708 </p> 709 709 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <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." 713 714 </p> 714 715 <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 is716 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." 717 718 </p> 718 719 <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. 722 724 </p> 723 725 <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 a n entityis changed.725 </li> 726 <li>An entity's modification time, if represented withone-second resolution, could be a weak validator, since it is possible727 that the re sourcemight 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. 728 730 </li> 729 731 <li>Support for weak validators is optional. However, weak validators allow for more efficient caching of equivalent objects; … … 736 738 </p> 737 739 <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 a n entity. For example, either kind is usable for a conditional GET of a full entity. However, only a strong validator739 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. 740 742 </p> 741 743 <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>). … … 795 797 </p> 796 798 <ul> 797 <li>The validator is being compared by an origin server to the actual current validator for the entityand,</li>798 <li>That origin server reliably knows that the associated entity did not change twice during the second covered by the presented799 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. 800 802 </li> 801 803 </ul> … … 803 805 <ul> 804 806 <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, and807 a cache entry for the associated representation, and 806 808 </li> 807 809 <li>That cache entry includes a Date value, which gives the time when the origin server sent the original response, and</li> … … 810 812 <p id="rfc.section.4.p.12">or </p> 811 813 <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> 813 817 <li>That cache entry includes a Date value, which gives the time when the origin server sent the original response, and</li> 814 818 <li>The presented Last-Modified time is at least 60 seconds before the Date value.</li> … … 892 896 <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> 893 897 <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. 895 899 </p> 896 900 <div id="rfc.iref.e.1"></div> … … 929 933 <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> 930 934 <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 GET932 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, 933 937 then the server <em class="bcp14">MAY</em> perform the requested method as if the If-Match header field did not exist. 934 938 </p> 935 <p id="rfc.section.6.2.p.5">If none of the entity tags match, or if "*" is given and no current entityexists, 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, 936 940 such as PUT, from modifying a resource that has changed since the client last retrieved it. 937 941 </p> … … 941 945 <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. 942 946 </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 without945 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: 946 950 </p> 947 951 <div id="rfc.figure.u.10"></div><pre class="text"> If-Match: "xyzzy" … … 1014 1018 <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> 1015 1019 <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 GET1017 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 supplied1019 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 entities1020 </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 1020 1024 that matched. For all other request methods, the server <em class="bcp14">MUST</em> respond with a status of 412 (Precondition Failed). 1021 1025 </p> … … 1075 1079 last modification would indicate some time in the future, the server <em class="bcp14">MUST</em> replace that date with the message origination date. 1076 1080 </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 changes1079 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. 1080 1084 </p> 1081 1085 <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 681 681 the same entity-body. 682 682 </p> 683 <p id="rfc.section.4.p.2">If a cache has a stored non-empty set of subranges for a n entity, and an incoming response transfers another subrange, the684 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: 685 685 </p> 686 686 <ul> … … 695 695 <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> 696 696 <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. 698 698 </p> 699 699 <div id="rfc.iref.a.1"></div> … … 747 747 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 "*". 748 748 </p> 749 <p id="rfc.section.5.2.p.7">Examples of byte-content-range-spec values, assuming that the entitycontains 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> 750 750 <ul> 751 751 <li>The first 500 bytes: … … 797 797 <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 798 798 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 request800 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. 801 801 </p> 802 802 <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". 804 804 </p> 805 805 <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> 806 806 <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 a n 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 examining807 </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 808 808 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. 809 809 </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 entityusing 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. 812 812 </p> 813 813 <div id="rfc.iref.r.1"></div> … … 815 815 <h2 id="rfc.section.5.4"><a href="#rfc.section.5.4">5.4</a> <a id="header.range" href="#header.range">Range</a></h2> 816 816 <h3 id="rfc.section.5.4.1"><a href="#rfc.section.5.4.1">5.4.1</a> <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> 821 823 <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. 823 825 </p> 824 826 </div> … … 835 837 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. 836 838 </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-pos838 is taken to be equal to one less than the current length of the entity-bodyin 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> 841 843 <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> 842 844 <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. (That844 is, this form specifies the last N bytes of an entity-body.) If the entity is shorter than the specified suffix-length, the845 entire entity-bodyis 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. 846 848 </p> 847 849 <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 848 850 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. 850 852 </p> 851 853 <p id="rfc.section.5.4.1.p.12">Examples of byte-ranges-specifier values (assuming an entity-body of length 10000): </p> … … 871 873 <h3 id="rfc.section.5.4.2"><a href="#rfc.section.5.4.2">5.4.2</a> <a id="range.retrieval.requests" href="#range.retrieval.requests">Range Retrieval Requests</a></h3> 872 874 <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 entitybody.875 representation body, instead of the entire representation body. 874 876 </p> 875 877 <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> … … 1139 1141 </pre> <p id="rfc.section.A.p.7">Notes: </p> 1140 1142 <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> 1142 1144 <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. 1143 1145 </li> -
draft-ietf-httpbis/latest/p6-cache.html
r865 r868 680 680 </p> 681 681 <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 an683 equivalent copy of a n 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. 684 684 </li> 685 685 </ul> … … 799 799 </p> 800 800 <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 3.3</a>) or the max-age response cache directive (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section 3.2.2</a>). Generally, origin servers will assign future explicit expiration times to responses in the belief that the entity is not802 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 3.3</a>) or the max-age response cache directive (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section 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. 803 803 </p> 804 804 <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. … … 1025 1025 <p id="rfc.section.3.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to caching.</p> 1026 1026 <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. 1028 1028 </p> 1029 1029 <div id="rfc.iref.a.2"></div> … … 1196 1196 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. 1197 1197 </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. 1200 1200 </li> 1201 1201 </ul> … … 1336 1336 <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 1337 1337 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 bodyof the message.1338 by caching operations or transformations applied to the payload of the message. 1339 1339 </p> 1340 1340 <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 … … 1369 1369 <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. 1370 1370 </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. 1373 1373 </li> 1374 1374 </ul>
Note: See TracChangeset
for help on using the changeset viewer.