Changeset 874
- Timestamp:
- 23/07/10 05:43:26 (13 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 7 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r872 r874 22 22 <!ENTITY CONNECT "<xref target='Part2' x:rel='#CONNECT' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 23 23 <!ENTITY content.negotiation "<xref target='Part3' x:rel='#content.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 24 <!ENTITY diff-mime "<xref target='Part3' x:rel='#differences.between.http. entities.and.rfc.2045.entities' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">25 <!ENTITY entity "<xref target='Part3' x:rel='#entity' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">24 <!ENTITY diff-mime "<xref target='Part3' x:rel='#differences.between.http.and.mime' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 25 <!ENTITY representation "<xref target='Part3' x:rel='#representation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 26 26 <!ENTITY entity-header-fields "<xref target='Part3' x:rel='#entity.header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 27 27 <!ENTITY header-cache-control "<xref target='Part6' x:rel='#header.cache-control' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> -
draft-ietf-httpbis/latest/p2-semantics.xml
r867 r874 654 654 </section> 655 655 656 <section title="Representation" anchor=" entity">656 <section title="Representation" anchor="representation"> 657 657 <t> 658 658 Request and Response messages &MAY; transfer a representation if not otherwise … … 779 779 </t> 780 780 <t> 781 If the OPTIONS request includes a n entity-body (as indicated by the781 If the OPTIONS request includes a message-body (as indicated by the 782 782 presence of Content-Length or Transfer-Encoding), then the media type 783 783 &MUST; be indicated by a Content-Type field. Although this … … 833 833 <iref primary="true" item="Methods" subitem="GET" x:for-anchor=""/> 834 834 <t> 835 The GET method means retrieve whatever information (in the form of a n836 entity) currently corresponds to the resource identified by the835 The GET method means retrieve whatever information (in the form of a 836 representation) currently corresponds to the resource identified by the 837 837 Effective Request URI. 838 838 </t> … … 850 850 circumstances described by the conditional header field(s). The 851 851 conditional GET method is intended to reduce unnecessary network 852 usage by allowing cached entities to be refreshed without requiring852 usage by allowing cached representations to be refreshed without requiring 853 853 multiple requests or transferring data already held by the client. 854 854 </t> … … 889 889 The response to a HEAD request &MAY; be cacheable in the sense that the 890 890 information contained in the response &MAY; be used to update a 891 previously cached entityfrom that resource. If the new field values892 indicate that the cached entity differs from the current entity(as891 previously cached representation from that resource. If the new field values 892 indicate that the cached representation differs from the current representation (as 893 893 would be indicated by a change in Content-Length, Content-MD5, ETag 894 894 or Last-Modified), then the cache &MUST; treat the cache entry as … … 902 902 <t> 903 903 The POST method is used to request that the origin server accept the 904 entityenclosed in the request as data to be processed by the resource904 representation enclosed in the request as data to be processed by the resource 905 905 identified by the Effective Request URI. POST is designed 906 906 to allow a uniform method to cover the following functions: … … 930 930 resource that can be identified by a URI. In this case, either 200 931 931 (OK) or 204 (No Content) is the appropriate response status, 932 depending on whether or not the response includes a n entitythat932 depending on whether or not the response includes a representation that 933 933 describes the result. 934 934 </t> 935 935 <t> 936 936 If a resource has been created on the origin server, the response 937 &SHOULD; be 201 (Created) and contain a n entitywhich describes the937 &SHOULD; be 201 (Created) and contain a representation which describes the 938 938 status of the request and refers to the new resource, and a Location 939 939 header (see <xref target="header.location"/>). … … 1030 1030 <t> 1031 1031 A successful response &SHOULD; be 200 (OK) if the response includes an 1032 entitydescribing the status, 202 (Accepted) if the action has not1032 representation describing the status, 202 (Accepted) if the action has not 1033 1033 yet been enacted, or 204 (No Content) if the action has been enacted 1034 1034 but the response does not include a representation. … … 1036 1036 <t> 1037 1037 If the request passes through a cache and the Effective Request URI 1038 identifies one or more currently cached entities, those entries &SHOULD; be1039 treated as stale. Responses to th is method are not cacheable.1038 identifies one or more currently cached representations, those entries &SHOULD; be 1039 treated as stale. Responses to the DELETE method &MUST-NOT; be cached. 1040 1040 </t> 1041 1041 </section> … … 1051 1051 of the request message. The final recipient of the request 1052 1052 &SHOULD; reflect the message received back to the client as the 1053 entity-body of a 200 (OK) response. The final recipient is either the1053 message-body of a 200 (OK) response. The final recipient is either the 1054 1054 origin server or the first proxy or gateway to receive a Max-Forwards 1055 1055 value of zero (0) in the request (see <xref target="header.max-forwards"/>). … … 1066 1066 </t> 1067 1067 <t> 1068 If the request is valid, the response &SHOULD; contain the entire1069 request message in the entity-body, with a Content-Type of1070 "message/http" (see &media-type-message-http;). Responses to this method1071 &MUST-NOT; be cached.1068 If the request is valid, the response &SHOULD; have a Content-Type of 1069 "message/http" (see &media-type-message-http;) and contain a message-body 1070 that encloses a copy of the entire request message. 1071 Responses to the TRACE method &MUST-NOT; be cached. 1072 1072 </t> 1073 1073 </section> … … 1165 1165 <list style="hanging"> 1166 1166 <t hangText="GET"> 1167 a n entitycorresponding to the requested resource is sent in1167 a representation corresponding to the requested resource is sent in 1168 1168 the response; 1169 1169 </t> … … 1173 1173 </t> 1174 1174 <t hangText="POST"> 1175 a n entitydescribing or containing the result of the action;1175 a representation describing or containing the result of the action; 1176 1176 </t> 1177 1177 <t hangText="TRACE"> 1178 a n entitycontaining the request message as received by the1178 a representation containing the request message as received by the 1179 1179 end server. 1180 1180 </t> … … 1201 1201 <t> 1202 1202 A 201 response &MAY; contain an ETag response header field indicating 1203 the current value of the entity 1203 the current value of the entity-tag for the representation of the resource 1204 1204 just created (see &header-etag;). 1205 1205 </t> … … 1292 1292 <t> 1293 1293 The server has fulfilled the partial GET request for the resource 1294 and the enclosed entityis a partial representation as defined in &status-206;.1294 and the enclosed payload is a partial representation as defined in &status-206;. 1295 1295 </t> 1296 1296 </section> … … 1525 1525 The 4xx class of status code is intended for cases in which the 1526 1526 client seems to have erred. Except when responding to a HEAD request, 1527 the server &SHOULD; include a n entitycontaining an explanation of the1527 the server &SHOULD; include a representation containing an explanation of the 1528 1528 error situation, and whether it is a temporary or permanent 1529 1529 condition. These status codes are applicable to any request method. 1530 User agents &SHOULD; display any included entityto the user.1530 User agents &SHOULD; display any included representation to the user. 1531 1531 </t> 1532 1532 <t> … … 1614 1614 <t> 1615 1615 The resource identified by the request is only capable of generating 1616 response entities which have content characteristics not acceptable1616 response representations which have content characteristics not acceptable 1617 1617 according to the accept headers sent in the request. 1618 1618 </t> … … 1671 1671 and resubmit the request. The response body &SHOULD; include enough 1672 1672 information for the user to recognize the source of the conflict. 1673 Ideally, the response entitywould include enough information for the1673 Ideally, the response representation would include enough information for the 1674 1674 user or user agent to fix the problem; however, that might not be 1675 1675 possible and is not required. … … 1741 1741 <t> 1742 1742 The server is refusing to process a request because the request 1743 entityis larger than the server is willing or able to process. The1743 representation is larger than the server is willing or able to process. The 1744 1744 server &MAY; close the connection to prevent the client from continuing 1745 1745 the request. … … 1808 1808 which the server is aware that it has erred or is incapable of 1809 1809 performing the request. Except when responding to a HEAD request, the 1810 server &SHOULD; include a n entitycontaining an explanation of the1810 server &SHOULD; include a representation containing an explanation of the 1811 1811 error situation, and whether it is a temporary or permanent 1812 condition. User agents &SHOULD; display any included entityto the1812 condition. User agents &SHOULD; display any included representation to the 1813 1813 user. These response codes are applicable to any request method. 1814 1814 </t> … … 1890 1890 using the same major version as the client, as described in &http-version;, 1891 1891 other than with this error message. The response &SHOULD; contain 1892 a n entitydescribing why that version is not supported and what other1892 a representation describing why that version is not supported and what other 1893 1893 protocols are supported by that server. 1894 1894 </t> -
draft-ietf-httpbis/latest/p3-payload.xml
r867 r874 602 602 <section title="Canonicalization and Text Defaults" anchor="canonicalization.and.text.defaults"> 603 603 <t> 604 Internet media types are registered with a canonical form. A n605 entity-body transferred via HTTP messages &MUST; be representedin the604 Internet media types are registered with a canonical form. A 605 representation transferred via HTTP messages &MUST; be in the 606 606 appropriate canonical form prior to its transmission except for 607 607 "text" types, as defined in the next paragraph. … … 611 611 the text line break. HTTP relaxes this requirement and allows the 612 612 transport of text media with plain CR or LF alone representing a line 613 break when it is done consistently for an entire entity-body. HTTP614 applications &MUST; accept CRLF, bare CR, and bare LF as being615 representative ofa line break in text media received via HTTP. In616 addition, if the text is represented in a character setthat does not613 break when it is done consistently for an entire representation. HTTP 614 applications &MUST; accept CRLF, bare CR, and bare LF as indicating 615 a line break in text media received via HTTP. In 616 addition, if the text is in a character encoding that does not 617 617 use octets 13 and 10 for CR and LF respectively, as is the case for 618 some multi-byte character sets, HTTP allows the use of whatever octet619 sequences are defined by that character setto represent the618 some multi-byte character encodings, HTTP allows the use of whatever octet 619 sequences are defined by that character encoding to represent the 620 620 equivalent of CR and LF for line breaks. This flexibility regarding 621 line breaks applies only to text media in the entity-body; a bare CR621 line breaks applies only to text media in the payload body; a bare CR 622 622 or LF &MUST-NOT; be substituted for CRLF within any of the HTTP control 623 623 structures (such as header fields and multipart boundaries). 624 624 </t> 625 625 <t> 626 If a n entity-bodyis encoded with a content-coding, the underlying626 If a representation is encoded with a content-coding, the underlying 627 627 data &MUST; be in a form defined above prior to being encoded. 628 628 </t> 629 629 <t> 630 630 The "charset" parameter is used with some media types to define the 631 character set(<xref target="character.sets"/>) of the data. When no explicit charset631 character encoding (<xref target="character.sets"/>) of the data. When no explicit charset 632 632 parameter is provided by the sender, media subtypes of the "text" 633 633 type are defined to have a default charset value of "ISO-8859-1" when 634 received via HTTP. Data in character sets other than "ISO-8859-1" or634 received via HTTP. Data in character encodings other than "ISO-8859-1" or 635 635 its subsets &MUST; be labeled with an appropriate charset value. See 636 636 <xref target="missing.charset"/> for compatibility problems. … … 641 641 <t> 642 642 MIME provides for a number of "multipart" types -- encapsulations of 643 one or more entities within a single message-body. All multipart643 one or more representations within a single message-body. All multipart 644 644 types share a common syntax, as defined in <xref target="RFC2046" x:sec="5.1.1" x:fmt="of"/>, 645 645 and &MUST; include a boundary parameter as part of the media type … … 705 705 </section> 706 706 707 <section title=" Entity" anchor="entity">707 <section title="Representation" anchor="representation"> 708 708 <t> 709 709 Request and Response messages &MAY; transfer a representation if not otherwise … … 721 721 <x:anchor-alias value="extension-header"/> 722 722 <t> 723 Entity-header fields define metadata about the entity-body or, 724 if no body is present, about the resource identified by the request. 723 Entity-header fields define metadata about the representation data 724 enclosed in the message-body or, if no message-body is present, about 725 the representation that would have been transferred in a 200 response 726 to a simultaneous GET request on the Effective Request URI. 725 727 </t> 726 728 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="entity-header"/><iref primary="true" item="Grammar" subitem="extension-header"/> … … 747 749 </section> 748 750 749 <section title=" Entity Body" anchor="entity.body">750 <x:anchor-alias value=" entity-body"/>751 <t> 752 The entity-body (if any) sent with an HTTP request or response is in751 <section title="Payload Body" anchor="payload.body"> 752 <x:anchor-alias value="payload-body"/> 753 <t> 754 The payload body (if any) sent with an HTTP request or response is in 753 755 a format and encoding defined by the entity-header fields. 754 756 </t> 755 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="entity-body"/> 756 <x:ref>entity-body</x:ref> = *<x:ref>OCTET</x:ref> 757 </artwork></figure> 758 <t> 759 An entity-body is only present in a message when a message-body is 760 present, as described in &message-body;. The entity-body is obtained 757 <t> 758 A payload body is only present in a message when a message-body is 759 present, as described in &message-body;. The payload body is obtained 761 760 from the message-body by decoding any Transfer-Encoding that might 762 761 have been applied to ensure safe and proper transfer of the message. … … 765 764 <section title="Type" anchor="type"> 766 765 <t> 767 When a n entity-body is included with a message, the data type of that766 When a payload body is included with a message, the data type of that 768 767 body is determined via the header fields Content-Type and Content-Encoding. 769 768 These define a two-layer, ordered encoding model: 770 769 </t> 771 770 <figure><artwork type="example"> 772 entity-body := Content-Encoding( Content-Type( data ) )771 payload-body := Content-Encoding( Content-Type( data ) ) 773 772 </artwork></figure> 774 773 <t> 775 774 Content-Type specifies the media type of the underlying data. Any HTTP/1.1 776 message containing a n entity-body &SHOULD; include a Content-Type header775 message containing a payload body &SHOULD; include a Content-Type header 777 776 field defining the media type of that body, unless that information is 778 777 unknown. … … 791 790 </t> 792 791 <t> 793 Client that do so risk drawing incorrect conclusions, which may expose792 Clients that do so risk drawing incorrect conclusions, which may expose 794 793 additional security risks (e.g., "privilege escalation"). Implementers are 795 794 encouraged to provide a means of disabling such "content sniffing" when it … … 799 798 Content-Encoding may be used to indicate any additional content 800 799 codings applied to the data, usually for the purpose of data 801 compression, that are a property of the re quested resource. There is800 compression, that are a property of the representation. There is 802 801 no default encoding. 803 802 </t> … … 928 927 initial response from the origin server. Selection is based on a list 929 928 of the available representations of the response included within the 930 header fields or entity-body of the initial response, with each929 header fields or body of the initial response, with each 931 930 representation identified by its own URI. Selection from among the 932 931 representations may be performed automatically (if the user agent is … … 1342 1341 </t> 1343 1342 <t> 1344 If the content-coding of a n entityin a request message is not1343 If the content-coding of a representation in a request message is not 1345 1344 acceptable to the origin server, the server &SHOULD; respond with a 1346 1345 status code of 415 (Unsupported Media Type). … … 1362 1361 The "Content-Language" entity-header field describes the natural 1363 1362 language(s) of the intended audience for the representation. Note that this might 1364 not be equivalent to all the languages used within the entity-body.1363 not be equivalent to all the languages used within the representation. 1365 1364 </t> 1366 1365 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Language"/><iref primary="true" item="Grammar" subitem="Content-Language-v"/> … … 1504 1503 <t> 1505 1504 The "Content-MD5" entity-header field, as defined in <xref target="RFC1864"/>, is 1506 an MD5 digest of the entity-body that provides an end-to-end message 1507 integrity check (MIC) of the entity-body. Note that a MIC is good for 1508 detecting accidental modification of the entity-body in transit, but is not 1505 an MD5 digest of the payload body that provides an end-to-end message 1506 integrity check (MIC) of the payload body (the message-body after any 1507 transfer-coding is decoded). Note that a MIC is good for 1508 detecting accidental modification of the payload body in transit, but is not 1509 1509 proof against malicious attacks. 1510 1510 </t> … … 1515 1515 <t> 1516 1516 The Content-MD5 header field &MAY; be generated by an origin server or 1517 client to function as an integrity check of the entity-body. Only1518 origin servers or clients &MAY; generate the Content-MD5 header field;1517 client to function as an integrity check of the payload body. Only 1518 origin servers or user agents &MAY; generate the Content-MD5 header field; 1519 1519 proxies and gateways &MUST-NOT; generate it, as this would defeat its 1520 value as an end-to-end integrity check. Any recipient of the entity-body, 1521 including gateways and proxies, &MAY; check that the digest value 1522 in this header field matches that of the entity-body as received. 1523 </t> 1524 <t> 1525 The MD5 digest is computed based on the content of the entity-body, 1526 including any content-coding that has been applied, but not including 1527 any transfer-encoding applied to the message-body. If the message is 1528 received with a transfer-encoding, that encoding &MUST; be removed 1529 prior to checking the Content-MD5 value against the received representation. 1530 </t> 1531 <t> 1532 This has the result that the digest is computed on the octets of the 1533 entity-body exactly as, and in the order that, they would be sent if 1534 no transfer-encoding were being applied. 1520 value as an end-to-end integrity check. Any recipient &MAY; check that 1521 the digest value in this header field matches a corresponding digest 1522 calculated on payload body as received. 1523 </t> 1524 <t> 1525 The MD5 digest is computed based on the content of the payload body, 1526 including any content-coding, but not including any transfer-coding 1527 applied to the message-body because such transfer-codings might be 1528 applied or removed anywhere along the request/response chain. 1529 If the message is received with a transfer-coding, that encoding &MUST; 1530 be decoded prior to checking the Content-MD5 value against the received 1531 payload. 1535 1532 </t> 1536 1533 <t> … … 1541 1538 </t> 1542 1539 <t> 1543 There are several consequences of this. The entity-bodyfor composite1540 There are several consequences of this. The payload for composite 1544 1541 types &MAY; contain many body-parts, each with its own MIME and HTTP 1545 1542 headers (including Content-MD5, Content-Transfer-Encoding, and … … 1581 1578 <t> 1582 1579 The "Content-Type" entity-header field indicates the media type of the 1583 entity-body. In the case of responses to the HEAD method, the media type is1580 representation. In the case of responses to the HEAD method, the media type is 1584 1581 that which would have been sent had the request been a GET. 1585 1582 </t> … … 1595 1592 </artwork></figure> 1596 1593 <t> 1597 Further discussion of methods for identifying the media type of a n1598 entityis provided in <xref target="type"/>.1594 Further discussion of methods for identifying the media type of a 1595 representation is provided in <xref target="type"/>. 1599 1596 </t> 1600 1597 </section> … … 2534 2531 </references> 2535 2532 2536 <section title="Differences Between HTTP Entities and RFC 2045 Entities" anchor="differences.between.http.entities.and.rfc.2045.entities">2533 <section title="Differences between HTTP and MIME" anchor="differences.between.http.and.mime"> 2537 2534 <t> 2538 2535 HTTP/1.1 uses many of the constructs defined for Internet Mail (<xref target="RFC5322"/>) and the Multipurpose Internet Mail Extensions (MIME <xref target="RFC2045"/>) to 2539 allow entitiesto be transmitted in an open variety of2536 allow a message-body to be transmitted in an open variety of 2540 2537 representations and with extensible mechanisms. However, RFC 2045 2541 2538 discusses mail, and HTTP has a few features that are different from 2542 those described in RFC 2045. These differences were carefully chosen2539 those described in MIME. These differences were carefully chosen 2543 2540 to optimize performance over binary connections, to allow greater 2544 2541 freedom in the use of new media types, to make date comparisons … … 2547 2544 </t> 2548 2545 <t> 2549 This appendix describes specific areas where HTTP differs from RFC2550 2045.Proxies and gateways to strict MIME environments &SHOULD; be2546 This appendix describes specific areas where HTTP differs from MIME. 2547 Proxies and gateways to strict MIME environments &SHOULD; be 2551 2548 aware of these differences and provide the appropriate conversions 2552 2549 where necessary. Proxies and gateways from MIME environments to HTTP … … 2582 2579 <section title="Conversion to Canonical Form" anchor="conversion.to.canonical.form"> 2583 2580 <t> 2584 <xref target="RFC2045"/> requires that an Internet mail entitybe converted to2581 MIME requires that an Internet mail body-part be converted to 2585 2582 canonical form prior to being transferred, as described in <xref target="RFC2049" x:fmt="of" x:sec="4"/>. 2586 2583 <xref target="canonicalization.and.text.defaults"/> of this document describes the forms … … 2623 2620 <section title="Introduction of Content-Encoding" anchor="introduction.of.content-encoding"> 2624 2621 <t> 2625 RFC 2045does not include any concept equivalent to HTTP/1.1's2622 MIME does not include any concept equivalent to HTTP/1.1's 2626 2623 Content-Encoding header field. Since this acts as a modifier on the 2627 2624 media type, proxies and gateways from HTTP to MIME-compliant 2628 2625 protocols &MUST; either change the value of the Content-Type header 2629 field or decode the entity-bodybefore forwarding the message. (Some2626 field or decode the representation before forwarding the message. (Some 2630 2627 experimental applications of Content-Type for Internet mail have used 2631 2628 a media-type parameter of ";conversions=<content-coding>" to perform 2632 2629 a function equivalent to Content-Encoding. However, this parameter is 2633 not part of RFC 2045).2630 not part of the MIME standards). 2634 2631 </t> 2635 2632 </section> … … 2637 2634 <section title="No Content-Transfer-Encoding" anchor="no.content-transfer-encoding"> 2638 2635 <t> 2639 HTTP does not use the Content-Transfer-Encoding field of RFC2640 2045.Proxies and gateways from MIME-compliant protocols to HTTP &MUST;2636 HTTP does not use the Content-Transfer-Encoding field of MIME. 2637 Proxies and gateways from MIME-compliant protocols to HTTP &MUST; 2641 2638 remove any Content-Transfer-Encoding 2642 2639 prior to delivering the response message to an HTTP client. … … 2846 2843 <x:ref>disposition-type</x:ref> = "attachment" / disp-extension-token 2847 2844 2848 <x:ref>entity-body</x:ref> = *OCTET2849 2845 <x:ref>entity-header</x:ref> = Content-Encoding / Content-Language / Content-Length 2850 2846 / Content-Location / Content-MD5 / Content-Range / Content-Type / … … 2886 2882 ; MIME-Version defined but not used 2887 2883 ; content-disposition defined but not used 2888 ; entity-body defined but not used2889 2884 ; entity-header defined but not used 2890 2885 </artwork></figure></section> -
draft-ietf-httpbis/latest/p4-conditional.xml
r867 r874 307 307 </section> 308 308 309 <section title="Entity 309 <section title="Entity-Tags" anchor="entity.tags"> 310 310 <x:anchor-alias value="entity-tag"/> 311 311 <x:anchor-alias value="opaque-tag"/> 312 312 <x:anchor-alias value="weak"/> 313 313 <t> 314 Entity tags are used for comparing two or more entities from the same315 requested resource. HTTP/1.1 uses entity 314 Entity-tags are used for comparing two or more representations from the same 315 requested resource. HTTP/1.1 uses entity-tags in the ETag (<xref target="header.etag"/>), 316 316 If-Match (<xref target="header.if-match"/>), If-None-Match (<xref target="header.if-none-match"/>), and 317 317 If-Range (&header-if-range;) header fields. The definition of how they 318 318 are used and compared as cache validators is in <xref target="weak.and.strong.validators"/>. An 319 entity 319 entity-tag consists of an opaque quoted string, possibly prefixed by 320 320 a weakness indicator. 321 321 </t> … … 326 326 </artwork></figure> 327 327 <t> 328 A "strong entity tag" &MAY; be shared by two entities of a resource328 A "strong entity-tag" &MAY; be shared by two representations of a resource 329 329 only if they are equivalent by octet equality. 330 330 </t> 331 331 <t> 332 A "weak entity 333 two entities of a resource only if the entities are equivalent and332 A "weak entity-tag," indicated by the "W/" prefix, &MAY; be shared by 333 two representations of a resource only if the representations are equivalent and 334 334 could be substituted for each other with no significant change in 335 semantics. A weak entity 336 </t> 337 <t> 338 An entity tag &MUST; be unique across all versions of all entities339 associated with a particular resource. A given entity 340 be used for entities obtained by requests on different URIs. The use341 of the same entity tag value in conjunction with entities obtained by335 semantics. A weak entity-tag can only be used for weak comparison. 336 </t> 337 <t> 338 An entity-tag &MUST; be unique across all versions of all representations 339 associated with a particular resource. A given entity-tag value &MAY; 340 be used for representations obtained by requests on different URIs. The use 341 of the same entity-tag value in conjunction with representations obtained by 342 342 requests on different URIs does not imply the equivalence of those 343 entities.344 </t> 345 346 <section title="Example: Entity Tags varying on Content-Negotiated Resources" anchor="example.entity.tag.vs.conneg">343 representations. 344 </t> 345 346 <section title="Example: Entity-tags varying on Content-Negotiated Resources" anchor="example.entity.tag.vs.conneg"> 347 347 <t> 348 348 Consider a resource that is subject to content negotiation (&content-negotiation;), … … 390 390 <t> 391 391 <x:h>Note:</x:h> Content codings are a property of the representation, 392 so therefore an entity 392 so therefore an entity-tag of an encoded representation must be distinct 393 393 from an unencoded representation to prevent conflicts during cache updates 394 394 and range requests. In contrast, transfer codings (&transfer-codings;) 395 apply only during message transfer and do not require distinct entity 395 apply only during message transfer and do not require distinct entity-tags. 396 396 </t> 397 397 </x:note> … … 469 469 </t> 470 470 <t> 471 Entity tags are normally "strong validators,"but the protocol472 provides a mechanism to tag an entity 471 An entity-tag is normally a strong validator, but the protocol 472 provides a mechanism to tag an entity-tag as "weak." One can think of 473 473 a strong validator as one that changes whenever the sequence of bits 474 474 in a representation changes, while a weak value changes whenever the … … 481 481 incremented in stable storage every time a representation is changed. 482 482 </t><t> 483 A n entity's modification time, if defined with only one-second483 A representation's modification time, if defined with only one-second 484 484 resolution, could be a weak validator, since it is possible that 485 485 the representation might be modified twice during a single second. … … 524 524 </t> 525 525 <t> 526 The example below shows the results for a set of entity 526 The example below shows the results for a set of entity-tag pairs, 527 527 and both the weak and strong comparison function results: 528 528 </t> … … 554 554 </texttable> 555 555 <t> 556 An entity 557 <xref target="entity.tags"/> gives the syntax for entity 556 An entity-tag is strong unless it is explicitly tagged as weak. 557 <xref target="entity.tags"/> gives the syntax for entity-tags. 558 558 </t> 559 559 <t> … … 621 621 </section> 622 622 623 <section title="Rules for When to Use Entity Tags and Last-Modified Dates" anchor="rules.for.when.to.use.entity.tags.and.last-modified.dates">623 <section title="Rules for When to Use Entity-tags and Last-Modified Dates" anchor="rules.for.when.to.use.entity.tags.and.last-modified.dates"> 624 624 <t> 625 625 We adopt a set of rules and recommendations for origin servers, … … 630 630 HTTP/1.1 origin servers: 631 631 <list style="symbols"> 632 <t>&SHOULD; send an entity 632 <t>&SHOULD; send an entity-tag validator unless it is not feasible to 633 633 generate one.</t> 634 634 635 <t>&MAY; send a weak entity tag instead of a strong entitytag, if636 performance considerations support the use of weak entity 637 or if it is unfeasible to send a strong entity 635 <t>&MAY; send a weak entity-tag instead of a strong entity-tag, if 636 performance considerations support the use of weak entity-tags, 637 or if it is unfeasible to send a strong entity-tag.</t> 638 638 639 639 <t>&SHOULD; send a Last-Modified value if it is feasible to send one, … … 645 645 <t> 646 646 In other words, the preferred behavior for an HTTP/1.1 origin server 647 is to send both a strong entity 648 </t> 649 <t> 650 In order to be legal, a strong entity 651 associated entity changes in any way. A weak entitytag &SHOULD;652 change whenever the associated entitychanges in a semantically647 is to send both a strong entity-tag and a Last-Modified value. 648 </t> 649 <t> 650 In order to be legal, a strong entity-tag &MUST; change whenever the 651 associated representation changes in any way. A weak entity-tag &SHOULD; 652 change whenever the associated representation changes in a semantically 653 653 significant way. 654 654 </t> … … 656 656 <t> 657 657 <x:h>Note:</x:h> In order to provide semantically transparent caching, an 658 origin server must avoid reusing a specific strong entity 659 value for two different entities, or reusing a specific weak660 entity tag value for two semantically different entities. Cache658 origin server must avoid reusing a specific strong entity-tag 659 value for two different representations, or reusing a specific weak 660 entity-tag value for two semantically different representations. Cache 661 661 entries might persist for arbitrarily long periods, regardless of 662 662 expiration times, so it might be inappropriate to expect that a … … 668 668 HTTP/1.1 clients: 669 669 <list style="symbols"> 670 <t>&MUST; use that entity 671 If-Match or If-None-Match) if an entity 670 <t>&MUST; use that entity-tag in any cache-conditional request (using 671 If-Match or If-None-Match) if an entity-tag has been provided by the 672 672 origin server.</t> 673 673 … … 682 682 683 683 <t>&SHOULD; use both validators in cache-conditional requests if both an 684 entity 684 entity-tag and a Last-Modified value have been provided by the origin 685 685 server. This allows both HTTP/1.0 and HTTP/1.1 caches to respond 686 686 appropriately.</t> … … 690 690 An HTTP/1.1 origin server, upon receiving a conditional request that 691 691 includes both a Last-Modified date (e.g., in an If-Modified-Since or 692 If-Unmodified-Since header field) and one or more entity 692 If-Unmodified-Since header field) and one or more entity-tags (e.g., 693 693 in an If-Match, If-None-Match, or If-Range header field) as cache 694 694 validators, &MUST-NOT; return a response status of 304 (Not Modified) … … 698 698 <t> 699 699 An HTTP/1.1 caching proxy, upon receiving a conditional request that 700 includes both a Last-Modified date and one or more entity 700 includes both a Last-Modified date and one or more entity-tags as 701 701 cache validators, &MUST-NOT; return a locally cached response to the 702 702 client unless that cached response is consistent with all of the … … 709 709 conservative assumptions about the validators they receive. 710 710 </t><t> 711 HTTP/1.0 clients and caches will ignore entity 711 HTTP/1.0 clients and caches will ignore entity-tags. Generally, 712 712 last-modified values received or used by these systems will 713 713 support transparent and efficient caching, and so HTTP/1.1 origin … … 737 737 <t> 738 738 The "ETag" response-header field provides the current value of the 739 entity 740 the resource identified by the Effective Request URI. An entity 739 entity-tag (see <xref target="entity.tags"/>) for one representation of 740 the resource identified by the Effective Request URI. An entity-tag 741 741 is intended for use as a resource-local identifier for differentiating 742 742 between representations of the same resource that vary over time or via … … 756 756 </artwork></figure> 757 757 <t> 758 An entity 758 An entity-tag provides an "opaque" cache validator that allows for 759 759 more reliable validation than modification dates in situations where 760 760 it is inconvenient to store modification dates, … … 764 764 </t> 765 765 <t> 766 The principle behind entity 766 The principle behind entity-tags is that only the service author 767 767 knows the semantics of a resource well enough to select an 768 768 appropriate cache validation mechanism, and the specification of any … … 781 781 <t> 782 782 The "If-Match" request-header field is used to make a request method 783 conditional. A client that has one or more entities previously784 obtained from the resource can verify that one of those entities is785 current by including a list of their associated entity 783 conditional. A client that has one or more representations previously 784 obtained from the resource can verify that one of those representations is 785 current by including a list of their associated entity-tags in the 786 786 If-Match header field. 787 787 </t> … … 790 790 transaction overhead. It is also used when updating resources, to prevent 791 791 inadvertent modification of the wrong version of a resource. As a special 792 case, the value "*" matches any current entityof the resource.792 case, the value "*" matches any current representation of the resource. 793 793 </t> 794 794 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Match"/><iref primary="true" item="Grammar" subitem="If-Match-v"/> … … 797 797 </artwork></figure> 798 798 <t> 799 If any of the entity tags match the entitytag of the representation that799 If any of the entity-tags match the entity-tag of the representation that 800 800 would have been returned in the response to a similar GET request 801 801 (without the If-Match header) on that resource, or if "*" is given 802 and any current entityexists for that resource, then the server &MAY;802 and any current representation exists for that resource, then the server &MAY; 803 803 perform the requested method as if the If-Match header field did not 804 804 exist. 805 805 </t> 806 806 <t> 807 If none of the entity 807 If none of the entity-tags match, or if "*" is given and no current 808 808 representation exists, the server &MUST-NOT; perform the requested method, and 809 809 &MUST; return a 412 (Precondition Failed) response. This behavior is … … 827 827 If-Match header field to signal that the request method &MUST-NOT; be 828 828 applied if the representation corresponding to the If-Match value (a single 829 entity 829 entity-tag) is no longer a representation of that resource. This 830 830 allows the user to indicate that they do not wish the request to be 831 831 successful if the resource has been changed without their knowledge. … … 936 936 <t> 937 937 The "If-None-Match" request-header field is used to make a request method 938 conditional. A client that has one or more entities previously939 obtained from the resource can verify that none of those entities is940 current by including a list of their associated entity 938 conditional. A client that has one or more representations previously 939 obtained from the resource can verify that none of those representations is 940 current by including a list of their associated entity-tags in the 941 941 If-None-Match header field. 942 942 </t> … … 948 948 </t> 949 949 <t> 950 As a special case, the value "*" matches any current entityof the950 As a special case, the value "*" matches any current representation of the 951 951 resource. 952 952 </t> … … 956 956 </artwork></figure> 957 957 <t> 958 If any of the entity tags match the entitytag of the representation that958 If any of the entity-tags match the entity-tag of the representation that 959 959 would have been returned in the response to a similar GET request 960 960 (without the If-None-Match header) on that resource, or if "*" is … … 970 970 </t> 971 971 <t> 972 If none of the entity 972 If none of the entity-tags match, then the server &MAY; perform the 973 973 requested method as if the If-None-Match header field did not exist, 974 974 but &MUST; also ignore any If-Modified-Since header field(s) in the 975 request. That is, if no entity 975 request. That is, if no entity-tags match, then the server &MUST-NOT; 976 976 return a 304 (Not Modified) response. 977 977 </t> … … 1075 1075 of the origin server and the nature of the original resource. For 1076 1076 files, it may be just the file system last-modified time. For 1077 entities with dynamically included parts, it may be the most recent1077 representations with dynamically included parts, it may be the most recent 1078 1078 of the set of last-modify times for its component parts. For database 1079 1079 gateways, it may be the last-update time stamp of the record. For … … 1091 1091 as close as possible to the time that it generates the Date value of 1092 1092 its response. This allows a recipient to make an accurate assessment 1093 of the entity's modification time, especially if the representation changes1093 of the representation's modification time, especially if the representation changes 1094 1094 near the time that the response is generated. 1095 1095 </t> … … 1490 1490 <section title="Changes from RFC 2616" anchor="changes.from.rfc.2616"> 1491 1491 <t> 1492 Allow weak entity 1492 Allow weak entity-tags in all requests except range requests (Sections 1493 1493 <xref target="weak.and.strong.validators" format="counter"/> and 1494 1494 <xref target="header.if-none-match" format="counter"/>). -
draft-ietf-httpbis/latest/p5-range.xml
r866 r874 316 316 <t> 317 317 HTTP/1.1 allows a client to request that only part (a range of) the 318 re sponse entitybe included within the response. HTTP/1.1 uses range318 representation be included within the response. HTTP/1.1 uses range 319 319 units in the Range (<xref target="header.range"/>) and Content-Range (<xref target="header.content-range"/>) 320 header fields. A n entitycan be broken down into subranges according320 header fields. A representation can be broken down into subranges according 321 321 to various structural units. 322 322 </t> … … 412 412 <section title="Combining Ranges" anchor="combining.byte.ranges"> 413 413 <t> 414 A response might transfer only a subrange of a n entity-body, either because414 A response might transfer only a subrange of a representation, either because 415 415 the request included one or more Range specifications, or because 416 a connection was brokenprematurely.416 a connection closed prematurely. 417 417 After several such transfers, a cache might have received several 418 ranges of the same entity-body.418 ranges of the same representation. 419 419 </t> 420 420 <t> … … 498 498 <x:anchor-alias value="other-range-resp-spec"/> 499 499 <t> 500 The "Content-Range" entity-header field is sent with a partial entity-bodyto501 specify where in the full entity-bodythe partial body should be500 The "Content-Range" entity-header field is sent with a partial representation to 501 specify where in the full representation the partial body should be 502 502 applied. Range units are defined in <xref target="range.units"/>. 503 503 </t> … … 522 522 </artwork></figure> 523 523 <t> 524 The header &SHOULD; indicate the total length of the full entity-body,524 The header &SHOULD; indicate the total length of the full representation, 525 525 unless this length is unknown or difficult to determine. The asterisk 526 526 "*" character means that the instance-length is unknown at the time … … 617 617 invalid, the server &SHOULD; treat the request as if the invalid Range 618 618 header field did not exist. (Normally, this means return a 200 619 response containing the full entity).619 response containing the full representation). 620 620 </t> 621 621 <t> … … 643 643 <x:anchor-alias value="If-Range-v"/> 644 644 <t> 645 If a client has a partial copy of a n entityin its cache, and wishes646 to have an up-to-date copy of the entire entityin its cache, it645 If a client has a partial copy of a representation in its cache, and wishes 646 to have an up-to-date copy of the entire representation in its cache, it 647 647 could use the Range request-header with a conditional GET (using 648 648 either or both of If-Unmodified-Since and If-Match.) However, if the … … 662 662 </artwork></figure> 663 663 <t> 664 If the client has no entity 664 If the client has no entity-tag for a representation, but does have a Last-Modified 665 665 date, it &MAY; use that date in an If-Range header. (The 666 666 server can distinguish between a valid HTTP-date and any form of … … 671 671 </t> 672 672 <t> 673 If the entity 673 If the entity-tag given in the If-Range header matches the current 674 674 cache validator for the representation, then the server &SHOULD; provide the 675 675 specified sub-range of the representation using a 206 (Partial Content) … … 744 744 A suffix-byte-range-spec is used to specify the suffix of the 745 745 representation body, of a length given by the suffix-length value. (That is, 746 this form specifies the last N bytes of a n entity-body.) If the746 this form specifies the last N bytes of a representation.) If the 747 747 representation is shorter than the specified suffix-length, the entire 748 748 representation is used. … … 751 751 If a syntactically valid byte-range-set includes at least one byte-range-spec 752 752 whose first-byte-pos is less than the current length of 753 the entity-body, or at least one suffix-byte-range-spec with a non-zero753 the representation, or at least one suffix-byte-range-spec with a non-zero 754 754 suffix-length, then the byte-range-set is satisfiable. 755 755 Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set … … 760 760 </t> 761 761 <t> 762 Examples of byte-ranges-specifier values (assuming a n entity-bodyof762 Examples of byte-ranges-specifier values (assuming a representation of 763 763 length 10000): 764 764 <list style="symbols"> … … 820 820 possible, since Range supports efficient recovery from partially 821 821 failed transfers, and supports efficient partial retrieval of large 822 entities.822 representations. 823 823 </t> 824 824 <t> 825 825 If the server supports the Range header and the specified range or 826 ranges are appropriate for the entity:826 ranges are appropriate for the representation: 827 827 <list style="symbols"> 828 828 <t>The presence of a Range header in an unconditional GET modifies … … 845 845 <t> 846 846 If a proxy that supports ranges receives a Range request, forwards 847 the request to an inbound server, and receives an entire entityin847 the request to an inbound server, and receives an entire representation in 848 848 reply, it &SHOULD; only return the requested range to its client. It 849 849 &SHOULD; store the entire received response in its cache if that is -
draft-ietf-httpbis/latest/p6-cache.xml
r866 r874 271 271 <x:dfn>explicit expiration time</x:dfn> 272 272 <list> 273 <t>The time at which the origin server intends that a n entityshould no longer be273 <t>The time at which the origin server intends that a representation should no longer be 274 274 returned by a cache without further validation.</t> 275 275 </list> … … 324 324 <x:dfn>validator</x:dfn> 325 325 <list> 326 <t>A protocol element (e.g., an entity 326 <t>A protocol element (e.g., an entity-tag or a Last-Modified time) that is used to find 327 327 out whether a stored response has an equivalent copy of a representation.</t> 328 328 </list> … … 929 929 The updated response can <cref anchor="TODO-is-req">requirement?</cref> be used to replace the 930 930 stored response in cache. In the case of a 206 response, the combined 931 entity-body&MAY; be stored.931 representation &MAY; be stored. 932 932 </t> 933 933 <t> … … 1107 1107 <t>The no-transform request directive indicates that an intermediate cache or proxy 1108 1108 &MUST-NOT; change the Content-Encoding, Content-Range or Content-Type request 1109 headers, nor the request entity-body.</t>1109 headers, nor the request representation.</t> 1110 1110 </list> 1111 1111 </t> … … 1263 1263 <t>The no-transform response directive indicates that an intermediate cache or proxy 1264 1264 &MUST-NOT; change the Content-Encoding, Content-Range or Content-Type response 1265 headers, nor the response entity-body.</t>1265 headers, nor the response representation.</t> 1266 1266 </list> 1267 1267 </t> … … 1585 1585 214 Transformation applied 1586 1586 <list> 1587 <t>&MUST; be added by an intermediate cache or proxy if it applies any 1588 transformation changing the content-coding (as specified in the Content-Encoding 1589 header) or media-type (as specified in the Content-Type header) of the response, or 1590 the entity-body of the response, unless this Warning code already appears in the 1591 response.</t> 1587 <t>&MUST; be added by an intermediate proxy if it applies any 1588 transformation to the representation, such as changing the content-coding, 1589 media-type, or modifying the representation data, unless this Warning code 1590 already appears in the response.</t> 1592 1591 </list> 1593 1592 </t> … … 1607 1606 <t> 1608 1607 User agents often have history mechanisms, such as "Back" buttons and history lists, that 1609 can be used to redisplay a n entityretrieved earlier in a session.1608 can be used to redisplay a representation retrieved earlier in a session. 1610 1609 </t> 1611 1610 <t> -
draft-ietf-httpbis/latest/p7-auth.xml
r848 r874 310 310 prior response, and the user agent has already attempted 311 311 authentication at least once, then the user &SHOULD; be presented the 312 entity that was given in the response, since that entitymight312 representation that was given in the response, since that representation might 313 313 include relevant diagnostic information. HTTP access authentication 314 314 is explained in "HTTP Authentication: Basic and Digest Access
Note: See TracChangeset
for help on using the changeset viewer.