Changeset 875 for draft-ietf-httpbis/latest
- Timestamp:
- 23/07/10 05:43:59 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 7 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r873 r875 711 711 MIME-like message payloads for flexible interaction with network-based hypertext information systems. HTTP relies upon the 712 712 Uniform Resource Identifier (URI) standard <a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> to indicate request targets and relationships between resources. Messages are passed in a format similar to that used by Internet 713 mail <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a> and the Multipurpose Internet Mail Extensions (MIME) <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> (see <a href="p3-payload.html#differences.between.http. entities.and.rfc.2045.entities" title="Differences Between HTTP Entities and RFC 2045 Entities">Appendix A</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> for the differences between HTTP and MIME messages).713 mail <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a> and the Multipurpose Internet Mail Extensions (MIME) <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> (see <a href="p3-payload.html#differences.between.http.and.mime" title="Differences between HTTP and MIME">Appendix A</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> for the differences between HTTP and MIME messages). 714 714 </p> 715 715 <p id="rfc.section.1.p.2">HTTP is a generic interface protocol for information systems. It is designed to hide the details of how a service is implemented -
draft-ietf-httpbis/latest/p2-semantics.html
r868 r875 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">Representation</a><ul class="toc">553 <li class="tocline0">6. <a href="#representation">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> … … 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">Representation</a></h1>905 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="representation" href="#representation">Representation</a></h1> 906 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 907 of metadata (representation header fields) and data (representation body). When a complete or partial representation is enclosed … … 968 968 </p> 969 969 <p id="rfc.section.7.2.p.2">Responses to this method are not cacheable.</p> 970 <p id="rfc.section.7.2.p.3">If the OPTIONS request includes a n entity-body (as indicated by the presence of Content-Length or Transfer-Encoding), then970 <p id="rfc.section.7.2.p.3">If the OPTIONS request includes a message-body (as indicated by the presence of Content-Length or Transfer-Encoding), then 971 971 the media type <em class="bcp14">MUST</em> be indicated by a Content-Type field. Although this specification does not define any use for such a body, future extensions 972 972 to HTTP might use the OPTIONS body to make more detailed queries on the server. … … 991 991 <div id="rfc.iref.g.8"></div> 992 992 <div id="rfc.iref.m.2"></div> 993 <p id="rfc.section.7.3.p.1">The GET method means retrieve whatever information (in the form of a n entity) currently corresponds to the resource identified994 by the Effective Request URI.993 <p id="rfc.section.7.3.p.1">The GET method means retrieve whatever information (in the form of a representation) currently corresponds to the resource 994 identified by the Effective Request URI. 995 995 </p> 996 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 … … 1000 1000 If-Match, If-None-Match, or If-Range header field. A conditional GET method requests that the representation be transferred 1001 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 transferring1002 unnecessary network usage by allowing cached representations to be refreshed without requiring multiple requests or transferring 1003 1003 data already held by the client. 1004 1004 </p> … … 1018 1018 hypertext links for validity, accessibility, and recent modification. 1019 1019 </p> 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 differs1021 from the current entity (as would be indicated by a change in Content-Length, Content-MD5, ETag or Last-Modified), then the1022 cache <em class="bcp14">MUST</em> treat the cache entry as stale.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 representation from that resource. If the new field values indicate that the cached 1021 representation differs from the current representation (as would be indicated by a change in Content-Length, Content-MD5, 1022 ETag or Last-Modified), then the cache <em class="bcp14">MUST</em> treat the cache entry as stale. 1023 1023 </p> 1024 1024 <div id="rfc.iref.p.1"></div> 1025 1025 <div id="rfc.iref.m.4"></div> 1026 1026 <h2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a> <a id="POST" href="#POST">POST</a></h2> 1027 <p id="rfc.section.7.5.p.1">The POST method is used to request that the origin server accept the entity enclosed in the request as data to be processed1028 by the resource identified by the Effective Request URI. POST is designed to allow a uniform method to cover the following1029 f unctions:1027 <p id="rfc.section.7.5.p.1">The POST method is used to request that the origin server accept the representation enclosed in the request as data to be 1028 processed by the resource identified by the Effective Request URI. POST is designed to allow a uniform method to cover the 1029 following functions: 1030 1030 </p> 1031 1031 <ul> … … 1039 1039 </p> 1040 1040 <p id="rfc.section.7.5.p.3">The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 1041 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes a n entity1041 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes a representation 1042 1042 that describes the result. 1043 1043 </p> 1044 <p id="rfc.section.7.5.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be 201 (Created) and contain a n entity which describes the status of the request and refers to the new resource, and a Location1045 header (see <a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section 9.4</a>).1044 <p id="rfc.section.7.5.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be 201 (Created) and contain a representation which describes the status of the request and refers to the new resource, and 1045 a Location header (see <a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section 9.4</a>). 1046 1046 </p> 1047 1047 <p id="rfc.section.7.5.p.5">Responses to this method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields. … … 1085 1085 location. 1086 1086 </p> 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 representation.1089 </p> 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, those1091 entries <em class="bcp14">SHOULD</em> be treated as stale. Responses to this method are not cacheable.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 representation describing the status, 202 (Accepted) if the action has not yet been 1088 enacted, or 204 (No Content) if the action has been enacted but the response does not include a representation. 1089 </p> 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 representations, 1091 those entries <em class="bcp14">SHOULD</em> be treated as stale. Responses to the DELETE method <em class="bcp14">MUST NOT</em> be cached. 1092 1092 </p> 1093 1093 <h2 id="rfc.section.7.8"><a href="#rfc.section.7.8">7.8</a> <a id="TRACE" href="#TRACE">TRACE</a></h2> … … 1095 1095 <div id="rfc.iref.m.7"></div> 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 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 the1098 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.1097 request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the message-body of a 200 (OK) response. The final recipient is either 1098 the 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 … … 1103 1103 infinite loop. 1104 1104 </p> 1105 <p id="rfc.section.7.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> contain the entire request message in the entity-body, with a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 10.3.1</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>). Responses to thismethod <em class="bcp14">MUST NOT</em> be cached.1105 <p id="rfc.section.7.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 10.3.1</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>) and contain a message-body that encloses a copy of the entire request message. Responses to the TRACE method <em class="bcp14">MUST NOT</em> be cached. 1106 1106 </p> 1107 1107 <div id="rfc.iref.c.1"></div> … … 1152 1152 <dl> 1153 1153 <dt>GET</dt> 1154 <dd>a n entitycorresponding to the requested resource is sent in the response;</dd>1154 <dd>a representation corresponding to the requested resource is sent in the response;</dd> 1155 1155 <dt>HEAD</dt> 1156 1156 <dd>the entity-header fields corresponding to the requested resource are sent in the response without any message-body;</dd> 1157 1157 <dt>POST</dt> 1158 <dd>a n entitydescribing or containing the result of the action;</dd>1158 <dd>a representation describing or containing the result of the action;</dd> 1159 1159 <dt>TRACE</dt> 1160 <dd>a n entitycontaining the request message as received by the end server.</dd>1160 <dd>a representation containing the request message as received by the end server.</dd> 1161 1161 </dl> 1162 1162 <div id="rfc.iref.28"></div> … … 1169 1169 server <em class="bcp14">MUST</em> create the resource before returning the 201 status code. If the action cannot be carried out immediately, the server <em class="bcp14">SHOULD</em> respond with 202 (Accepted) response instead. 1170 1170 </p> 1171 <p id="rfc.section.8.2.2.p.2">A 201 response <em class="bcp14">MAY</em> contain an ETag response header field indicating the current value of the entity 1171 <p id="rfc.section.8.2.2.p.2">A 201 response <em class="bcp14">MAY</em> contain an ETag response header field indicating the current value of the entity-tag for the representation of the resource 1172 1172 just created (see <a href="p4-conditional.html#header.etag" title="ETag">Section 6.1</a> of <a href="#Part4" id="rfc.xref.Part4.14"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). 1173 1173 </p> … … 1216 1216 <div id="rfc.iref.s.10"></div> 1217 1217 <h3 id="rfc.section.8.2.7"><a href="#rfc.section.8.2.7">8.2.7</a> <a id="status.206" href="#status.206">206 Partial Content</a></h3> 1218 <p id="rfc.section.8.2.7.p.1">The server has fulfilled the partial GET request for the resource and the enclosed entity is a partial representation as defined1219 in <a href="p5-range.html#status.206" title="206 Partial Content">Section 3.1</a> of <a href="#Part5" id="rfc.xref.Part5.11"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>.1218 <p id="rfc.section.8.2.7.p.1">The server has fulfilled the partial GET request for the resource and the enclosed payload is a partial representation as 1219 defined in <a href="p5-range.html#status.206" title="206 Partial Content">Section 3.1</a> of <a href="#Part5" id="rfc.xref.Part5.11"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. 1220 1220 </p> 1221 1221 <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a> <a id="status.3xx" href="#status.3xx">Redirection 3xx</a></h2> … … 1326 1326 <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a> <a id="status.4xx" href="#status.4xx">Client Error 4xx</a></h2> 1327 1327 <p id="rfc.section.8.4.p.1">The 4xx class of status code is intended for cases in which the client seems to have erred. Except when responding to a HEAD 1328 request, the server <em class="bcp14">SHOULD</em> include a n entitycontaining an explanation of the error situation, and whether it is a temporary or permanent condition.1329 These status codes are applicable to any request method. User agents <em class="bcp14">SHOULD</em> display any included entityto the user.1328 request, the server <em class="bcp14">SHOULD</em> include a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition. 1329 These status codes are applicable to any request method. User agents <em class="bcp14">SHOULD</em> display any included representation to the user. 1330 1330 </p> 1331 1331 <p id="rfc.section.8.4.p.2">If the client is sending data, a server implementation using TCP <em class="bcp14">SHOULD</em> be careful to ensure that the client acknowledges receipt of the packet(s) containing the response, before the server closes … … 1371 1371 <div id="rfc.iref.s.25"></div> 1372 1372 <h3 id="rfc.section.8.4.7"><a href="#rfc.section.8.4.7">8.4.7</a> <a id="status.406" href="#status.406">406 Not Acceptable</a></h3> 1373 <p id="rfc.section.8.4.7.p.1">The resource identified by the request is only capable of generating response entities which have content characteristics1373 <p id="rfc.section.8.4.7.p.1">The resource identified by the request is only capable of generating response representations which have content characteristics 1374 1374 not acceptable according to the accept headers sent in the request. 1375 1375 </p> … … 1401 1401 <p id="rfc.section.8.4.10.p.1">The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in 1402 1402 situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response 1403 body <em class="bcp14">SHOULD</em> include enough information for the user to recognize the source of the conflict. Ideally, the response entity would include1404 enough information for the user or user agent to fix the problem; however, that might not be possible and is not required.1403 body <em class="bcp14">SHOULD</em> include enough information for the user to recognize the source of the conflict. Ideally, the response representation would 1404 include 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 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 … … 1437 1437 <div id="rfc.iref.s.32"></div> 1438 1438 <h3 id="rfc.section.8.4.14"><a href="#rfc.section.8.4.14">8.4.14</a> <a id="status.413" href="#status.413">413 Request Entity Too Large</a></h3> 1439 <p id="rfc.section.8.4.14.p.1">The server is refusing to process a request because the request entity is larger than the server is willing or able to process.1440 The server <em class="bcp14">MAY</em> close the connection to prevent the client from continuing the request.1439 <p id="rfc.section.8.4.14.p.1">The server is refusing to process a request because the request representation is larger than the server is willing or able 1440 to process. The server <em class="bcp14">MAY</em> close the connection to prevent the client from continuing the request. 1441 1441 </p> 1442 1442 <p id="rfc.section.8.4.14.p.2">If the condition is temporary, the server <em class="bcp14">SHOULD</em> include a Retry-After header field to indicate that it is temporary and after what time the client <em class="bcp14">MAY</em> try again. … … 1470 1470 <h2 id="rfc.section.8.5"><a href="#rfc.section.8.5">8.5</a> <a id="status.5xx" href="#status.5xx">Server Error 5xx</a></h2> 1471 1471 <p id="rfc.section.8.5.p.1">Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable 1472 of performing the request. Except when responding to a HEAD request, the server <em class="bcp14">SHOULD</em> include a n entitycontaining an explanation of the error situation, and whether it is a temporary or permanent condition.1473 User agents <em class="bcp14">SHOULD</em> display any included entityto the user. These response codes are applicable to any request method.1472 of performing the request. Except when responding to a HEAD request, the server <em class="bcp14">SHOULD</em> include a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition. 1473 User agents <em class="bcp14">SHOULD</em> display any included representation to the user. These response codes are applicable to any request method. 1474 1474 </p> 1475 1475 <div id="rfc.iref.60"></div> … … 1515 1515 <p id="rfc.section.8.5.6.p.1">The server does not support, or refuses to support, the protocol version that was used in the request message. The server 1516 1516 is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described 1517 in <a href="p1-messaging.html#http.version" title="HTTP Version">Section 2.5</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain a n entitydescribing why that version is not supported and what other protocols are supported by that server.1517 in <a href="p1-messaging.html#http.version" title="HTTP Version">Section 2.5</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain a representation describing why that version is not supported and what other protocols are supported by that server. 1518 1518 </p> 1519 1519 <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> -
draft-ietf-httpbis/latest/p3-payload.html
r868 r875 377 377 <link rel="Chapter" title="1 Introduction" href="#rfc.section.1"> 378 378 <link rel="Chapter" title="2 Protocol Parameters" href="#rfc.section.2"> 379 <link rel="Chapter" title="3 Entity" href="#rfc.section.3">379 <link rel="Chapter" title="3 Representation" href="#rfc.section.3"> 380 380 <link rel="Chapter" title="4 Content Negotiation" href="#rfc.section.4"> 381 381 <link rel="Chapter" title="5 Header Field Definitions" href="#rfc.section.5"> … … 384 384 <link rel="Chapter" title="8 Acknowledgments" href="#rfc.section.8"> 385 385 <link rel="Chapter" href="#rfc.section.9" title="9 References"> 386 <link rel="Appendix" title="A Differences Between HTTP Entities and RFC 2045 Entities" href="#rfc.section.A">386 <link rel="Appendix" title="A Differences between HTTP and MIME" href="#rfc.section.A"> 387 387 <link rel="Appendix" title="B Additional Features" href="#rfc.section.B"> 388 388 <link rel="Appendix" title="C Compatibility with Previous Versions" href="#rfc.section.C"> … … 555 555 </ul> 556 556 </li> 557 <li class="tocline0">3. <a href="# entity">Entity</a><ul class="toc">557 <li class="tocline0">3. <a href="#representation">Representation</a><ul class="toc"> 558 558 <li class="tocline1">3.1 <a href="#entity.header.fields">Entity Header Fields</a></li> 559 <li class="tocline1">3.2 <a href="# entity.body">EntityBody</a><ul class="toc">559 <li class="tocline1">3.2 <a href="#payload.body">Payload Body</a><ul class="toc"> 560 560 <li class="tocline1">3.2.1 <a href="#type">Type</a></li> 561 561 </ul> … … 597 597 </li> 598 598 <li class="tocline0"><a href="#rfc.authors">Authors' Addresses</a></li> 599 <li class="tocline0">A. <a href="#differences.between.http. entities.and.rfc.2045.entities">Differences Between HTTP Entities and RFC 2045 Entities</a><ul class="toc">599 <li class="tocline0">A. <a href="#differences.between.http.and.mime">Differences between HTTP and MIME</a><ul class="toc"> 600 600 <li class="tocline1">A.1 <a href="#mime-version">MIME-Version</a></li> 601 601 <li class="tocline1">A.2 <a href="#conversion.to.canonical.form">Conversion to Canonical Form</a></li> … … 818 818 </p> 819 819 <h3 id="rfc.section.2.3.1"><a href="#rfc.section.2.3.1">2.3.1</a> <a id="canonicalization.and.text.defaults" href="#canonicalization.and.text.defaults">Canonicalization and Text Defaults</a></h3> 820 <p id="rfc.section.2.3.1.p.1">Internet media types are registered with a canonical form. An entity-body transferred via HTTP messages <em class="bcp14">MUST</em> be represented in the appropriate canonical form prior to its transmission except for "text" types, as defined in the next 821 paragraph. 820 <p id="rfc.section.2.3.1.p.1">Internet media types are registered with a canonical form. A representation transferred via HTTP messages <em class="bcp14">MUST</em> be in the appropriate canonical form prior to its transmission except for "text" types, as defined in the next paragraph. 822 821 </p> 823 822 <p id="rfc.section.2.3.1.p.2">When in canonical form, media subtypes of the "text" type use CRLF as the text line break. HTTP relaxes this requirement and 824 823 allows the transport of text media with plain CR or LF alone representing a line break when it is done consistently for an 825 entire entity-body. HTTP applications <em class="bcp14">MUST</em> accept CRLF, bare CR, and bare LF as being representative of a line break in text media received via HTTP. In addition, if826 the text is represented in a character set that does not use octets 13 and 10 for CR and LF respectively, as is the case for827 some multi-byte character sets, HTTP allows the use of whatever octet sequences are defined by that character set to represent828 the equivalent of CR and LF for line breaks. This flexibility regarding line breaks applies only to text media in the entity-body;829 a bare CR or LF <em class="bcp14">MUST NOT</em> be substituted for CRLF within any of the HTTP control structures (such as header fields and multipart boundaries).830 </p> 831 <p id="rfc.section.2.3.1.p.3">If a n entity-bodyis encoded with a content-coding, the underlying data <em class="bcp14">MUST</em> be in a form defined above prior to being encoded.832 </p> 833 <p id="rfc.section.2.3.1.p.4">The "charset" parameter is used with some media types to define the character set(<a href="#character.sets" title="Character Sets">Section 2.1</a>) of the data. When no explicit charset parameter is provided by the sender, media subtypes of the "text" type are defined834 to have a default charset value of "ISO-8859-1" when received via HTTP. Data in character sets other than "ISO-8859-1" or835 its subsets <em class="bcp14">MUST</em> be labeled with an appropriate charset value. See <a href="#missing.charset" title="Missing Charset">Section 2.1.1</a> for compatibility problems.824 entire representation. HTTP applications <em class="bcp14">MUST</em> accept CRLF, bare CR, and bare LF as indicating a line break in text media received via HTTP. In addition, if the text is 825 in a character encoding that does not use octets 13 and 10 for CR and LF respectively, as is the case for some multi-byte 826 character encodings, HTTP allows the use of whatever octet sequences are defined by that character encoding to represent the 827 equivalent of CR and LF for line breaks. This flexibility regarding line breaks applies only to text media in the payload 828 body; a bare CR or LF <em class="bcp14">MUST NOT</em> be substituted for CRLF within any of the HTTP control structures (such as header fields and multipart boundaries). 829 </p> 830 <p id="rfc.section.2.3.1.p.3">If a representation is encoded with a content-coding, the underlying data <em class="bcp14">MUST</em> be in a form defined above prior to being encoded. 831 </p> 832 <p id="rfc.section.2.3.1.p.4">The "charset" parameter is used with some media types to define the character encoding (<a href="#character.sets" title="Character Sets">Section 2.1</a>) of the data. When no explicit charset parameter is provided by the sender, media subtypes of the "text" type are defined 833 to have a default charset value of "ISO-8859-1" when received via HTTP. Data in character encodings other than "ISO-8859-1" 834 or its subsets <em class="bcp14">MUST</em> be labeled with an appropriate charset value. See <a href="#missing.charset" title="Missing Charset">Section 2.1.1</a> for compatibility problems. 836 835 </p> 837 836 <h3 id="rfc.section.2.3.2"><a href="#rfc.section.2.3.2">2.3.2</a> <a id="multipart.types" href="#multipart.types">Multipart Types</a></h3> 838 <p id="rfc.section.2.3.2.p.1">MIME provides for a number of "multipart" types -- encapsulations of one or more entities within a single message-body. All839 multipart types share a common syntax, as defined in <a href="http://tools.ietf.org/html/rfc2046#section-5.1.1">Section 5.1.1</a> of <a href="#RFC2046" id="rfc.xref.RFC2046.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, and <em class="bcp14">MUST</em> include a boundary parameter as part of the media type value. The message body is itself a protocol element and <em class="bcp14">MUST</em> therefore use only CRLF to represent line breaks between body-parts.837 <p id="rfc.section.2.3.2.p.1">MIME provides for a number of "multipart" types -- encapsulations of one or more representations within a single message-body. 838 All multipart types share a common syntax, as defined in <a href="http://tools.ietf.org/html/rfc2046#section-5.1.1">Section 5.1.1</a> of <a href="#RFC2046" id="rfc.xref.RFC2046.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, and <em class="bcp14">MUST</em> include a boundary parameter as part of the media type value. The message body is itself a protocol element and <em class="bcp14">MUST</em> therefore use only CRLF to represent line breaks between body-parts. 840 839 </p> 841 840 <p id="rfc.section.2.3.2.p.2">In general, HTTP treats a multipart message-body no differently than any other media type: strictly as payload. HTTP does … … 866 865 </pre> <p id="rfc.section.2.4.p.6">See <a href="#RFC5646" id="rfc.xref.RFC5646.3"><cite title="Tags for Identifying Languages">[RFC5646]</cite></a> for further information. 867 866 </p> 868 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id=" entity" href="#entity">Entity</a></h1>867 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="representation" href="#representation">Representation</a></h1> 869 868 <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 869 of entity-header fields and a representation body, although some responses will only include the entity-headers. … … 874 873 </p> 875 874 <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 metadata about the entity-body or, if no body is present, about the resource identified by the 877 request. 875 <p id="rfc.section.3.1.p.1">Entity-header fields define metadata about the representation data enclosed in the message-body or, if no message-body is 876 present, about the representation that would have been transferred in a 200 response to a simultaneous GET request on the 877 Effective Request URI. 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> … … 892 892 fields cannot be assumed to be recognizable by the recipient. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by the recipient and <em class="bcp14">MUST</em> be forwarded by transparent proxies. 893 893 </p> 894 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="entity.body" href="#entity.body">Entity Body</a></h2> 895 <p id="rfc.section.3.2.p.1">The entity-body (if any) sent with an HTTP request or response is in a format and encoding defined by the entity-header fields.</p> 896 <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.13"></span> <a href="#entity.body" class="smpl">entity-body</a> = *<a href="#notation" class="smpl">OCTET</a> 897 </pre><p id="rfc.section.3.2.p.3">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.18"><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 894 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="payload.body" href="#payload.body">Payload Body</a></h2> 895 <p id="rfc.section.3.2.p.1">The payload body (if any) sent with an HTTP request or response is in a format and encoding defined by the entity-header fields.</p> 896 <p id="rfc.section.3.2.p.2">A payload 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.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The payload body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied to ensure 898 897 safe and proper transfer of the message. 899 898 </p> 900 899 <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a> <a id="type" href="#type">Type</a></h3> 901 <p id="rfc.section.3.2.1.p.1">When a n entity-body is included with a message, the data type of that body is determined via the header fields Content-Type900 <p id="rfc.section.3.2.1.p.1">When a payload body is included with a message, the data type of that body is determined via the header fields Content-Type 902 901 and Content-Encoding. These define a two-layer, ordered encoding model: 903 902 </p> 904 <div id="rfc.figure.u.1 4"></div><pre class="text"> entity-body := Content-Encoding( Content-Type( data ) )905 </pre><p id="rfc.section.3.2.1.p.3">Content-Type specifies the media type of the underlying data. Any HTTP/1.1 message containing a n entity-body <em class="bcp14">SHOULD</em> include a Content-Type header field defining the media type of that body, unless that information is unknown.903 <div id="rfc.figure.u.13"></div><pre class="text"> payload-body := Content-Encoding( Content-Type( data ) ) 904 </pre><p id="rfc.section.3.2.1.p.3">Content-Type specifies the media type of the underlying data. Any HTTP/1.1 message containing a payload body <em class="bcp14">SHOULD</em> include a Content-Type header field defining the media type of that body, unless that information is unknown. 906 905 </p> 907 906 <p id="rfc.section.3.2.1.p.4">If the Content-Type header field is not present, it indicates that the sender does not know the media type of the data; recipients <em class="bcp14">MAY</em> either assume that it is "application/octet-stream" (<a href="#RFC2046" id="rfc.xref.RFC2046.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, <a href="http://tools.ietf.org/html/rfc2046#section-4.5.1">Section 4.5.1</a>) or examine the content to determine its type. … … 911 910 the specified type. 912 911 </p> 913 <p id="rfc.section.3.2.1.p.6">Client that do so risk drawing incorrect conclusions, which may expose additional security risks (e.g., "privilege escalation").912 <p id="rfc.section.3.2.1.p.6">Clients that do so risk drawing incorrect conclusions, which may expose additional security risks (e.g., "privilege escalation"). 914 913 Implementers are encouraged to provide a means of disabling such "content sniffing" when it is used. 915 914 </p> 916 915 <p id="rfc.section.3.2.1.p.7">Content-Encoding may be used to indicate any additional content codings applied to the data, usually for the purpose of data 917 compression, that are a property of the re quested resource. There is no default encoding.916 compression, that are a property of the representation. There is no default encoding. 918 917 </p> 919 918 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="content.negotiation" href="#content.negotiation">Content Negotiation</a></h1> … … 977 976 <p id="rfc.section.4.2.p.1">With agent-driven negotiation, selection of the best representation for a response is performed by the user agent after receiving 978 977 an initial response from the origin server. Selection is based on a list of the available representations of the response 979 included within the header fields or entity-body of the initial response, with each representation identified by its own URI.980 Selection from among the representations may be performed automatically (if the user agent is capable of doing so) or manually981 by theuser selecting from a generated (possibly hypertext) menu.978 included within the header fields or body of the initial response, with each representation identified by its own URI. Selection 979 from among the representations may be performed automatically (if the user agent is capable of doing so) or manually by the 980 user selecting from a generated (possibly hypertext) menu. 982 981 </p> 983 982 <p id="rfc.section.4.2.p.2">Agent-driven negotiation is advantageous when the response would vary over commonly-used dimensions (such as type, language, … … 1005 1004 for an in-line image. 1006 1005 </p> 1007 <div id="rfc.figure.u.1 5"></div><pre class="inline"><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span> <a href="#header.accept" class="smpl">Accept</a> = "Accept" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.accept" class="smpl">Accept-v</a>1006 <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span> <a href="#header.accept" class="smpl">Accept</a> = "Accept" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.accept" class="smpl">Accept-v</a> 1008 1007 <a href="#header.accept" class="smpl">Accept-v</a> = #( <a href="#header.accept" class="smpl">media-range</a> [ <a href="#header.accept" class="smpl">accept-params</a> ] ) 1009 1008 … … 1030 1029 </div> 1031 1030 <p id="rfc.section.5.1.p.6">The example</p> 1032 <div id="rfc.figure.u.1 6"></div><pre class="text"> Accept: audio/*; q=0.2, audio/basic1031 <div id="rfc.figure.u.15"></div><pre class="text"> Accept: audio/*; q=0.2, audio/basic 1033 1032 </pre><p id="rfc.section.5.1.p.8"> <em class="bcp14">SHOULD</em> be interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% mark-down in 1034 1033 quality." … … 1039 1038 </p> 1040 1039 <p id="rfc.section.5.1.p.10">A more elaborate example is</p> 1041 <div id="rfc.figure.u.1 7"></div><pre class="text"> Accept: text/plain; q=0.5, text/html,1040 <div id="rfc.figure.u.16"></div><pre class="text"> Accept: text/plain; q=0.5, text/html, 1042 1041 text/x-dvi; q=0.8, text/x-c 1043 1042 </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 … … 1047 1046 to a given type, the most specific reference has precedence. For example, 1048 1047 </p> 1049 <div id="rfc.figure.u.1 8"></div><pre class="text"> Accept: text/*, text/html, text/html;level=1, */*1048 <div id="rfc.figure.u.17"></div><pre class="text"> Accept: text/*, text/html, text/html;level=1, */* 1050 1049 </pre><p id="rfc.section.5.1.p.15">have the following precedence: </p> 1051 1050 <ol> … … 1058 1057 which matches that type. For example, 1059 1058 </p> 1060 <div id="rfc.figure.u.1 9"></div><pre class="text"> Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,1059 <div id="rfc.figure.u.18"></div><pre class="text"> Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, 1061 1060 text/html;level=2;q=0.4, */*;q=0.5 1062 1061 </pre><p id="rfc.section.5.1.p.18">would cause the following values to be associated:</p> … … 1107 1106 to a server which is capable of representing documents in those character sets. 1108 1107 </p> 1109 <div id="rfc.figure.u. 20"></div><pre class="inline"><span id="rfc.iref.g.19"></span><span id="rfc.iref.g.20"></span> <a href="#header.accept-charset" class="smpl">Accept-Charset</a> = "Accept-Charset" ":" <a href="#core.rules" class="smpl">OWS</a>1108 <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span> <a href="#header.accept-charset" class="smpl">Accept-Charset</a> = "Accept-Charset" ":" <a href="#core.rules" class="smpl">OWS</a> 1110 1109 <a href="#header.accept-charset" class="smpl">Accept-Charset-v</a> 1111 1110 <a href="#header.accept-charset" class="smpl">Accept-Charset-v</a> = 1#( ( <a href="#rule.charset" class="smpl">charset</a> / "*" ) … … 1114 1113 example is 1115 1114 </p> 1116 <div id="rfc.figure.u.2 1"></div><pre class="text"> Accept-Charset: iso-8859-5, unicode-1-1;q=0.81115 <div id="rfc.figure.u.20"></div><pre class="text"> Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 1117 1116 </pre><p id="rfc.section.5.2.p.5">The special value "*", if present in the Accept-Charset field, matches every character set (including ISO-8859-1) which is 1118 1117 not mentioned elsewhere in the Accept-Charset field. If no "*" is present in an Accept-Charset field, then all character sets … … 1128 1127 <p id="rfc.section.5.3.p.1">The "Accept-Encoding" request-header field can be used by user agents to indicate what response content-codings (<a href="#content.codings" title="Content Codings">Section 2.2</a>) are acceptable in the response. 1129 1128 </p> 1130 <div id="rfc.figure.u.2 2"></div><pre class="inline"><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span> <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> = "Accept-Encoding" ":" <a href="#core.rules" class="smpl">OWS</a>1129 <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.20"></span><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span> <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> = "Accept-Encoding" ":" <a href="#core.rules" class="smpl">OWS</a> 1131 1130 <a href="#header.accept-encoding" class="smpl">Accept-Encoding-v</a> 1132 1131 <a href="#header.accept-encoding" class="smpl">Accept-Encoding-v</a> = … … 1136 1135 </p> 1137 1136 <p id="rfc.section.5.3.p.4">Examples of its use are:</p> 1138 <div id="rfc.figure.u.2 3"></div><pre class="text"> Accept-Encoding: compress, gzip1137 <div id="rfc.figure.u.22"></div><pre class="text"> Accept-Encoding: compress, gzip 1139 1138 Accept-Encoding: 1140 1139 Accept-Encoding: * … … 1180 1179 in the response. Language tags are defined in <a href="#language.tags" title="Language Tags">Section 2.4</a>. 1181 1180 </p> 1182 <div id="rfc.figure.u.2 4"></div><pre class="inline"><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span><span id="rfc.iref.g.26"></span> <a href="#header.accept-language" class="smpl">Accept-Language</a> = "Accept-Language" ":" <a href="#core.rules" class="smpl">OWS</a>1181 <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.23"></span><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span> <a href="#header.accept-language" class="smpl">Accept-Language</a> = "Accept-Language" ":" <a href="#core.rules" class="smpl">OWS</a> 1183 1182 <a href="#header.accept-language" class="smpl">Accept-Language-v</a> 1184 1183 <a href="#header.accept-language" class="smpl">Accept-Language-v</a> = … … 1189 1188 languages specified by that range. The quality value defaults to "q=1". For example, 1190 1189 </p> 1191 <div id="rfc.figure.u.2 5"></div><pre class="text"> Accept-Language: da, en-gb;q=0.8, en;q=0.71190 <div id="rfc.figure.u.24"></div><pre class="text"> Accept-Language: da, en-gb;q=0.8, en;q=0.7 1192 1191 </pre><p id="rfc.section.5.4.p.5">would mean: "I prefer Danish, but will accept British English and other types of English." (see also <a href="http://tools.ietf.org/html/rfc4647#section-2.3">Section 2.3</a> of <a href="#RFC4647" id="rfc.xref.RFC4647.2"><cite title="Matching of Language Tags">[RFC4647]</cite></a>) 1193 1192 </p> … … 1218 1217 is primarily used to allow a representation to be compressed without losing the identity of its underlying media type. 1219 1218 </p> 1220 <div id="rfc.figure.u.2 6"></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>1219 <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.26"></span><span id="rfc.iref.g.27"></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> 1221 1220 <a href="#header.content-encoding" class="smpl">Content-Encoding-v</a> = 1#<a href="#content.codings" class="smpl">content-coding</a> 1222 1221 </pre><p id="rfc.section.5.5.p.3">Content codings are defined in <a href="#content.codings" title="Content Codings">Section 2.2</a>. An example of its use is 1223 1222 </p> 1224 <div id="rfc.figure.u.2 7"></div><pre class="text"> Content-Encoding: gzip1223 <div id="rfc.figure.u.26"></div><pre class="text"> Content-Encoding: gzip 1225 1224 </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 1225 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 … … 1229 1228 <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 1229 </p> 1231 <p id="rfc.section.5.5.p.7">If the content-coding of a n entityin 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).1230 <p id="rfc.section.5.5.p.7">If the content-coding of a representation 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 1231 </p> 1233 1232 <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. … … 1237 1236 <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 1237 <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 </p> 1241 <div id="rfc.figure.u.2 8"></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>1238 Note that this might not be equivalent to all the languages used within the representation. 1239 </p> 1240 <div id="rfc.figure.u.27"></div><pre class="inline"><span id="rfc.iref.g.28"></span><span id="rfc.iref.g.29"></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 1241 <a href="#header.content-language" class="smpl">Content-Language-v</a> = 1#<a href="#language.tags" class="smpl">language-tag</a> 1243 1242 </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 … … 1245 1244 field is 1246 1245 </p> 1247 <div id="rfc.figure.u.2 9"></div><pre class="text"> Content-Language: da1246 <div id="rfc.figure.u.28"></div><pre class="text"> Content-Language: da 1248 1247 </pre><p id="rfc.section.5.6.p.5">If no Content-Language is specified, the default is that the content is intended for all language audiences. This might mean 1249 1248 that the sender does not consider it to be specific to any natural language, or that the sender does not know for which language … … 1253 1252 simultaneously in the original Maori and English versions, would call for 1254 1253 </p> 1255 <div id="rfc.figure.u. 30"></div><pre class="text"> Content-Language: mi, en1254 <div id="rfc.figure.u.29"></div><pre class="text"> Content-Language: mi, en 1256 1255 </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 1256 linguistic audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin," which is clearly … … 1267 1266 would contain the same representation that is enclosed as payload in this message. 1268 1267 </p> 1269 <div id="rfc.figure.u.3 1"></div><pre class="inline"><span id="rfc.iref.g.31"></span><span id="rfc.iref.g.32"></span> <a href="#header.content-location" class="smpl">Content-Location</a> = "Content-Location" ":" <a href="#core.rules" class="smpl">OWS</a>1268 <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.30"></span><span id="rfc.iref.g.31"></span> <a href="#header.content-location" class="smpl">Content-Location</a> = "Content-Location" ":" <a href="#core.rules" class="smpl">OWS</a> 1270 1269 <a href="#header.content-location" class="smpl">Content-Location-v</a> 1271 1270 <a href="#header.content-location" class="smpl">Content-Location-v</a> = … … 1308 1307 <div id="rfc.iref.h.8"></div> 1309 1308 <h2 id="rfc.section.5.8"><a href="#rfc.section.5.8">5.8</a> <a id="header.content-md5" href="#header.content-md5">Content-MD5</a></h2> 1310 <p id="rfc.section.5.8.p.1">The "Content-MD5" entity-header field, as defined in <a href="#RFC1864" id="rfc.xref.RFC1864.1"><cite title="The Content-MD5 Header Field">[RFC1864]</cite></a>, is an MD5 digest of the entity-body that provides an end-to-end message integrity check (MIC) of the entity-body. Note that 1311 a MIC is good for detecting accidental modification of the entity-body in transit, but is not proof against malicious attacks. 1312 </p> 1313 <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.33"></span><span id="rfc.iref.g.34"></span> <a href="#header.content-md5" class="smpl">Content-MD5</a> = "Content-MD5" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-md5" class="smpl">Content-MD5-v</a> 1309 <p id="rfc.section.5.8.p.1">The "Content-MD5" entity-header field, as defined in <a href="#RFC1864" id="rfc.xref.RFC1864.1"><cite title="The Content-MD5 Header Field">[RFC1864]</cite></a>, is an MD5 digest of the payload body that provides an end-to-end message integrity check (MIC) of the payload body (the 1310 message-body after any transfer-coding is decoded). Note that a MIC is good for detecting accidental modification of the payload 1311 body in transit, but is not proof against malicious attacks. 1312 </p> 1313 <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.32"></span><span id="rfc.iref.g.33"></span> <a href="#header.content-md5" class="smpl">Content-MD5</a> = "Content-MD5" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-md5" class="smpl">Content-MD5-v</a> 1314 1314 <a href="#header.content-md5" class="smpl">Content-MD5-v</a> = <base64 of 128 bit MD5 digest as per <a href="#RFC1864" id="rfc.xref.RFC1864.2"><cite title="The Content-MD5 Header Field">[RFC1864]</cite></a>> 1315 </pre><p id="rfc.section.5.8.p.3">The Content-MD5 header field <em class="bcp14">MAY</em> be generated by an origin server or client to function as an integrity check of the entity-body. Only origin servers or clients <em class="bcp14">MAY</em> generate the Content-MD5 header field; proxies and gateways <em class="bcp14">MUST NOT</em> generate it, as this would defeat its value as an end-to-end integrity check. Any recipient of the entity-body, including 1316 gateways and proxies, <em class="bcp14">MAY</em> check that the digest value in this header field matches that of the entity-body as received. 1317 </p> 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 1319 not including any transfer-encoding applied to the message-body. If the message is received with a transfer-encoding, that 1320 encoding <em class="bcp14">MUST</em> be removed prior to checking the Content-MD5 value against the received representation. 1321 </p> 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 1323 be sent if no transfer-encoding were being applied. 1324 </p> 1325 <p id="rfc.section.5.8.p.6">HTTP extends RFC 1864 to permit the digest to be computed for MIME composite media-types (e.g., multipart/* and message/rfc822), 1315 </pre><p id="rfc.section.5.8.p.3">The Content-MD5 header field <em class="bcp14">MAY</em> be generated by an origin server or client to function as an integrity check of the payload body. Only origin servers or user 1316 agents <em class="bcp14">MAY</em> generate the Content-MD5 header field; proxies and gateways <em class="bcp14">MUST NOT</em> generate it, as this would defeat its value as an end-to-end integrity check. Any recipient <em class="bcp14">MAY</em> check that the digest value in this header field matches a corresponding digest calculated on payload body as received. 1317 </p> 1318 <p id="rfc.section.5.8.p.4">The MD5 digest is computed based on the content of the payload body, including any content-coding, but not including any transfer-coding 1319 applied to the message-body because such transfer-codings might be applied or removed anywhere along the request/response 1320 chain. If the message is received with a transfer-coding, that encoding <em class="bcp14">MUST</em> be decoded prior to checking the Content-MD5 value against the received payload. 1321 </p> 1322 <p id="rfc.section.5.8.p.5">HTTP extends RFC 1864 to permit the digest to be computed for MIME composite media-types (e.g., multipart/* and message/rfc822), 1326 1323 but this does not change how the digest is computed as defined in the preceding paragraph. 1327 1324 </p> 1328 <p id="rfc.section.5.8.p. 7">There are several consequences of this. The entity-bodyfor composite types <em class="bcp14">MAY</em> contain many body-parts, each with its own MIME and HTTP headers (including Content-MD5, Content-Transfer-Encoding, and Content-Encoding1325 <p id="rfc.section.5.8.p.6">There are several consequences of this. The payload for composite types <em class="bcp14">MAY</em> contain many body-parts, each with its own MIME and HTTP headers (including Content-MD5, Content-Transfer-Encoding, and Content-Encoding 1329 1326 headers). If a body-part has a Content-Transfer-Encoding or Content-Encoding header, it is assumed that the content of the 1330 1327 body-part has had the encoding applied, and the body-part is included in the Content-MD5 digest as is -- i.e., after the application. 1331 1328 The Transfer-Encoding header field is not allowed within body-parts. 1332 1329 </p> 1333 <p id="rfc.section.5.8.p. 8">Conversion of all line breaks to CRLF <em class="bcp14">MUST NOT</em> be done before computing or checking the digest: the line break convention used in the text actually transmitted <em class="bcp14">MUST</em> be left unaltered when computing the digest.1334 </p> 1335 <div class="note" id="rfc.section.5.8.p. 9">1330 <p id="rfc.section.5.8.p.7">Conversion of all line breaks to CRLF <em class="bcp14">MUST NOT</em> be done before computing or checking the digest: the line break convention used in the text actually transmitted <em class="bcp14">MUST</em> be left unaltered when computing the digest. 1331 </p> 1332 <div class="note" id="rfc.section.5.8.p.8"> 1336 1333 <p> <b>Note:</b> While the definition of Content-MD5 is exactly the same for HTTP as in RFC 1864 for MIME entity-bodies, there are several 1337 1334 ways in which the application of Content-MD5 to HTTP entity-bodies differs from its application to MIME entity-bodies. One … … 1345 1342 <div id="rfc.iref.h.9"></div> 1346 1343 <h2 id="rfc.section.5.9"><a href="#rfc.section.5.9">5.9</a> <a id="header.content-type" href="#header.content-type">Content-Type</a></h2> 1347 <p id="rfc.section.5.9.p.1">The "Content-Type" entity-header field indicates the media type of the entity-body. In the case of responses to the HEAD method,1348 the media type is that which would have been sent had the request been a GET.1349 </p> 1350 <div id="rfc.figure.u.3 3"></div><pre class="inline"><span id="rfc.iref.g.35"></span><span id="rfc.iref.g.36"></span> <a href="#header.content-type" class="smpl">Content-Type</a> = "Content-Type" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-type" class="smpl">Content-Type-v</a>1344 <p id="rfc.section.5.9.p.1">The "Content-Type" entity-header field indicates the media type of the representation. In the case of responses to the HEAD 1345 method, the media type is that which would have been sent had the request been a GET. 1346 </p> 1347 <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.34"></span><span id="rfc.iref.g.35"></span> <a href="#header.content-type" class="smpl">Content-Type</a> = "Content-Type" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-type" class="smpl">Content-Type-v</a> 1351 1348 <a href="#header.content-type" class="smpl">Content-Type-v</a> = <a href="#media.types" class="smpl">media-type</a> 1352 1349 </pre><p id="rfc.section.5.9.p.3">Media types are defined in <a href="#media.types" title="Media Types">Section 2.3</a>. An example of the field is 1353 1350 </p> 1354 <div id="rfc.figure.u.3 4"></div><pre class="text"> Content-Type: text/html; charset=ISO-8859-41355 </pre><p id="rfc.section.5.9.p.5">Further discussion of methods for identifying the media type of a n entityis provided in <a href="#type" title="Type">Section 3.2.1</a>.1351 <div id="rfc.figure.u.33"></div><pre class="text"> Content-Type: text/html; charset=ISO-8859-4 1352 </pre><p id="rfc.section.5.9.p.5">Further discussion of methods for identifying the media type of a representation is provided in <a href="#type" title="Type">Section 3.2.1</a>. 1356 1353 </p> 1357 1354 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> … … 1715 1712 <span class="n hidden"><span class="family-name">Reschke</span><span class="given-name">Julian F.</span></span></span><span class="org vcardline">greenbytes GmbH</span><span class="adr"><span class="street-address vcardline">Hafenweg 16</span><span class="vcardline"><span class="locality">Muenster</span>, <span class="region">NW</span> <span class="postal-code">48155</span></span><span class="country-name vcardline">Germany</span></span><span class="vcardline tel">Phone: <a href="tel:+492512807760"><span class="value">+49 251 2807760</span></a></span><span class="vcardline tel"><span class="type">Fax</span>: <a href="fax:+492512807761"><span class="value">+49 251 2807761</span></a></span><span class="vcardline">Email: <a href="mailto:julian.reschke@greenbytes.de"><span class="email">julian.reschke@greenbytes.de</span></a></span><span class="vcardline">URI: <a href="http://greenbytes.de/tech/webdav/" class="url">http://greenbytes.de/tech/webdav/</a></span></address> 1716 1713 </div> 1717 <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a> <a id="differences.between.http. entities.and.rfc.2045.entities" href="#differences.between.http.entities.and.rfc.2045.entities">Differences Between HTTP Entities and RFC 2045 Entities</a></h1>1718 <p id="rfc.section.A.p.1">HTTP/1.1 uses many of the constructs defined for Internet Mail (<a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a>) and the Multipurpose Internet Mail Extensions (MIME <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>) to allow entities to be transmitted in an open variety of representations and with extensible mechanisms. However, RFC 20451719 discusses mail, and HTTP has a few features that are different from those described in RFC 2045. These differences were carefully1720 c hosen to optimize performance over binary connections, to allow greater freedom in the use of new media types, to make date1721 comparisons easier, and to acknowledge the practice of some early HTTP servers and clients.1722 </p> 1723 <p id="rfc.section.A.p.2">This appendix describes specific areas where HTTP differs from RFC 2045. Proxies and gateways to strict MIME environments <em class="bcp14">SHOULD</em> be aware of these differences and provide the appropriate conversions where necessary. Proxies and gateways from MIME environments1714 <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a> <a id="differences.between.http.and.mime" href="#differences.between.http.and.mime">Differences between HTTP and MIME</a></h1> 1715 <p id="rfc.section.A.p.1">HTTP/1.1 uses many of the constructs defined for Internet Mail (<a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a>) and the Multipurpose Internet Mail Extensions (MIME <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>) to allow a message-body to be transmitted in an open variety of representations and with extensible mechanisms. However, 1716 RFC 2045 discusses mail, and HTTP has a few features that are different from those described in MIME. These differences were 1717 carefully chosen to optimize performance over binary connections, to allow greater freedom in the use of new media types, 1718 to make date comparisons easier, and to acknowledge the practice of some early HTTP servers and clients. 1719 </p> 1720 <p id="rfc.section.A.p.2">This appendix describes specific areas where HTTP differs from MIME. Proxies and gateways to strict MIME environments <em class="bcp14">SHOULD</em> be aware of these differences and provide the appropriate conversions where necessary. Proxies and gateways from MIME environments 1724 1721 to HTTP also need to be aware of the differences because some conversions might be required. 1725 1722 </p> … … 1732 1729 environments. 1733 1730 </p> 1734 <div id="rfc.figure.u.3 5"></div><pre class="inline"><span id="rfc.iref.g.37"></span><span id="rfc.iref.g.38"></span> <a href="#mime-version" class="smpl">MIME-Version</a> = "MIME-Version" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#mime-version" class="smpl">MIME-Version-v</a>1731 <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.36"></span><span id="rfc.iref.g.37"></span> <a href="#mime-version" class="smpl">MIME-Version</a> = "MIME-Version" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#mime-version" class="smpl">MIME-Version-v</a> 1735 1732 <a href="#mime-version" class="smpl">MIME-Version-v</a> = 1*<a href="#notation" class="smpl">DIGIT</a> "." 1*<a href="#notation" class="smpl">DIGIT</a> 1736 1733 </pre><p id="rfc.section.A.1.p.3">MIME version "1.0" is the default for use in HTTP/1.1. However, HTTP/1.1 message parsing and semantics are defined by this … … 1738 1735 </p> 1739 1736 <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a> <a id="conversion.to.canonical.form" href="#conversion.to.canonical.form">Conversion to Canonical Form</a></h2> 1740 <p id="rfc.section.A.2.p.1"> <a href="#RFC2045" id="rfc.xref.RFC2045.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> requires that an Internet mail entitybe converted to canonical form prior to being transferred, as described in <a href="http://tools.ietf.org/html/rfc2049#section-4">Section 4</a> of <a href="#RFC2049" id="rfc.xref.RFC2049.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples">[RFC2049]</cite></a>. <a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section 2.3.1</a> of this document describes the forms allowed for subtypes of the "text" media type when transmitted over HTTP. <a href="#RFC2046" id="rfc.xref.RFC2046.4"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> requires that content with a type of "text" represent line breaks as CRLF and forbids the use of CR or LF outside of line1737 <p id="rfc.section.A.2.p.1">MIME requires that an Internet mail body-part be converted to canonical form prior to being transferred, as described in <a href="http://tools.ietf.org/html/rfc2049#section-4">Section 4</a> of <a href="#RFC2049" id="rfc.xref.RFC2049.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples">[RFC2049]</cite></a>. <a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section 2.3.1</a> of this document describes the forms allowed for subtypes of the "text" media type when transmitted over HTTP. <a href="#RFC2046" id="rfc.xref.RFC2046.4"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> requires that content with a type of "text" represent line breaks as CRLF and forbids the use of CR or LF outside of line 1741 1738 break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a line break within text content when a message is transmitted 1742 1739 over HTTP. … … 1754 1751 </p> 1755 1752 <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> 1756 <p id="rfc.section.A.4.p.1"> RFC 2045 does not include any concept equivalent to HTTP/1.1's Content-Encoding header field. Since this acts as a modifier1757 on the media type, proxies and gateways from HTTP to MIME-compliant protocols <em class="bcp14">MUST</em> either change the value of the Content-Type header field or decode the entity-body before forwarding the message. (Some experimental1758 applications of Content-Type for Internet mail have used a media-type parameter of ";conversions=<content-coding>" to perform1759 a function equivalent to Content-Encoding. However, this parameter is not part of RFC 2045).1753 <p id="rfc.section.A.4.p.1">MIME does not include any concept equivalent to HTTP/1.1's Content-Encoding header field. Since this acts as a modifier on 1754 the media type, proxies and gateways from HTTP to MIME-compliant protocols <em class="bcp14">MUST</em> either change the value of the Content-Type header field or decode the representation before forwarding the message. (Some 1755 experimental applications of Content-Type for Internet mail have used a media-type parameter of ";conversions=<content-coding>" 1756 to perform a function equivalent to Content-Encoding. However, this parameter is not part of the MIME standards). 1760 1757 </p> 1761 1758 <h2 id="rfc.section.A.5"><a href="#rfc.section.A.5">A.5</a> <a id="no.content-transfer-encoding" href="#no.content-transfer-encoding">No Content-Transfer-Encoding</a></h2> 1762 <p id="rfc.section.A.5.p.1">HTTP does not use the Content-Transfer-Encoding field of RFC 2045. Proxies and gateways from MIME-compliant protocols to HTTP <em class="bcp14">MUST</em> remove any Content-Transfer-Encoding prior to delivering the response message to an HTTP client.1759 <p id="rfc.section.A.5.p.1">HTTP does not use the Content-Transfer-Encoding field of MIME. Proxies and gateways from MIME-compliant protocols to HTTP <em class="bcp14">MUST</em> remove any Content-Transfer-Encoding prior to delivering the response message to an HTTP client. 1763 1760 </p> 1764 1761 <p id="rfc.section.A.5.p.2">Proxies and gateways from HTTP to MIME-compliant protocols are responsible for ensuring that the message is in the correct … … 1790 1787 in <a href="#RFC2183" id="rfc.xref.RFC2183.3"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a>. 1791 1788 </p> 1792 <div id="rfc.figure.u.3 6"></div><pre class="inline"><span id="rfc.iref.g.39"></span><span id="rfc.iref.g.40"></span><span id="rfc.iref.g.41"></span><span id="rfc.iref.g.42"></span><span id="rfc.iref.g.43"></span><span id="rfc.iref.g.44"></span><span id="rfc.iref.g.45"></span> <a href="#content-disposition" class="smpl">content-disposition</a> = "Content-Disposition" ":" <a href="#core.rules" class="smpl">OWS</a>1789 <div id="rfc.figure.u.35"></div><pre class="inline"><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span><span id="rfc.iref.g.40"></span><span id="rfc.iref.g.41"></span><span id="rfc.iref.g.42"></span><span id="rfc.iref.g.43"></span><span id="rfc.iref.g.44"></span> <a href="#content-disposition" class="smpl">content-disposition</a> = "Content-Disposition" ":" <a href="#core.rules" class="smpl">OWS</a> 1793 1790 <a href="#content-disposition" class="smpl">content-disposition-v</a> 1794 1791 <a href="#content-disposition" class="smpl">content-disposition-v</a> = <a href="#content-disposition" class="smpl">disposition-type</a> … … 1800 1797 <a href="#content-disposition" class="smpl">disp-extension-parm</a> = <a href="#core.rules" class="smpl">token</a> "=" <a href="#core.rules" class="smpl">word</a> 1801 1798 </pre><p id="rfc.section.B.1.p.3">An example is</p> 1802 <div id="rfc.figure.u.3 7"></div><pre class="text"> Content-Disposition: attachment; filename="fname.ext"1799 <div id="rfc.figure.u.36"></div><pre class="text"> Content-Disposition: attachment; filename="fname.ext" 1803 1800 </pre><p id="rfc.section.B.1.p.5">The receiving user agent <em class="bcp14">SHOULD NOT</em> respect any directory path information present in the filename-parm parameter, which is the only parameter believed to apply 1804 1801 to HTTP implementations at this time. The filename <em class="bcp14">SHOULD</em> be treated as a terminal component only. … … 1830 1827 </p> 1831 1828 <h1 id="rfc.section.D"><a href="#rfc.section.D">D.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 1832 <div id="rfc.figure.u.3 8"></div> <pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = "Accept:" OWS Accept-v1829 <div id="rfc.figure.u.37"></div> <pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = "Accept:" OWS Accept-v 1833 1830 <a href="#header.accept-charset" class="smpl">Accept-Charset</a> = "Accept-Charset:" OWS Accept-Charset-v 1834 1831 <a href="#header.accept-charset" class="smpl">Accept-Charset-v</a> = *( "," OWS ) ( charset / "*" ) [ OWS ";" OWS "q=" … … 1887 1884 <a href="#content-disposition" class="smpl">disposition-type</a> = "attachment" / disp-extension-token 1888 1885 1889 <a href="#entity.body" class="smpl">entity-body</a> = *OCTET1890 1886 <a href="#entity.header.fields" class="smpl">entity-header</a> = Content-Encoding / Content-Language / Content-Length 1891 1887 / Content-Location / Content-MD5 / Content-Range / Content-Type / … … 1918 1914 1919 1915 <a href="#core.rules" class="smpl">word</a> = <word, defined in [Part1], Section 1.2.2> 1920 </pre> <div id="rfc.figure.u.3 9"></div>1916 </pre> <div id="rfc.figure.u.38"></div> 1921 1917 <p>ABNF diagnostics:</p><pre class="inline">; Accept defined but not used 1922 1918 ; Accept-Charset defined but not used … … 1925 1921 ; MIME-Version defined but not used 1926 1922 ; content-disposition defined but not used 1927 ; entity-body defined but not used1928 1923 ; entity-header defined but not used 1929 1924 </pre><h1 id="rfc.section.E"><a href="#rfc.section.E">E.</a> <a id="change.log" href="#change.log">Change Log (to be removed by RFC Editor before publication)</a></h1> … … 2140 2135 <li class="indline1"><tt>Grammar</tt> 2141 2136 <ul class="ind"> 2142 <li class="indline1"><tt>Accept</tt> <a class="iref" href="#rfc.iref.g.1 4"><b>5.1</b></a></li>2143 <li class="indline1"><tt>Accept-Charset</tt> <a class="iref" href="#rfc.iref.g.1 9"><b>5.2</b></a></li>2144 <li class="indline1"><tt>Accept-Charset-v</tt> <a class="iref" href="#rfc.iref.g. 20"><b>5.2</b></a></li>2145 <li class="indline1"><tt>Accept-Encoding</tt> <a class="iref" href="#rfc.iref.g.2 1"><b>5.3</b></a></li>2146 <li class="indline1"><tt>Accept-Encoding-v</tt> <a class="iref" href="#rfc.iref.g.2 2"><b>5.3</b></a></li>2147 <li class="indline1"><tt>accept-ext</tt> <a class="iref" href="#rfc.iref.g.1 8"><b>5.1</b></a></li>2148 <li class="indline1"><tt>Accept-Language</tt> <a class="iref" href="#rfc.iref.g.2 4"><b>5.4</b></a></li>2149 <li class="indline1"><tt>Accept-Language-v</tt> <a class="iref" href="#rfc.iref.g.2 5"><b>5.4</b></a></li>2150 <li class="indline1"><tt>accept-params</tt> <a class="iref" href="#rfc.iref.g.1 7"><b>5.1</b></a></li>2151 <li class="indline1"><tt>Accept-v</tt> <a class="iref" href="#rfc.iref.g.1 5"><b>5.1</b></a></li>2137 <li class="indline1"><tt>Accept</tt> <a class="iref" href="#rfc.iref.g.13"><b>5.1</b></a></li> 2138 <li class="indline1"><tt>Accept-Charset</tt> <a class="iref" href="#rfc.iref.g.18"><b>5.2</b></a></li> 2139 <li class="indline1"><tt>Accept-Charset-v</tt> <a class="iref" href="#rfc.iref.g.19"><b>5.2</b></a></li> 2140 <li class="indline1"><tt>Accept-Encoding</tt> <a class="iref" href="#rfc.iref.g.20"><b>5.3</b></a></li> 2141 <li class="indline1"><tt>Accept-Encoding-v</tt> <a class="iref" href="#rfc.iref.g.21"><b>5.3</b></a></li> 2142 <li class="indline1"><tt>accept-ext</tt> <a class="iref" href="#rfc.iref.g.17"><b>5.1</b></a></li> 2143 <li class="indline1"><tt>Accept-Language</tt> <a class="iref" href="#rfc.iref.g.23"><b>5.4</b></a></li> 2144 <li class="indline1"><tt>Accept-Language-v</tt> <a class="iref" href="#rfc.iref.g.24"><b>5.4</b></a></li> 2145 <li class="indline1"><tt>accept-params</tt> <a class="iref" href="#rfc.iref.g.16"><b>5.1</b></a></li> 2146 <li class="indline1"><tt>Accept-v</tt> <a class="iref" href="#rfc.iref.g.14"><b>5.1</b></a></li> 2152 2147 <li class="indline1"><tt>attribute</tt> <a class="iref" href="#rfc.iref.g.8"><b>2.3</b></a></li> 2153 2148 <li class="indline1"><tt>charset</tt> <a class="iref" href="#rfc.iref.g.1"><b>2.1</b></a></li> 2154 <li class="indline1"><tt>codings</tt> <a class="iref" href="#rfc.iref.g.2 3"><b>5.3</b></a></li>2149 <li class="indline1"><tt>codings</tt> <a class="iref" href="#rfc.iref.g.22"><b>5.3</b></a></li> 2155 2150 <li class="indline1"><tt>content-coding</tt> <a class="iref" href="#rfc.iref.g.2"><b>2.2</b></a></li> 2156 <li class="indline1"><tt>content-disposition</tt> <a class="iref" href="#rfc.iref.g.39"><b>B.1</b></a></li> 2157 <li class="indline1"><tt>content-disposition-v</tt> <a class="iref" href="#rfc.iref.g.40"><b>B.1</b></a></li> 2158 <li class="indline1"><tt>Content-Encoding</tt> <a class="iref" href="#rfc.iref.g.27"><b>5.5</b></a></li> 2159 <li class="indline1"><tt>Content-Encoding-v</tt> <a class="iref" href="#rfc.iref.g.28"><b>5.5</b></a></li> 2160 <li class="indline1"><tt>Content-Language</tt> <a class="iref" href="#rfc.iref.g.29"><b>5.6</b></a></li> 2161 <li class="indline1"><tt>Content-Language-v</tt> <a class="iref" href="#rfc.iref.g.30"><b>5.6</b></a></li> 2162 <li class="indline1"><tt>Content-Location</tt> <a class="iref" href="#rfc.iref.g.31"><b>5.7</b></a></li> 2163 <li class="indline1"><tt>Content-Location-v</tt> <a class="iref" href="#rfc.iref.g.32"><b>5.7</b></a></li> 2164 <li class="indline1"><tt>Content-MD5</tt> <a class="iref" href="#rfc.iref.g.33"><b>5.8</b></a></li> 2165 <li class="indline1"><tt>Content-MD5-v</tt> <a class="iref" href="#rfc.iref.g.34"><b>5.8</b></a></li> 2166 <li class="indline1"><tt>Content-Type</tt> <a class="iref" href="#rfc.iref.g.35"><b>5.9</b></a></li> 2167 <li class="indline1"><tt>Content-Type-v</tt> <a class="iref" href="#rfc.iref.g.36"><b>5.9</b></a></li> 2168 <li class="indline1"><tt>disp-extension-parm</tt> <a class="iref" href="#rfc.iref.g.45"><b>B.1</b></a></li> 2169 <li class="indline1"><tt>disp-extension-token</tt> <a class="iref" href="#rfc.iref.g.44"><b>B.1</b></a></li> 2170 <li class="indline1"><tt>disposition-parm</tt> <a class="iref" href="#rfc.iref.g.42"><b>B.1</b></a></li> 2171 <li class="indline1"><tt>disposition-type</tt> <a class="iref" href="#rfc.iref.g.41"><b>B.1</b></a></li> 2172 <li class="indline1"><tt>entity-body</tt> <a class="iref" href="#rfc.iref.g.13"><b>3.2</b></a></li> 2151 <li class="indline1"><tt>content-disposition</tt> <a class="iref" href="#rfc.iref.g.38"><b>B.1</b></a></li> 2152 <li class="indline1"><tt>content-disposition-v</tt> <a class="iref" href="#rfc.iref.g.39"><b>B.1</b></a></li> 2153 <li class="indline1"><tt>Content-Encoding</tt> <a class="iref" href="#rfc.iref.g.26"><b>5.5</b></a></li> 2154 <li class="indline1"><tt>Content-Encoding-v</tt> <a class="iref" href="#rfc.iref.g.27"><b>5.5</b></a></li> 2155 <li class="indline1"><tt>Content-Language</tt> <a class="iref" href="#rfc.iref.g.28"><b>5.6</b></a></li> 2156 <li class="indline1"><tt>Content-Language-v</tt> <a class="iref" href="#rfc.iref.g.29"><b>5.6</b></a></li> 2157 <li class="indline1"><tt>Content-Location</tt> <a class="iref" href="#rfc.iref.g.30"><b>5.7</b></a></li> 2158 <li class="indline1"><tt>Content-Location-v</tt> <a class="iref" href="#rfc.iref.g.31"><b>5.7</b></a></li> 2159 <li class="indline1"><tt>Content-MD5</tt> <a class="iref" href="#rfc.iref.g.32"><b>5.8</b></a></li> 2160 <li class="indline1"><tt>Content-MD5-v</tt> <a class="iref" href="#rfc.iref.g.33"><b>5.8</b></a></li> 2161 <li class="indline1"><tt>Content-Type</tt> <a class="iref" href="#rfc.iref.g.34"><b>5.9</b></a></li> 2162 <li class="indline1"><tt>Content-Type-v</tt> <a class="iref" href="#rfc.iref.g.35"><b>5.9</b></a></li> 2163 <li class="indline1"><tt>disp-extension-parm</tt> <a class="iref" href="#rfc.iref.g.44"><b>B.1</b></a></li> 2164 <li class="indline1"><tt>disp-extension-token</tt> <a class="iref" href="#rfc.iref.g.43"><b>B.1</b></a></li> 2165 <li class="indline1"><tt>disposition-parm</tt> <a class="iref" href="#rfc.iref.g.41"><b>B.1</b></a></li> 2166 <li class="indline1"><tt>disposition-type</tt> <a class="iref" href="#rfc.iref.g.40"><b>B.1</b></a></li> 2173 2167 <li class="indline1"><tt>entity-header</tt> <a class="iref" href="#rfc.iref.g.11"><b>3.1</b></a></li> 2174 2168 <li class="indline1"><tt>extension-header</tt> <a class="iref" href="#rfc.iref.g.12"><b>3.1</b></a></li> 2175 <li class="indline1"><tt>filename-parm</tt> <a class="iref" href="#rfc.iref.g.4 3"><b>B.1</b></a></li>2176 <li class="indline1"><tt>language-range</tt> <a class="iref" href="#rfc.iref.g.2 6"><b>5.4</b></a></li>2169 <li class="indline1"><tt>filename-parm</tt> <a class="iref" href="#rfc.iref.g.42"><b>B.1</b></a></li> 2170 <li class="indline1"><tt>language-range</tt> <a class="iref" href="#rfc.iref.g.25"><b>5.4</b></a></li> 2177 2171 <li class="indline1"><tt>language-tag</tt> <a class="iref" href="#rfc.iref.g.10"><b>2.4</b></a></li> 2178 <li class="indline1"><tt>media-range</tt> <a class="iref" href="#rfc.iref.g.1 6"><b>5.1</b></a></li>2172 <li class="indline1"><tt>media-range</tt> <a class="iref" href="#rfc.iref.g.15"><b>5.1</b></a></li> 2179 2173 <li class="indline1"><tt>media-type</tt> <a class="iref" href="#rfc.iref.g.4"><b>2.3</b></a></li> 2180 <li class="indline1"><tt>MIME-Version</tt> <a class="iref" href="#rfc.iref.g.3 7"><b>A.1</b></a></li>2181 <li class="indline1"><tt>MIME-Version-v</tt> <a class="iref" href="#rfc.iref.g.3 8"><b>A.1</b></a></li>2174 <li class="indline1"><tt>MIME-Version</tt> <a class="iref" href="#rfc.iref.g.36"><b>A.1</b></a></li> 2175 <li class="indline1"><tt>MIME-Version-v</tt> <a class="iref" href="#rfc.iref.g.37"><b>A.1</b></a></li> 2182 2176 <li class="indline1"><tt>parameter</tt> <a class="iref" href="#rfc.iref.g.7"><b>2.3</b></a></li> 2183 2177 <li class="indline1"><tt>subtype</tt> <a class="iref" href="#rfc.iref.g.6"><b>2.3</b></a></li> … … 2274 2268 <li class="indline1"><em>RFC1951</em> <a class="iref" href="#rfc.xref.RFC1951.1">6.2</a>, <a class="iref" href="#RFC1951"><b>9.1</b></a></li> 2275 2269 <li class="indline1"><em>RFC1952</em> <a class="iref" href="#rfc.xref.RFC1952.1">6.2</a>, <a class="iref" href="#RFC1952"><b>9.1</b></a></li> 2276 <li class="indline1"><em>RFC2045</em> <a class="iref" href="#RFC2045"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.RFC2045.1">A</a>, <a class="iref" href="#rfc.xref.RFC2045.2">A.1</a> , <a class="iref" href="#rfc.xref.RFC2045.3">A.2</a></li>2270 <li class="indline1"><em>RFC2045</em> <a class="iref" href="#RFC2045"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.RFC2045.1">A</a>, <a class="iref" href="#rfc.xref.RFC2045.2">A.1</a></li> 2277 2271 <li class="indline1"><em>RFC2046</em> <a class="iref" href="#rfc.xref.RFC2046.1">2.3</a>, <a class="iref" href="#rfc.xref.RFC2046.2">2.3.2</a>, <a class="iref" href="#rfc.xref.RFC2046.3">3.2.1</a>, <a class="iref" href="#RFC2046"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.RFC2046.4">A.2</a><ul class="ind"> 2278 2272 <li class="indline1"><em>Section 4.5.1</em> <a class="iref" href="#rfc.xref.RFC2046.3">3.2.1</a></li> -
draft-ietf-httpbis/latest/p4-conditional.html
r868 r875 376 376 <link rel="Index" href="#rfc.index"> 377 377 <link rel="Chapter" title="1 Introduction" href="#rfc.section.1"> 378 <link rel="Chapter" title="2 Entity 378 <link rel="Chapter" title="2 Entity-Tags" href="#rfc.section.2"> 379 379 <link rel="Chapter" title="3 Status Code Definitions" href="#rfc.section.3"> 380 380 <link rel="Chapter" title="4 Weak and Strong Validators" href="#rfc.section.4"> 381 <link rel="Chapter" title="5 Rules for When to Use Entity Tags and Last-Modified Dates" href="#rfc.section.5">381 <link rel="Chapter" title="5 Rules for When to Use Entity-tags and Last-Modified Dates" href="#rfc.section.5"> 382 382 <link rel="Chapter" title="6 Header Field Definitions" href="#rfc.section.6"> 383 383 <link rel="Chapter" title="7 IANA Considerations" href="#rfc.section.7"> … … 536 536 </ul> 537 537 </li> 538 <li class="tocline0">2. <a href="#entity.tags">Entity 539 <li class="tocline1">2.1 <a href="#example.entity.tag.vs.conneg">Example: Entity Tags varying on Content-Negotiated Resources</a></li>538 <li class="tocline0">2. <a href="#entity.tags">Entity-Tags</a><ul class="toc"> 539 <li class="tocline1">2.1 <a href="#example.entity.tag.vs.conneg">Example: Entity-tags varying on Content-Negotiated Resources</a></li> 540 540 </ul> 541 541 </li> … … 546 546 </li> 547 547 <li class="tocline0">4. <a href="#weak.and.strong.validators">Weak and Strong Validators</a></li> 548 <li class="tocline0">5. <a href="#rules.for.when.to.use.entity.tags.and.last-modified.dates">Rules for When to Use Entity Tags and Last-Modified Dates</a></li>548 <li class="tocline0">5. <a href="#rules.for.when.to.use.entity.tags.and.last-modified.dates">Rules for When to Use Entity-tags and Last-Modified Dates</a></li> 549 549 <li class="tocline0">6. <a href="#header.fields">Header Field Definitions</a><ul class="toc"> 550 550 <li class="tocline1">6.1 <a href="#header.etag">ETag</a></li> … … 629 629 <p id="rfc.section.1.2.2.p.1">The ABNF rules below are defined in other parts:</p> 630 630 <div id="rfc.figure.u.2"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">HTTP-date</a> = <HTTP-date, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a>> 631 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="entity.tags" href="#entity.tags">Entity 632 <p id="rfc.section.2.p.1">Entity tags are used for comparing two or more entities from the same requested resource. HTTP/1.1 uses entity tags in the633 ETag (<a href="#header.etag" id="rfc.xref.header.etag.1" title="ETag">Section 6.1</a>), If-Match (<a href="#header.if-match" id="rfc.xref.header.if-match.1" title="If-Match">Section 6.2</a>), If-None-Match (<a href="#header.if-none-match" id="rfc.xref.header.if-none-match.1" title="If-None-Match">Section 6.4</a>), and If-Range (<a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) header fields. The definition of how they are used and compared as cache validators is in <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a>. An entitytag consists of an opaque quoted string, possibly prefixed by a weakness indicator.631 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="entity.tags" href="#entity.tags">Entity-Tags</a></h1> 632 <p id="rfc.section.2.p.1">Entity-tags are used for comparing two or more representations from the same requested resource. HTTP/1.1 uses entity-tags 633 in the ETag (<a href="#header.etag" id="rfc.xref.header.etag.1" title="ETag">Section 6.1</a>), If-Match (<a href="#header.if-match" id="rfc.xref.header.if-match.1" title="If-Match">Section 6.2</a>), If-None-Match (<a href="#header.if-none-match" id="rfc.xref.header.if-none-match.1" title="If-None-Match">Section 6.4</a>), and If-Range (<a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) header fields. The definition of how they are used and compared as cache validators is in <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a>. An entity-tag consists of an opaque quoted string, possibly prefixed by a weakness indicator. 634 634 </p> 635 635 <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span><span id="rfc.iref.g.3"></span> <a href="#entity.tags" class="smpl">entity-tag</a> = [ <a href="#entity.tags" class="smpl">weak</a> ] <a href="#entity.tags" class="smpl">opaque-tag</a> 636 636 <a href="#entity.tags" class="smpl">weak</a> = %x57.2F ; "W/", case-sensitive 637 637 <a href="#entity.tags" class="smpl">opaque-tag</a> = <a href="#core.rules" class="smpl">quoted-string</a> 638 </pre><p id="rfc.section.2.p.3">A "strong entity tag" <em class="bcp14">MAY</em> be shared by two entities of a resource only if they are equivalent by octet equality.639 </p> 640 <p id="rfc.section.2.p.4">A "weak entity tag," indicated by the "W/" prefix, <em class="bcp14">MAY</em> be shared by two entities of a resource only if the entities are equivalent and could be substituted for each other with no641 significant change in semantics. A weak entitytag can only be used for weak comparison.642 </p> 643 <p id="rfc.section.2.p.5">An entity tag <em class="bcp14">MUST</em> be unique across all versions of all entities associated with a particular resource. A given entity tag value <em class="bcp14">MAY</em> be used for entities obtained by requests on different URIs. The use of the same entity tag value in conjunction with entities644 obtained by requests on different URIs does not imply the equivalence of those entities.645 </p> 646 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> <a id="example.entity.tag.vs.conneg" href="#example.entity.tag.vs.conneg">Example: Entity Tags varying on Content-Negotiated Resources</a></h2>638 </pre><p id="rfc.section.2.p.3">A "strong entity-tag" <em class="bcp14">MAY</em> be shared by two representations of a resource only if they are equivalent by octet equality. 639 </p> 640 <p id="rfc.section.2.p.4">A "weak entity-tag," indicated by the "W/" prefix, <em class="bcp14">MAY</em> be shared by two representations of a resource only if the representations are equivalent and could be substituted for each 641 other with no significant change in semantics. A weak entity-tag can only be used for weak comparison. 642 </p> 643 <p id="rfc.section.2.p.5">An entity-tag <em class="bcp14">MUST</em> be unique across all versions of all representations associated with a particular resource. A given entity-tag value <em class="bcp14">MAY</em> be used for representations obtained by requests on different URIs. The use of the same entity-tag value in conjunction with 644 representations obtained by requests on different URIs does not imply the equivalence of those representations. 645 </p> 646 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> <a id="example.entity.tag.vs.conneg" href="#example.entity.tag.vs.conneg">Example: Entity-tags varying on Content-Negotiated Resources</a></h2> 647 647 <p id="rfc.section.2.1.p.1">Consider a resource that is subject to content negotiation (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 4</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), and where the representations returned upon a GET request vary based on the Accept-Encoding request header field (<a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 5.3</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>): 648 648 </p> … … 677 677 678 678 <em>...binary data...</em></pre><div class="note" id="rfc.section.2.1.p.7"> 679 <p> <b>Note:</b> Content codings are a property of the representation, so therefore an entity 679 <p> <b>Note:</b> Content codings are a property of the representation, so therefore an entity-tag of an encoded representation must be distinct 680 680 from an unencoded representation to prevent conflicts during cache updates and range requests. In contrast, transfer codings 681 (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) apply only during message transfer and do not require distinct entity 681 (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) apply only during message transfer and do not require distinct entity-tags. 682 682 </p> 683 683 </div> … … 717 717 changes is a "weak validator." 718 718 </p> 719 <p id="rfc.section.4.p.3"> Entity tags are normally "strong validators," but the protocol provides a mechanism to tag an entitytag as "weak." One can719 <p id="rfc.section.4.p.3">An entity-tag is normally a strong validator, but the protocol provides a mechanism to tag an entity-tag as "weak." One can 720 720 think of a strong validator as one that changes whenever the sequence of bits in a representation changes, while a weak value 721 721 changes whenever the meaning of a representation changes. Alternatively, one can think of a strong validator as part of an … … 726 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 727 </li> 728 <li>A n entity's modification time, if defined with only one-second resolution, could be a weak validator, since it is possible728 <li>A representation's modification time, if defined with only one-second resolution, could be a weak validator, since it is possible 729 729 that the representation might be modified twice during a single second. 730 730 </li> … … 752 752 </li> 753 753 </ul> 754 <p id="rfc.section.4.p.8">The example below shows the results for a set of entity 754 <p id="rfc.section.4.p.8">The example below shows the results for a set of entity-tag pairs, and both the weak and strong comparison function results:</p> 755 755 <div id="rfc.table.u.1"> 756 756 <table class="tt full left" cellpadding="3" cellspacing="0"> … … 791 791 </table> 792 792 </div> 793 <p id="rfc.section.4.p.9">An entity tag is strong unless it is explicitly tagged as weak. <a href="#entity.tags" title="Entity Tags">Section 2</a> gives the syntax for entitytags.793 <p id="rfc.section.4.p.9">An entity-tag is strong unless it is explicitly tagged as weak. <a href="#entity.tags" title="Entity-Tags">Section 2</a> gives the syntax for entity-tags. 794 794 </p> 795 795 <p id="rfc.section.4.p.10">A Last-Modified time, when used as a validator in a request, is implicitly weak unless it is possible to deduce that it is … … 831 831 HTTP/1.0 servers. 832 832 </p> 833 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="rules.for.when.to.use.entity.tags.and.last-modified.dates" href="#rules.for.when.to.use.entity.tags.and.last-modified.dates">Rules for When to Use Entity Tags and Last-Modified Dates</a></h1>833 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="rules.for.when.to.use.entity.tags.and.last-modified.dates" href="#rules.for.when.to.use.entity.tags.and.last-modified.dates">Rules for When to Use Entity-tags and Last-Modified Dates</a></h1> 834 834 <p id="rfc.section.5.p.1">We adopt a set of rules and recommendations for origin servers, clients, and caches regarding when various validator types 835 835 ought to be used, and for what purposes. … … 837 837 <p id="rfc.section.5.p.2">HTTP/1.1 origin servers: </p> 838 838 <ul> 839 <li><em class="bcp14">SHOULD</em> send an entity 840 </li> 841 <li><em class="bcp14">MAY</em> send a weak entity tag instead of a strong entity tag, if performance considerations support the use of weak entitytags,842 or if it is unfeasible to send a strong entity 839 <li><em class="bcp14">SHOULD</em> send an entity-tag validator unless it is not feasible to generate one. 840 </li> 841 <li><em class="bcp14">MAY</em> send a weak entity-tag instead of a strong entity-tag, if performance considerations support the use of weak entity-tags, 842 or if it is unfeasible to send a strong entity-tag. 843 843 </li> 844 844 <li><em class="bcp14">SHOULD</em> send a Last-Modified value if it is feasible to send one, unless the risk of a breakdown in semantic transparency that could … … 846 846 </li> 847 847 </ul> 848 <p id="rfc.section.5.p.3">In other words, the preferred behavior for an HTTP/1.1 origin server is to send both a strong entity 848 <p id="rfc.section.5.p.3">In other words, the preferred behavior for an HTTP/1.1 origin server is to send both a strong entity-tag and a Last-Modified 849 849 value. 850 850 </p> 851 <p id="rfc.section.5.p.4">In order to be legal, a strong entity tag <em class="bcp14">MUST</em> change whenever the associated entity changes in any way. A weak entity tag <em class="bcp14">SHOULD</em> change whenever the associated entitychanges in a semantically significant way.851 <p id="rfc.section.5.p.4">In order to be legal, a strong entity-tag <em class="bcp14">MUST</em> change whenever the associated representation changes in any way. A weak entity-tag <em class="bcp14">SHOULD</em> change whenever the associated representation changes in a semantically significant way. 852 852 </p> 853 853 <div class="note" id="rfc.section.5.p.5"> 854 <p> <b>Note:</b> In order to provide semantically transparent caching, an origin server must avoid reusing a specific strong entity tag value 855 for two different entities, or reusing a specific weak entity tag value for two semantically different entities. Cache entries 856 might persist for arbitrarily long periods, regardless of expiration times, so it might be inappropriate to expect that a 857 cache will never again attempt to validate an entry using a validator that it obtained at some point in the past. 854 <p> <b>Note:</b> In order to provide semantically transparent caching, an origin server must avoid reusing a specific strong entity-tag value 855 for two different representations, or reusing a specific weak entity-tag value for two semantically different representations. 856 Cache entries might persist for arbitrarily long periods, regardless of expiration times, so it might be inappropriate to 857 expect that a cache will never again attempt to validate an entry using a validator that it obtained at some point in the 858 past. 858 859 </p> 859 860 </div> 860 861 <p id="rfc.section.5.p.6">HTTP/1.1 clients: </p> 861 862 <ul> 862 <li><em class="bcp14">MUST</em> use that entity tag in any cache-conditional request (using If-Match or If-None-Match) if an entitytag has been provided863 <li><em class="bcp14">MUST</em> use that entity-tag in any cache-conditional request (using If-Match or If-None-Match) if an entity-tag has been provided 863 864 by the origin server. 864 865 </li> … … 869 870 has been provided by an HTTP/1.0 origin server. The user agent <em class="bcp14">SHOULD</em> provide a way to disable this, in case of difficulty. 870 871 </li> 871 <li><em class="bcp14">SHOULD</em> use both validators in cache-conditional requests if both an entity 872 <li><em class="bcp14">SHOULD</em> use both validators in cache-conditional requests if both an entity-tag and a Last-Modified value have been provided by the 872 873 origin server. This allows both HTTP/1.0 and HTTP/1.1 caches to respond appropriately. 873 874 </li> 874 875 </ul> 875 876 <p id="rfc.section.5.p.7">An HTTP/1.1 origin server, upon receiving a conditional request that includes both a Last-Modified date (e.g., in an If-Modified-Since 876 or If-Unmodified-Since header field) and one or more entity 877 or If-Unmodified-Since header field) and one or more entity-tags (e.g., in an If-Match, If-None-Match, or If-Range header 877 878 field) as cache validators, <em class="bcp14">MUST NOT</em> return a response status of 304 (Not Modified) unless doing so is consistent with all of the conditional header fields in 878 879 the request. 879 880 </p> 880 <p id="rfc.section.5.p.8">An HTTP/1.1 caching proxy, upon receiving a conditional request that includes both a Last-Modified date and one or more entity 881 tagsas cache validators, <em class="bcp14">MUST NOT</em> return a locally cached response to the client unless that cached response is consistent with all of the conditional header881 <p id="rfc.section.5.p.8">An HTTP/1.1 caching proxy, upon receiving a conditional request that includes both a Last-Modified date and one or more entity-tags 882 as cache validators, <em class="bcp14">MUST NOT</em> return a locally cached response to the client unless that cached response is consistent with all of the conditional header 882 883 fields in the request. 883 884 </p> … … 887 888 assumptions about the validators they receive. 888 889 </li> 889 <li>HTTP/1.0 clients and caches will ignore entity 890 <li>HTTP/1.0 clients and caches will ignore entity-tags. Generally, last-modified values received or used by these systems will 890 891 support transparent and efficient caching, and so HTTP/1.1 origin servers should provide Last-Modified values. In those rare 891 892 cases where the use of a Last-Modified value as a validator by an HTTP/1.0 system could result in a serious problem, then … … 901 902 <div id="rfc.iref.h.1"></div> 902 903 <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="header.etag" href="#header.etag">ETag</a></h2> 903 <p id="rfc.section.6.1.p.1">The "ETag" response-header field provides the current value of the entity tag (see <a href="#entity.tags" title="Entity Tags">Section 2</a>) for one representation of the resource identified by the Effective Request URI. An entitytag is intended for use as a resource-local904 <p id="rfc.section.6.1.p.1">The "ETag" response-header field provides the current value of the entity-tag (see <a href="#entity.tags" title="Entity-Tags">Section 2</a>) for one representation of the resource identified by the Effective Request URI. An entity-tag is intended for use as a resource-local 904 905 identifier for differentiating between representations of the same resource that vary over time or via content negotiation 905 906 (see <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a>). … … 911 912 ETag: W/"xyzzy" 912 913 ETag: "" 913 </pre><p id="rfc.section.6.1.p.4">An entity 914 </pre><p id="rfc.section.6.1.p.4">An entity-tag provides an "opaque" cache validator that allows for more reliable validation than modification dates in situations 914 915 where it is inconvenient to store modification dates, where the one-second resolution of HTTP date values is not sufficient, 915 916 or where the origin server wishes to avoid certain paradoxes that might arise from the use of modification dates. 916 917 </p> 917 <p id="rfc.section.6.1.p.5">The principle behind entity 918 <p id="rfc.section.6.1.p.5">The principle behind entity-tags is that only the service author knows the semantics of a resource well enough to select an 918 919 appropriate cache validation mechanism, and the specification of any validator comparison function more complex than byte-equality 919 920 would open up a can of worms. Thus, comparisons of any other headers (except Last-Modified, for compatibility with HTTP/1.0) … … 923 924 <div id="rfc.iref.h.2"></div> 924 925 <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a> <a id="header.if-match" href="#header.if-match">If-Match</a></h2> 925 <p id="rfc.section.6.2.p.1">The "If-Match" request-header field is used to make a request method conditional. A client that has one or more entities previously926 obtained from the resource can verify that one of those entities is current by including a list of their associated entity927 tags in the If-Match header field.926 <p id="rfc.section.6.2.p.1">The "If-Match" request-header field is used to make a request method conditional. A client that has one or more representations 927 previously obtained from the resource can verify that one of those representations is current by including a list of their 928 associated entity-tags in the If-Match header field. 928 929 </p> 929 930 <p id="rfc.section.6.2.p.2">This allows efficient updates of cached information with a minimum amount of transaction overhead. It is also used when updating 930 931 resources, to prevent inadvertent modification of the wrong version of a resource. As a special case, the value "*" matches 931 any current entityof the resource.932 any current representation of the resource. 932 933 </p> 933 934 <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> 934 935 <a href="#header.if-match" class="smpl">If-Match-v</a> = "*" / 1#<a href="#entity.tags" class="smpl">entity-tag</a> 935 </pre><p id="rfc.section.6.2.p.4">If any of the entity tags match the entitytag of the representation that would have been returned in the response to a similar936 GET request (without the If-Match header) on that resource, or if "*" is given and any current entity exists for that resource,937 then the server <em class="bcp14">MAY</em> perform the requested method as if the If-Match header field did not exist.938 </p> 939 <p id="rfc.section.6.2.p.5">If none of the entity 936 </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 937 GET request (without the If-Match header) on that resource, or if "*" is given and any current representation exists for that 938 resource, then the server <em class="bcp14">MAY</em> perform the requested method as if the If-Match header field did not exist. 939 </p> 940 <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, 940 941 such as PUT, from modifying a resource that has changed since the client last retrieved it. 941 942 </p> … … 945 946 <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. 946 947 </p> 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 948 <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 949 that resource. This allows the user to indicate that they do not wish the request to be successful if the resource has been 949 950 changed without their knowledge. Examples: … … 1007 1008 <div id="rfc.iref.h.4"></div> 1008 1009 <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a> <a id="header.if-none-match" href="#header.if-none-match">If-None-Match</a></h2> 1009 <p id="rfc.section.6.4.p.1">The "If-None-Match" request-header field is used to make a request method conditional. A client that has one or more entities1010 previously obtained from the resource can verify that none of those entities is current by including a list of their associated1011 entitytags in the If-None-Match header field.1010 <p id="rfc.section.6.4.p.1">The "If-None-Match" request-header field is used to make a request method conditional. A client that has one or more representations 1011 previously obtained from the resource can verify that none of those representations is current by including a list of their 1012 associated entity-tags in the If-None-Match header field. 1012 1013 </p> 1013 1014 <p id="rfc.section.6.4.p.2">This allows efficient updates of cached information with a minimum amount of transaction overhead. It is also used to prevent … … 1015 1016 exist. 1016 1017 </p> 1017 <p id="rfc.section.6.4.p.3">As a special case, the value "*" matches any current entityof the resource.</p>1018 <p id="rfc.section.6.4.p.3">As a special case, the value "*" matches any current representation of the resource.</p> 1018 1019 <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> 1019 1020 <a href="#header.if-none-match" class="smpl">If-None-Match-v</a> = "*" / 1#<a href="#entity.tags" class="smpl">entity-tag</a> 1020 </pre><p id="rfc.section.6.4.p.5">If any of the entity tags match the entitytag of the representation that would have been returned in the response to a similar1021 </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 1022 GET request (without the If-None-Match header) on that resource, or if "*" is given and any current representation exists 1022 1023 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 … … 1024 1025 that matched. For all other request methods, the server <em class="bcp14">MUST</em> respond with a status of 412 (Precondition Failed). 1025 1026 </p> 1026 <p id="rfc.section.6.4.p.6">If none of the entity tags match, then the server <em class="bcp14">MAY</em> perform the requested method as if the If-None-Match header field did not exist, but <em class="bcp14">MUST</em> also ignore any If-Modified-Since header field(s) in the request. That is, if no entitytags match, then the server <em class="bcp14">MUST NOT</em> return a 304 (Not Modified) response.1027 <p id="rfc.section.6.4.p.6">If none of the entity-tags match, then the server <em class="bcp14">MAY</em> perform the requested method as if the If-None-Match header field did not exist, but <em class="bcp14">MUST</em> also ignore any If-Modified-Since header field(s) in the request. That is, if no entity-tags match, then the server <em class="bcp14">MUST NOT</em> return a 304 (Not Modified) response. 1027 1028 </p> 1028 1029 <p id="rfc.section.6.4.p.7">If the request would, without the If-None-Match header field, result in anything other than a 2xx or 304 status, then the 1029 If-None-Match header <em class="bcp14">MUST</em> be ignored. (See <a href="#rules.for.when.to.use.entity.tags.and.last-modified.dates" title="Rules for When to Use Entity Tags and Last-Modified Dates">Section 5</a> for a discussion of server behavior when both If-Modified-Since and If-None-Match appear in the same request.)1030 If-None-Match header <em class="bcp14">MUST</em> be ignored. (See <a href="#rules.for.when.to.use.entity.tags.and.last-modified.dates" title="Rules for When to Use Entity-tags and Last-Modified Dates">Section 5</a> for a discussion of server behavior when both If-Modified-Since and If-None-Match appear in the same request.) 1030 1031 </p> 1031 1032 <p id="rfc.section.6.4.p.8">The meaning of "If-None-Match: *" is that the method <em class="bcp14">MUST NOT</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.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">SHOULD</em> be performed if the representation does not exist. This feature is intended to be useful in preventing races between PUT operations. … … 1072 1073 <div id="rfc.figure.u.18"></div><pre class="text"> Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT 1073 1074 </pre><p id="rfc.section.6.6.p.5">The exact meaning of this header field depends on the implementation of the origin server and the nature of the original resource. 1074 For files, it may be just the file system last-modified time. For entities with dynamically included parts, it may be the1075 most recent of the set of last-modify times for its component parts. For database gateways, it may be the last-update time1076 stamp of the record. For virtual objects, it may be the last time the internal state changed.1075 For files, it may be just the file system last-modified time. For representations with dynamically included parts, it may 1076 be the most recent of the set of last-modify times for its component parts. For database gateways, it may be the last-update 1077 time stamp of the record. For virtual objects, it may be the last time the internal state changed. 1077 1078 </p> 1078 1079 <p id="rfc.section.6.6.p.6">An origin server <em class="bcp14">MUST NOT</em> send a Last-Modified date which is later than the server's time of message origination. In such cases, where the resource's … … 1080 1081 </p> 1081 1082 <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 the1083 representation changes near the time that the response is generated.1083 its response. This allows a recipient to make an accurate assessment of the representation's modification time, especially 1084 if the representation changes near the time that the response is generated. 1084 1085 </p> 1085 1086 <p id="rfc.section.6.6.p.8">HTTP/1.1 servers <em class="bcp14">SHOULD</em> send Last-Modified whenever feasible. … … 1253 1254 <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a> <a id="compatibility" href="#compatibility">Compatibility with Previous Versions</a></h1> 1254 1255 <h2 id="rfc.section.A.1"><a href="#rfc.section.A.1">A.1</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2> 1255 <p id="rfc.section.A.1.p.1">Allow weak entity 1256 <p id="rfc.section.A.1.p.1">Allow weak entity-tags in all requests except range requests (Sections <a href="#weak.and.strong.validators" title="Weak and Strong Validators">4</a> and <a href="#header.if-none-match" id="rfc.xref.header.if-none-match.3" title="If-None-Match">6.4</a>). 1256 1257 </p> 1257 1258 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> -
draft-ietf-httpbis/latest/p5-range.html
r868 r875 630 630 <p id="rfc.section.1.2.2.p.1">The ABNF rules below are defined in other parts:</p> 631 631 <div id="rfc.figure.u.2"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">HTTP-date</a> = <HTTP-date, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a>> 632 </pre><div id="rfc.figure.u.3"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">entity-tag</a> = <entity-tag, defined in <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#entity.tags" title="Entity 632 </pre><div id="rfc.figure.u.3"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">entity-tag</a> = <entity-tag, defined in <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#entity.tags" title="Entity-Tags">Section 2</a>> 633 633 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="range.units" href="#range.units">Range Units</a></h1> 634 <p id="rfc.section.2.p.1">HTTP/1.1 allows a client to request that only part (a range of) the re sponse entitybe included within the response. HTTP/1.1635 uses range units in the Range (<a href="#header.range" id="rfc.xref.header.range.1" title="Range">Section 5.4</a>) and Content-Range (<a href="#header.content-range" id="rfc.xref.header.content-range.1" title="Content-Range">Section 5.2</a>) header fields. A n entitycan be broken down into subranges according to various structural units.634 <p id="rfc.section.2.p.1">HTTP/1.1 allows a client to request that only part (a range of) the representation be included within the response. HTTP/1.1 635 uses range units in the Range (<a href="#header.range" id="rfc.xref.header.range.1" title="Range">Section 5.4</a>) and Content-Range (<a href="#header.content-range" id="rfc.xref.header.content-range.1" title="Content-Range">Section 5.2</a>) header fields. A representation can be broken down into subranges according to various structural units. 636 636 </p> 637 637 <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span><span id="rfc.iref.g.3"></span> <a href="#range.units" class="smpl">range-unit</a> = <a href="#range.units" class="smpl">bytes-unit</a> / <a href="#range.units" class="smpl">other-range-unit</a> … … 677 677 </p> 678 678 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="combining.byte.ranges" href="#combining.byte.ranges">Combining Ranges</a></h1> 679 <p id="rfc.section.4.p.1">A response might transfer only a subrange of a n entity-body, either because the request included one or more Range specifications,680 or because a connection was broken prematurely. After several such transfers, a cache might have received several ranges of681 the same entity-body.679 <p id="rfc.section.4.p.1">A response might transfer only a subrange of a representation, either because the request included one or more Range specifications, 680 or because a connection closed prematurely. After several such transfers, a cache might have received several ranges of the 681 same representation. 682 682 </p> 683 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, … … 716 716 <div id="rfc.iref.h.2"></div> 717 717 <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a> <a id="header.content-range" href="#header.content-range">Content-Range</a></h2> 718 <p id="rfc.section.5.2.p.1">The "Content-Range" entity-header field is sent with a partial entity-body to specify where in the full entity-body the partial719 body should be applied. Range units are defined in <a href="#range.units" title="Range Units">Section 2</a>.718 <p id="rfc.section.5.2.p.1">The "Content-Range" entity-header field is sent with a partial representation to specify where in the full representation 719 the partial body should be applied. Range units are defined in <a href="#range.units" title="Range Units">Section 2</a>. 720 720 </p> 721 721 <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.7"></span><span id="rfc.iref.g.8"></span><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span> <a href="#header.content-range" class="smpl">Content-Range</a> = "Content-Range" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-range" class="smpl">Content-Range-v</a> … … 736 736 <a href="#header.content-range" class="smpl">other-range-resp-spec</a> 737 737 <a href="#header.content-range" class="smpl">other-range-resp-spec</a> = *<a href="#notation" class="smpl">CHAR</a> 738 </pre><p id="rfc.section.5.2.p.3">The header <em class="bcp14">SHOULD</em> indicate the total length of the full entity-body, unless this length is unknown or difficult to determine. The asterisk "*"739 character means that the instance-length is unknown at the time when the response was generated.738 </pre><p id="rfc.section.5.2.p.3">The header <em class="bcp14">SHOULD</em> indicate the total length of the full representation, unless this length is unknown or difficult to determine. The asterisk 739 "*" character means that the instance-length is unknown at the time when the response was generated. 740 740 </p> 741 741 <p id="rfc.section.5.2.p.4">Unlike byte-ranges-specifier values (see <a href="#byte.ranges" title="Byte Ranges">Section 5.4.1</a>), a byte-range-resp-spec <em class="bcp14">MUST</em> only specify one range, and <em class="bcp14">MUST</em> contain absolute byte positions for both the first and last byte of the range. … … 781 781 </p> 782 782 <p id="rfc.section.5.2.p.13">If the server ignores a byte-range-spec because it is syntactically invalid, the server <em class="bcp14">SHOULD</em> treat the request as if the invalid Range header field did not exist. (Normally, this means return a 200 response containing 783 the full entity).783 the full representation). 784 784 </p> 785 785 <p id="rfc.section.5.2.p.14">If the server receives a request (other than one including an If-Range request-header field) with an unsatisfiable Range request-header … … 795 795 <div id="rfc.iref.h.3"></div> 796 796 <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a> <a id="header.if-range" href="#header.if-range">If-Range</a></h2> 797 <p id="rfc.section.5.3.p.1">If a client has a partial copy of a n entity in its cache, and wishes to have an up-to-date copy of the entire entity in its798 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 representation has been modified, the client would then have to make a second800 request to obtain the entire current representation.797 <p id="rfc.section.5.3.p.1">If a client has a partial copy of a representation in its cache, and wishes to have an up-to-date copy of the entire representation 798 in its cache, it could use the Range request-header with a conditional GET (using either or both of If-Unmodified-Since and 799 If-Match.) However, if the condition fails because the representation has been modified, the client would then have to make 800 a second 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 … … 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 807 </pre><p id="rfc.section.5.3.p.4">If the client has no entity-tag for a representation, but does have a Last-Modified date, it <em class="bcp14">MAY</em> use that date in an If-Range header. (The server can distinguish between a valid HTTP-date and any form of entity-tag by examining 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 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 811 not match, then the server <em class="bcp14">SHOULD</em> return the entire representation using a 200 (OK) response. 812 812 </p> … … 844 844 <a href="#rule.ranges-specifier" class="smpl">suffix-length</a> = 1*<a href="#notation" class="smpl">DIGIT</a> 845 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 a n entity-body.) If the representation is shorter than the specified846 value. (That is, this form specifies the last N bytes of a representation.) If the representation is shorter than the specified 847 847 suffix-length, the entire representation is used. 848 848 </p> 849 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 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 is851 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.852 </p> 853 <p id="rfc.section.5.4.1.p.12">Examples of byte-ranges-specifier values (assuming a n entity-bodyof length 10000): </p>850 length of the representation, or at least one suffix-byte-range-spec with a non-zero suffix-length, then the byte-range-set 851 is 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. 852 </p> 853 <p id="rfc.section.5.4.1.p.12">Examples of byte-ranges-specifier values (assuming a representation of length 10000): </p> 854 854 <ul> 855 855 <li>The first 500 bytes (byte offsets 0-499, inclusive): … … 882 882 </pre><p id="rfc.section.5.4.2.p.3">A server <em class="bcp14">MAY</em> ignore the Range header. However, HTTP/1.1 origin servers and intermediate caches ought to support byte ranges when possible, 883 883 since Range supports efficient recovery from partially failed transfers, and supports efficient partial retrieval of large 884 entities.885 </p> 886 <p id="rfc.section.5.4.2.p.4">If the server supports the Range header and the specified range or ranges are appropriate for the entity: </p>884 representations. 885 </p> 886 <p id="rfc.section.5.4.2.p.4">If the server supports the Range header and the specified range or ranges are appropriate for the representation: </p> 887 887 <ul> 888 888 <li>The presence of a Range header in an unconditional GET modifies what is returned if the GET is otherwise successful. In other … … 897 897 </p> 898 898 <p id="rfc.section.5.4.2.p.6">If a proxy that supports ranges receives a Range request, forwards the request to an inbound server, and receives an entire 899 entityin reply, it <em class="bcp14">SHOULD</em> only return the requested range to its client. It <em class="bcp14">SHOULD</em> store the entire received response in its cache if that is consistent with its cache allocation policies.899 representation in reply, it <em class="bcp14">SHOULD</em> only return the requested range to its client. It <em class="bcp14">SHOULD</em> store the entire received response in its cache if that is consistent with its cache allocation policies. 900 900 </p> 901 901 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> -
draft-ietf-httpbis/latest/p6-cache.html
r868 r875 645 645 </p> 646 646 <ul class="empty"> 647 <li>The time at which the origin server intends that an entity should no longer be returned by a cache without further validation.</li> 647 <li>The time at which the origin server intends that a representation should no longer be returned by a cache without further 648 validation. 649 </li> 648 650 </ul> 649 651 <p id="rfc.section.1.2.p.4"> <span id="rfc.iref.h.1"></span> <dfn>heuristic expiration time</dfn> … … 680 682 </p> 681 683 <ul class="empty"> 682 <li>A protocol element (e.g., an entity 684 <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 685 equivalent copy of a representation. 684 686 </li> … … 1018 1020 <p id="rfc.section.2.8.p.5">If a header field-name in the new response matches more than one header in the stored response, all such stored headers <em class="bcp14">MUST</em> be replaced. 1019 1021 </p> 1020 <p id="rfc.section.2.8.p.6">The updated response can <span class="comment" id="TODO-is-req">[<a href="#TODO-is-req" class="smpl">TODO-is-req</a>: requirement?]</span> be used to replace the stored response in cache. In the case of a 206 response, the combined entity-body<em class="bcp14">MAY</em> be stored.1022 <p id="rfc.section.2.8.p.6">The updated response can <span class="comment" id="TODO-is-req">[<a href="#TODO-is-req" class="smpl">TODO-is-req</a>: requirement?]</span> be used to replace the stored response in cache. In the case of a 206 response, the combined representation <em class="bcp14">MAY</em> be stored. 1021 1023 </p> 1022 1024 <p id="rfc.section.2.8.p.7"> <span class="comment" id="ISSUE-how-head">[<a href="#ISSUE-how-head" class="smpl">ISSUE-how-head</a>: discuss how to handle HEAD updates]</span> … … 1121 1123 </p> 1122 1124 <ul class="empty"> 1123 <li>The no-transform request directive indicates that an intermediate cache or proxy <em class="bcp14">MUST NOT</em> change the Content-Encoding, Content-Range or Content-Type request headers, nor the request entity-body.1125 <li>The no-transform request directive indicates that an intermediate cache or proxy <em class="bcp14">MUST NOT</em> change the Content-Encoding, Content-Range or Content-Type request headers, nor the request representation. 1124 1126 </li> 1125 1127 </ul> … … 1225 1227 </p> 1226 1228 <ul class="empty"> 1227 <li>The no-transform response directive indicates that an intermediate cache or proxy <em class="bcp14">MUST NOT</em> change the Content-Encoding, Content-Range or Content-Type response headers, nor the response entity-body.1229 <li>The no-transform response directive indicates that an intermediate cache or proxy <em class="bcp14">MUST NOT</em> change the Content-Encoding, Content-Range or Content-Type response headers, nor the response representation. 1228 1230 </li> 1229 1231 </ul> … … 1412 1414 <p id="rfc.section.3.6.p.17"> 214 Transformation applied </p> 1413 1415 <ul class="empty"> 1414 <li><em class="bcp14">MUST</em> be added by an intermediate cache or proxy if it applies any transformation changing the content-coding (as specified in the 1415 Content-Encoding header) or media-type (as specified in the Content-Type header) of the response, or the entity-body of the 1416 response, unless this Warning code already appears in the response. 1416 <li><em class="bcp14">MUST</em> be added by an intermediate proxy if it applies any transformation to the representation, such as changing the content-coding, 1417 media-type, or modifying the representation data, unless this Warning code already appears in the response. 1417 1418 </li> 1418 1419 </ul> … … 1423 1424 </ul> 1424 1425 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="history.lists" href="#history.lists">History Lists</a></h1> 1425 <p id="rfc.section.4.p.1">User agents often have history mechanisms, such as "Back" buttons and history lists, that can be used to redisplay a n entity1426 <p id="rfc.section.4.p.1">User agents often have history mechanisms, such as "Back" buttons and history lists, that can be used to redisplay a representation 1426 1427 retrieved earlier in a session. 1427 1428 </p> -
draft-ietf-httpbis/latest/p7-auth.html
r865 r875 620 620 <p id="rfc.section.2.1.p.1">The request requires user authentication. The response <em class="bcp14">MUST</em> include a WWW-Authenticate header field (<a href="#header.www-authenticate" id="rfc.xref.header.www-authenticate.1" title="WWW-Authenticate">Section 3.4</a>) containing a challenge applicable to the requested resource. The client <em class="bcp14">MAY</em> repeat the request with a suitable Authorization header field (<a href="#header.authorization" id="rfc.xref.header.authorization.1" title="Authorization">Section 3.1</a>). If the request already included Authorization credentials, then the 401 response indicates that authorization has been 621 621 refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has 622 already attempted authentication at least once, then the user <em class="bcp14">SHOULD</em> be presented the entity that was given in the response, since that entity might include relevant diagnostic information. HTTP623 access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617" id="rfc.xref.RFC2617.5"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>.622 already attempted authentication at least once, then the user <em class="bcp14">SHOULD</em> be presented the representation that was given in the response, since that representation might include relevant diagnostic 623 information. HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617" id="rfc.xref.RFC2617.5"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>. 624 624 </p> 625 625 <div id="rfc.iref.3"></div>
Note: See TracChangeset
for help on using the changeset viewer.