Changeset 965
- Timestamp:
- 30/07/10 06:11:34 (12 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 7 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r963 r965 24 24 <!ENTITY diff-mime "<xref target='Part3' x:rel='#differences.between.http.and.mime' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 25 25 <!ENTITY representation "<xref target='Part3' x:rel='#representation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 26 <!ENTITY entity-header-fields "<xref target='Part3' x:rel='#entity.header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">27 26 <!ENTITY header-cache-control "<xref target='Part6' x:rel='#header.cache-control' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 28 27 <!ENTITY header-expect "<xref target='Part2' x:rel='#header.expect' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 521 520 <x:anchor-alias value="request-header"/> 522 521 <x:anchor-alias value="response-header"/> 523 <x:anchor-alias value="entity-header"/>524 522 <x:anchor-alias value="Cache-Control"/> 525 523 <x:anchor-alias value="Pragma"/> … … 534 532 </artwork></figure> 535 533 <figure><!-- Part3--><artwork type="abnf2616"> 536 <x:ref>entity-header</x:ref> = <entity-header, defined in &entity-header-fields;>537 534 <x:ref>MIME-Version</x:ref> = <MIME-Version, defined in &header-mime-version;> 538 535 </artwork></figure> … … 556 553 557 554 <section title="Client/Server Messaging" anchor="operation"> 558 <iref item="client"/>559 <iref item="server"/>560 <iref item="connection"/>555 <iref primary="true" item="client"/> 556 <iref primary="true" item="server"/> 557 <iref primary="true" item="connection"/> 561 558 <t> 562 559 HTTP is a stateless request/response protocol that operates by exchanging … … 567 564 sending HTTP responses. 568 565 </t> 569 <iref item="user agent"/> 570 <iref item="origin server"/> 566 <iref primary="true" item="user agent"/> 567 <iref primary="true" item="origin server"/> 568 <iref primary="true" item="browser"/> 569 <iref primary="true" item="spider"/> 571 570 <t> 572 571 Note that the terms client and server refer only to the roles that … … 576 575 such as a WWW browser, editor, or spider (web-traversing robot), and 577 576 the term "origin server" to refer to the program that can originate 578 authoritative responses to a request. 577 authoritative responses to a request. For general requirements, we use 578 the term "sender" to refer to whichever component sent a given message 579 and the term "recipient" to refer to any component that receives the 580 message. 579 581 </t> 580 582 <t> … … 589 591 < response 590 592 </artwork></figure> 591 <iref item="message"/>592 <iref item="request"/>593 <iref item="response"/>593 <iref primary="true" item="message"/> 594 <iref primary="true" item="request"/> 595 <iref primary="true" item="response"/> 594 596 <t> 595 597 A client sends an HTTP request to the server in the form of a request … … 639 641 640 642 <section title="Intermediaries" anchor="intermediaries"> 643 <iref primary="true" item="intermediary"/> 641 644 <t> 642 645 A more complicated situation occurs when one or more intermediaries … … 665 668 </t> 666 669 <t> 667 <iref item="upstream"/><irefitem="downstream"/>668 <iref item="inbound"/><irefitem="outbound"/>670 <iref primary="true" item="upstream"/><iref primary="true" item="downstream"/> 671 <iref primary="true" item="inbound"/><iref primary="true" item="outbound"/> 669 672 We use the terms "upstream" and "downstream" to describe various 670 673 requirements in relation to the directional flow of a message: … … 674 677 the origin server and "outbound" means toward the user agent. 675 678 </t> 676 <t><iref item="proxy"/>679 <t><iref primary="true" item="proxy"/> 677 680 A "proxy" is a message forwarding agent that is selected by the 678 681 client, usually via local configuration rules, to receive requests … … 685 688 sake of security, annotation services, or shared caching. 686 689 </t> 687 <t><iref item="gateway"/><irefitem="reverse proxy"/>690 <t><iref primary="true" item="gateway"/><iref primary="true" item="reverse proxy"/> 688 691 A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts 689 692 as a layer above some other server(s) and translates the received … … 692 695 multiple machines. 693 696 Unlike a proxy, a gateway receives requests as if it were the 694 origin server for the requestedresource; the requesting client697 origin server for the target resource; the requesting client 695 698 will not be aware that it is communicating with a gateway. 696 699 A gateway communicates with the client as if the gateway is the … … 701 704 specification. 702 705 </t> 703 <t><iref item="tunnel"/>706 <t><iref primary="true" item="tunnel"/> 704 707 A "tunnel" acts as a blind relay between two connections 705 708 without changing the messages. Once active, a tunnel is not … … 714 717 715 718 <section title="Caches" anchor="caches"> 716 <iref item="cache"/>719 <iref primary="true" item="cache"/> 717 720 <t> 718 721 A "cache" is a local store of previous response messages and the … … 735 738 < < 736 739 </artwork></figure> 737 <t><iref item="cacheable"/>740 <t><iref primary="true" item="cacheable"/> 738 741 A response is "cacheable" if a cache is allowed to store a copy of 739 742 the response message for use in answering subsequent requests. … … 1128 1131 like UTF-16 might introduce security flaws due to the differing ways 1129 1132 that such parsers interpret invalid characters. 1133 </t> 1134 <t> 1135 HTTP allows the set of defined header fields to be extended without 1136 changing the protocol version (see <xref target="header.field.registration"/>). 1137 However, such fields might not be recognized by a downstream recipient 1138 and might be stripped by non-transparent intermediaries. 1139 Unrecognized header fields &MUST; be forwarded by transparent proxies 1140 and &SHOULD; be ignored by a recipient. 1130 1141 </t> 1131 1142 </section> … … 1444 1455 experimental header fields might be given the semantics of general 1445 1456 header fields if all parties in the communication recognize them to 1446 be general-header fields. Unrecognized header fields are treated as 1447 entity-header fields. 1457 be general-header fields. 1448 1458 </t> 1449 1459 </section> … … 1460 1470 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Request"/> 1461 1471 <x:ref>Request</x:ref> = <x:ref>Request-Line</x:ref> ; <xref target="request-line"/> 1462 *(( <x:ref>general-header</x:ref> ; <xref target="general.header.fields"/> 1463 / <x:ref>request-header</x:ref> ; &request-header-fields; 1464 / <x:ref>entity-header</x:ref> ) <x:ref>CRLF</x:ref> ) ; &entity-header-fields; 1472 *( <x:ref>header-field</x:ref> <x:ref>CRLF</x:ref> ) ; <xref target="header.fields"/> 1465 1473 <x:ref>CRLF</x:ref> 1466 1474 [ <x:ref>message-body</x:ref> ] ; <xref target="message.body"/> … … 1658 1666 1659 1667 <section title="Effective Request URI" anchor="effective.request.uri"> 1660 <iref primary="true" item="Effective Request URI"/> 1668 <iref primary="true" item="effective request URI"/> 1669 <iref primary="true" item="target resource"/> 1661 1670 <t> 1662 1671 HTTP requests often do not carry the absolute URI (<xref target="RFC3986" x:fmt="," x:sec="4.3"/>) 1663 for the resource they are intended for; instead, the value needs to be inferred from the 1664 request-target, Host header and other context. The result of this process is 1665 the "Effective Request URI". 1666 </t> 1667 <t> 1668 If the request-target is an absolute-URI, then the Effective Request URI is 1672 for the target resource; instead, the URI needs to be inferred from the 1673 request-target, Host header field, and connection context. The result of 1674 this process is called the "effective request URI". The "target resource" 1675 is the resource identified by the effective request URI. 1676 </t> 1677 <t> 1678 If the request-target is an absolute-URI, then the effective request URI is 1669 1679 the request-target. 1670 1680 </t> 1671 1681 <t> 1672 1682 If the request-target uses the path-absolute (plus optional query) syntax 1673 or if it is just the asterisk "*", then the Effective Request URI is1683 or if it is just the asterisk "*", then the effective request URI is 1674 1684 constructed by concatenating 1675 1685 </t> … … 1704 1714 <figure> 1705 1715 <preamble> 1706 Example 1: the Effective Request URI for the message1716 Example 1: the effective request URI for the message 1707 1717 </preamble> 1708 1718 <artwork type="example" x:indent-with=" "> … … 1719 1729 <figure> 1720 1730 <preamble> 1721 Example 2: the Effective Request URI for the message1731 Example 2: the effective request URI for the message 1722 1732 </preamble> 1723 1733 <artwork type="example" x:indent-with=" "> … … 1731 1741 </figure> 1732 1742 <t> 1733 Effective Request URIs are compared using the rules described in1743 Effective request URIs are compared using the rules described in 1734 1744 <xref target="uri.comparison"/>, except that empty path components &MUST-NOT; 1735 1745 be treated as equivalent to an absolute path of "/". … … 1748 1758 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Response"/> 1749 1759 <x:ref>Response</x:ref> = <x:ref>Status-Line</x:ref> ; <xref target="status-line"/> 1750 *(( <x:ref>general-header</x:ref> ; <xref target="general.header.fields"/> 1751 / <x:ref>response-header</x:ref> ; &response-header-fields; 1752 / <x:ref>entity-header</x:ref> ) <x:ref>CRLF</x:ref> ) ; &entity-header-fields; 1760 *( <x:ref>header-field</x:ref> <x:ref>CRLF</x:ref> ) ; <xref target="header.fields"/> 1753 1761 <x:ref>CRLF</x:ref> 1754 1762 [ <x:ref>message-body</x:ref> ] ; <xref target="message.body"/> … … 2031 2039 The chunked encoding modifies the body of a message in order to 2032 2040 transfer it as a series of chunks, each with its own size indicator, 2033 followed by an &OPTIONAL; trailer containing entity-header fields. This2041 followed by an &OPTIONAL; trailer containing header fields. This 2034 2042 allows dynamically produced content to be transferred along with the 2035 2043 information necessary for the recipient to verify that it has … … 2052 2060 <x:ref>chunk-ext-val</x:ref> = <x:ref>token</x:ref> / <x:ref>quoted-str-nf</x:ref> 2053 2061 <x:ref>chunk-data</x:ref> = 1*<x:ref>OCTET</x:ref> ; a sequence of chunk-size octets 2054 <x:ref>trailer-part</x:ref> = *( <x:ref> entity-header</x:ref> <x:ref>CRLF</x:ref> )2062 <x:ref>trailer-part</x:ref> = *( <x:ref>header-field</x:ref> <x:ref>CRLF</x:ref> ) 2055 2063 2056 2064 <x:ref>quoted-str-nf</x:ref> = <x:ref>DQUOTE</x:ref> *( <x:ref>qdtext-nf</x:ref> / <x:ref>quoted-pair</x:ref> ) <x:ref>DQUOTE</x:ref> … … 2843 2851 related to message framing and transport protocols. 2844 2852 </t> 2845 <t>2846 For entity-header fields, both sender and recipient refer to either the2847 client or the server, depending on who sends and who receives the message.2848 </t>2849 2853 2850 2854 <section title="Connection" anchor="header.connection"> … … 3231 3235 &MUST; be listed in the order in which they were applied. 3232 3236 Additional information about the encoding parameters &MAY; be provided 3233 by other entity-header fields not defined by this specification.3237 by other header fields not defined by this specification. 3234 3238 </t> 3235 3239 <t> … … 4936 4940 <x:ref>RWS</x:ref> = 1*( [ obs-fold ] WSP ) 4937 4941 <x:ref>Reason-Phrase</x:ref> = *( WSP / VCHAR / obs-text ) 4938 <x:ref>Request</x:ref> = Request-Line *( ( general-header / request-header / 4939 entity-header ) CRLF ) CRLF [ message-body ] 4942 <x:ref>Request</x:ref> = Request-Line *( header-field CRLF ) CRLF [ message-body ] 4940 4943 <x:ref>Request-Line</x:ref> = Method SP request-target SP HTTP-Version CRLF 4941 <x:ref>Response</x:ref> = Status-Line *( ( general-header / response-header / 4942 entity-header ) CRLF ) CRLF [ message-body ] 4944 <x:ref>Response</x:ref> = Status-Line *( header-field CRLF ) CRLF [ message-body ] 4943 4945 4944 4946 <x:ref>Status-Code</x:ref> = 3DIGIT … … 5001 5003 / %x53.75.6E.64.61.79 ; Sunday 5002 5004 5003 <x:ref>entity-header</x:ref> = <entity-header, defined in [Part3], Section 3.1>5004 5005 5005 <x:ref>field-content</x:ref> = *( WSP / VCHAR / obs-text ) 5006 5006 <x:ref>field-name</x:ref> = token … … 5081 5081 <x:ref>time-of-day</x:ref> = hour ":" minute ":" second 5082 5082 <x:ref>token</x:ref> = 1*tchar 5083 <x:ref>trailer-part</x:ref> = *( entity-headerCRLF )5083 <x:ref>trailer-part</x:ref> = *( header-field CRLF ) 5084 5084 <x:ref>transfer-coding</x:ref> = "chunked" / "compress" / "deflate" / "gzip" / 5085 5085 transfer-extension … … 5638 5638 </t> 5639 5639 <t> 5640 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/109"/>: 5641 "Clarify entity / representation / variant terminology" 5642 </t> 5643 <t> 5640 5644 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/220"/>: 5641 5645 "consider removing the 'changes from 2068' sections" -
draft-ietf-httpbis/latest/p2-semantics.xml
r954 r965 277 277 agreed upon semantics of the HTTP uniform interface, the intentions defined 278 278 by each request method, and the various response messages that might be 279 expected as a result of applying that method for the requestedresource.279 expected as a result of applying that method to the target resource. 280 280 </t> 281 281 <t> … … 434 434 <t> 435 435 The Method token indicates the method to be performed on the resource 436 identified by the Effective Request URI (&effective-request-uri;). The436 identified by the effective request URI (&effective-request-uri;). The 437 437 method is case-sensitive. 438 438 </t> … … 451 451 <t> 452 452 The list of methods allowed by a resource can be specified in an 453 Allow header field (<xref target="header.allow"/>). The returncode of the response453 Allow header field (<xref target="header.allow"/>). The status code of the response 454 454 always notifies the client whether a method is currently allowed on a 455 455 resource, since the set of allowed methods can change dynamically. An 456 origin server &SHOULD; re turnthe status code 405 (Method Not Allowed)456 origin server &SHOULD; respond with the status code 405 (Method Not Allowed) 457 457 if the method is known by the origin server but not allowed for the 458 re quested resource, and 501 (Not Implemented) if the method is458 resource, and 501 (Not Implemented) if the method is 459 459 unrecognized or not implemented by the origin server. The methods GET 460 460 and HEAD &MUST; be supported by all general-purpose servers. All other … … 522 522 experimental header fields &MAY; be given the semantics of request-header 523 523 fields if all parties in the communication recognize them to 524 be request-header fields. Unrecognized header fields are treated as 525 entity-header fields. 524 be request-header fields. 526 525 </t> 527 526 </section> … … 635 634 information about the response which cannot be placed in the Status-Line. 636 635 These header fields give information about the server and about 637 further access to the resource identified by the Effective Request URI636 further access to the resource identified by the effective request URI 638 637 (&effective-request-uri;). 639 638 </t> … … 655 654 experimental header fields &MAY; be given the semantics of response-header 656 655 fields if all parties in the communication recognize them to 657 be response-header fields. Unrecognized header fields are treated as 658 entity-header fields. 656 be response-header fields. 659 657 </t> 660 658 </section> … … 678 676 <section title="Identifying the Resource Associated with a Representation" anchor="identifying.response.associated.with.representation"> 679 677 <t> 680 It is sometimes necessary to determine the identity ofthe resource678 It is sometimes necessary to determine an identifier for the resource 681 679 associated with a representation. 682 680 </t> … … 687 685 <t> 688 686 In the common case, an HTTP response is a representation of the resource 689 located at the Effective Request URI (see &effective-request-uri;). However,687 located at the effective request URI (see &effective-request-uri;). However, 690 688 this is not always the case. To determine the URI of the resource a 691 689 response is associated with, the following rules are used (with the first … … 694 692 <t><list style="numbers"> 695 693 <t>If the response status code is 200 or 203 and the request method was GET, 696 the response is a representation of the resource at the Effective Request URI.</t>694 the response payload is a representation of the resource identified by the effective request URI.</t> 697 695 <t>If the response status code is 204, 206, or 304 and the request method was GET 698 or HEAD, the response is a partial representation of the resource at the699 Effective Request URI (see &caching-combining-headers;).</t>696 or HEAD, the response payload is a partial representation of the resource identified 697 by the effective request URI (see &caching-combining-headers;).</t> 700 698 <t>If the response has a Content-Location header, and that URI is the same 701 as the Effective Request URI, the responseis a representation of the702 resource at the Effective Request URI.</t>699 as the effective request URI, the response payload is a representation of the 700 resource identified by the effective request URI.</t> 703 701 <t>If the response has a Content-Location header, and that URI is not the 704 same as the Effective Request URI, the response asserts that it is a 705 representation of the resource at the Content-Location URI (but it might not 706 be).</t> 702 same as the effective request URI, then the response asserts that its 703 payload is a representation of the resource identified by the 704 Content-Location URI. However, such an assertion cannot be trusted unless 705 it can be verified by other means (not defined by HTTP).</t> 707 706 <t>Otherwise, the response is a representation of an anonymous (i.e., 708 707 unidentified) resource.</t> … … 776 775 The OPTIONS method represents a request for information about the 777 776 communication options available on the request/response chain 778 identified by the Effective Request URI. This method allows the client to777 identified by the effective request URI. This method allows the client to 779 778 determine the options and/or requirements associated with a resource, 780 779 or the capabilities of a server, without implying a resource action … … 835 834 The GET method means retrieve whatever information (in the form of a 836 835 representation) currently corresponds to the resource identified by the 837 Effective Request URI.836 effective request URI. 838 837 </t> 839 838 <t> 840 If the Effective Request URI identifies a data-producing process, it is the839 If the effective request URI identifies a data-producing process, it is the 841 840 produced data which shall be returned as the representation in the response and not 842 841 the source text of the process, unless that text happens to be the output of … … 903 902 The POST method is used to request that the origin server accept the 904 903 representation enclosed in the request as data to be processed by the resource 905 identified by the Effective Request URI. POST is designed904 identified by the effective request URI. POST is designed 906 905 to allow a uniform method to cover the following functions: 907 906 <list style="symbols"> … … 924 923 <t> 925 924 The actual function performed by the POST method is determined by the 926 server and is usually dependent on the Effective Request URI.925 server and is usually dependent on the effective request URI. 927 926 </t> 928 927 <t> … … 958 957 <t> 959 958 The PUT method requests that the enclosed representation be stored at the 960 Effective Request URI. If the Effective Request URI refers to an already959 effective request URI. If the effective request URI refers to an already 961 960 existing resource, the enclosed representation &SHOULD; be considered a 962 961 modified version of the one residing on the origin server. Otherwise, if the 963 Effective Request URI does not point to an existing resource, and that URI is962 effective request URI does not point to an existing resource, and that URI is 964 963 capable of being defined as a new resource by the requesting user 965 964 agent, the origin server can create the resource with that URI. 966 965 </t> 967 966 <t> 968 If a new resource is created at the Effective Request URI, the origin967 If a new resource is created at the effective request URI, the origin 969 968 server &MUST; inform the user agent 970 969 via the 201 (Created) response. If an existing resource is modified, … … 973 972 </t> 974 973 <t> 975 If the resource identified by the Effective Request URI could not be974 If the resource identified by the effective request URI could not be 976 975 created or modified, an appropriate error response &SHOULD; be given 977 976 that reflects the nature of the problem. … … 983 982 <t> 984 983 If the request passes through a cache that has one or more stored 985 responses for the Effective Request URI, those stored responses984 responses for the effective request URI, those stored responses 986 985 &SHOULD; be marked as stale if the response to the PUT request 987 986 has a success status code. Responses to the PUT method are … … 990 989 <t> 991 990 The fundamental difference between the POST and PUT requests is 992 reflected in the different meaning of the Effective Request URI. The URI in a991 reflected in the different meaning of the effective request URI. The URI in a 993 992 POST request identifies the resource that will handle the enclosed 994 993 representation. That resource might be a data-accepting process, a gateway to … … 1015 1014 </t> 1016 1015 <t> 1017 Unless otherwise specified for a particular entity-header, the1018 entity-headers in the PUT request &SHOULD; be applied to the resource1019 created or modified by the PUT.1016 Header fields in a PUT request that are recognized as representation 1017 metadata &SHOULD; be applied to the resource created or modified by 1018 the PUT. Unrecognized header fields &SHOULD; be ignored. 1020 1019 </t> 1021 1020 </section> … … 1026 1025 <t> 1027 1026 The DELETE method requests that the origin server delete the resource 1028 identified by the Effective Request URI. This method &MAY; be overridden by1027 identified by the effective request URI. This method &MAY; be overridden by 1029 1028 human intervention (or other means) on the origin server. The client cannot 1030 1029 be guaranteed that the operation has been carried out, even if the … … 1042 1041 </t> 1043 1042 <t> 1044 If the request passes through a cache and the Effective Request URI1043 If the request passes through a cache and the effective request URI 1045 1044 identifies one or more currently cached representations, those entries &SHOULD; be 1046 1045 treated as stale. Responses to the DELETE method are not cacheable. … … 1168 1167 <iref primary="true" item="Status Codes" subitem="200 OK" x:for-anchor=""/> 1169 1168 <t> 1170 The request has succeeded. The informationreturned with the response1169 The request has succeeded. The payload returned with the response 1171 1170 is dependent on the method used in the request, for example: 1172 1171 <list style="hanging"> 1173 1172 <t hangText="GET"> 1174 a representation corresponding to the requested resource is sent in1175 the response;1173 a representation of the resource corresponding to the effective 1174 request URI is sent in the response; 1176 1175 </t> 1177 1176 <t hangText="HEAD"> 1178 the entity-header fields corresponding to the requested 1179 resource are sent in the response without any message-body; 1177 the same representation as GET, except without the message-body; 1180 1178 </t> 1181 1179 <t hangText="POST"> … … 1243 1241 <iref primary="true" item="Status Codes" subitem="203 Non-Authoritative Information" x:for-anchor=""/> 1244 1242 <t> 1245 The returned metadata in the entity-headeris not the1243 The returned metadata in the header fields is not the 1246 1244 definitive set as available from the origin server, but is gathered 1247 1245 from a local or a third-party copy. The set presented &MAY; be a subset … … 1266 1264 additional content to return in the response payload body. The 1267 1265 resource metadata and representation metadata in the response message's 1268 header fields refer to the requested resource and its current1269 representation, respectively, after the requested action.1266 header fields refer to the target resource 1267 and its current representation, respectively, after the requested action. 1270 1268 For example, if a 204 status code is received in response to a PUT 1271 1269 and the response contains an ETag header field, then the value of 1272 1270 that field is the current entity-tag for the representation that 1273 was successfully PUT to the requested resource.1271 was successfully PUT. 1274 1272 </t> 1275 1273 <t> … … 1340 1338 <iref primary="true" item="Status Codes" subitem="300 Multiple Choices" x:for-anchor=""/> 1341 1339 <t> 1342 The requested resource corresponds to any one of a set of1343 representation s, each with its own specific location, and agent-driven1340 The target resource more than one 1341 representation, each with its own specific location, and agent-driven 1344 1342 negotiation information (&content-negotiation;) is being provided so that 1345 the user (or user agent) can select a preferred representation and1346 redirect its request to that location.1343 the user (or user agent) can select a preferred representation by 1344 redirecting its request to that location. 1347 1345 </t> 1348 1346 <t> 1349 1347 Unless it was a HEAD request, the response &SHOULD; include a representation 1350 containing a list of re source characteristicsand location(s) from1348 containing a list of representation metadata and location(s) from 1351 1349 which the user or user agent can choose the one most appropriate. The 1352 1350 data format is specified by the media type given in the Content-Type … … 1373 1371 <iref primary="true" item="Status Codes" subitem="301 Moved Permanently" x:for-anchor=""/> 1374 1372 <t> 1375 The requestedresource has been assigned a new permanent URI and any1373 The target resource has been assigned a new permanent URI and any 1376 1374 future references to this resource &SHOULD; use one of the returned 1377 1375 URIs. Clients with link editing capabilities ought to automatically 1378 re-link references to the Effective Request URI to one or more of the new1376 re-link references to the effective request URI to one or more of the new 1379 1377 references returned by the server, where possible. 1380 1378 </t> … … 1410 1408 <iref primary="true" item="Status Codes" subitem="302 Found" x:for-anchor=""/> 1411 1409 <t> 1412 The requestedresource resides temporarily under a different URI.1410 The target resource resides temporarily under a different URI. 1413 1411 Since the redirection might be altered on occasion, the client &SHOULD; 1414 continue to use the Effective Request URI for future requests.1412 continue to use the effective request URI for future requests. 1415 1413 </t> 1416 1414 <t> … … 1457 1455 representation corresponding to the response, be redirected again, 1458 1456 or end with an error status. The Location URI is not a substitute 1459 reference for the originally requested resource.1457 reference for the effective request URI. 1460 1458 </t> 1461 1459 <t> … … 1471 1469 resource does not have a representation of its own that can be 1472 1470 transferred by the server over HTTP. The Location URI indicates a 1473 resource that is descriptive of the requested resource such that1474 the follow-on representation might be useful without implying that1475 i t adequately represents the previously requestedresource.1471 resource that is descriptive of the target resource, such that the 1472 follow-on representation might be useful to recipients without 1473 implying that it adequately represents the target resource. 1476 1474 Note that answers to the questions of what can be represented, what 1477 1475 representations are adequate, and what might be a useful description … … 1520 1518 <iref primary="true" item="Status Codes" subitem="307 Temporary Redirect" x:for-anchor=""/> 1521 1519 <t> 1522 The requestedresource resides temporarily under a different URI.1520 The target resource resides temporarily under a different URI. 1523 1521 Since the redirection can change over time, the client &SHOULD; 1524 continue to use the Effective Request URI for future requests.1522 continue to use the effective request URI for future requests. 1525 1523 </t> 1526 1524 <t> … … 1610 1608 <iref primary="true" item="Status Codes" subitem="404 Not Found" x:for-anchor=""/> 1611 1609 <t> 1612 The server has not found anything matching the Effective Request URI. No1610 The server has not found anything matching the effective request URI. No 1613 1611 indication is given of whether the condition is temporary or 1614 1612 permanent. The 410 (Gone) status code &SHOULD; be used if the server … … 1625 1623 <iref primary="true" item="Status Codes" subitem="405 Method Not Allowed" x:for-anchor=""/> 1626 1624 <t> 1627 The method specified in the Request-Line is not allowed for the 1628 resource identified by the Effective Request URI. The response &MUST; include an1625 The method specified in the Request-Line is not allowed for the target 1626 resource. The response &MUST; include an 1629 1627 Allow header containing a list of valid methods for the requested 1630 1628 resource. … … 1714 1712 <iref primary="true" item="Status Codes" subitem="410 Gone" x:for-anchor=""/> 1715 1713 <t> 1716 The requestedresource is no longer available at the server and no1714 The target resource is no longer available at the server and no 1717 1715 forwarding address is known. This condition is expected to be 1718 1716 considered permanent. Clients with link editing capabilities &SHOULD; 1719 delete references to the Effective Request URI after user approval. If the1717 delete references to the effective request URI after user approval. If the 1720 1718 server does not know, or has no facility to determine, whether or not 1721 1719 the condition is permanent, the status code 404 (Not Found) &SHOULD; be … … 1784 1782 <iref primary="true" item="Status Codes" subitem="414 URI Too Long" x:for-anchor=""/> 1785 1783 <t> 1786 The server is refusing to service the request because the Effective Request URI1784 The server is refusing to service the request because the effective request URI 1787 1785 is longer than the server is willing to interpret. This rare 1788 1786 condition is only likely to occur when a client has improperly … … 1792 1790 itself), or when the server is under attack by a client attempting to 1793 1791 exploit security holes present in some servers using fixed-length 1794 buffers for reading or manipulating the Effective Request URI.1792 buffers for reading or manipulating the effective request URI. 1795 1793 </t> 1796 1794 </section> … … 1801 1799 <t> 1802 1800 The server is refusing to service the request because the representation of 1803 the request is in a format not supported by the requestedresource1801 the request is in a format not supported by the target resource 1804 1802 for the requested method. 1805 1803 </t> … … 1932 1930 related to request and response semantics. 1933 1931 </t> 1934 <t>1935 For entity-header fields, both sender and recipient refer to either the1936 client or the server, depending on who sends and who receives the message.1937 </t>1938 1932 1939 1933 <section title="Allow" anchor="header.allow"> … … 1944 1938 <t> 1945 1939 The "Allow" response-header field lists the set of methods advertised as 1946 supported by the resource identified by the Effective Request URI. The purpose of1940 supported by the target resource. The purpose of 1947 1941 this field is strictly to inform the recipient of valid methods 1948 1942 associated with the resource. … … 2177 2171 <t> 2178 2172 The "Referer" [sic] request-header field allows the client to specify the 2179 URI of the resource from which the Effective Request URI was obtained (the2173 URI of the resource from which the effective request URI was obtained (the 2180 2174 "referrer", although the header field is misspelled.). 2181 2175 </t> … … 2189 2183 </t> 2190 2184 <t> 2191 If the Effective Request URI was obtained from a source that does not have its own2185 If the effective request URI was obtained from a source that does not have its own 2192 2186 URI (e.g., input from the user keyboard), the Referer field &MUST; either be 2193 2187 sent with the value "about:blank", or not be sent at all. Note that this … … 2206 2200 <t> 2207 2201 If the field value is a relative URI, it &SHOULD; be interpreted 2208 relative to the Effective Request URI. The URI &MUST-NOT; include a fragment. See2202 relative to the effective request URI. The URI &MUST-NOT; include a fragment. See 2209 2203 <xref target="encoding.sensitive.information.in.uris"/> for security considerations. 2210 2204 </t> … … 3290 3284 <t> 3291 3285 Deprecate 305 Use Proxy status code, because user agents did not implement it. 3292 It used to indicate that the requestedresource must be accessed through the3286 It used to indicate that the target resource must be accessed through the 3293 3287 proxy given by the Location field. The Location field gave the URI of the 3294 3288 proxy. The recipient was expected to repeat this single request via the proxy. -
draft-ietf-httpbis/latest/p3-payload.xml
r942 r965 260 260 </list> 261 261 </t> 262 <t>263 <iref item="payload"/>264 <x:dfn>payload</x:dfn>265 <list>266 <t>267 The information transferred within a given message is called the268 payload, consisting of optional payload metadata and an optional269 payload body. The payload in HTTP is always a partial or complete270 representation of some resource, though which resource is represented271 is dependent on the type of message (request or response), the272 request method, and the response status code.273 </t>274 </list>275 </t>276 <t>277 <iref item="representation"/>278 <x:dfn>representation</x:dfn>279 <list>280 <t>281 A representation is information in a format that can be readily282 communicated from one party to another. For our purposes, a283 representation is binary data and its associated metadata.284 A representation of a resource is information that reflects the285 state of that resource, as observed at some point in the past286 or to be desired at some point in the future.287 </t>288 </list>289 </t>290 262 </section> 291 263 … … 705 677 </section> 706 678 707 <section title="Representation" anchor="representation"> 708 <t> 709 Request and Response messages &MAY; transfer a representation if not otherwise 710 restricted by the request method or response status code. A representation 711 consists of entity-header fields and a representation body, although some 712 responses will only include the entity-headers. 713 </t> 714 <t> 715 In this section, both sender and recipient refer to either the client 716 or the server, depending on who sends and who receives the message. 717 </t> 718 719 <section title="Entity Header Fields" anchor="entity.header.fields"> 720 <x:anchor-alias value="entity-header"/> 721 <x:anchor-alias value="extension-header"/> 722 <t> 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. 727 </t> 728 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="entity-header"/><iref primary="true" item="Grammar" subitem="extension-header"/> 729 <x:ref>entity-header</x:ref> = <x:ref>Content-Encoding</x:ref> ; <xref target="header.content-encoding"/> 730 / <x:ref>Content-Language</x:ref> ; <xref target="header.content-language"/> 731 / <x:ref>Content-Length</x:ref> ; &header-content-length; 732 / <x:ref>Content-Location</x:ref> ; <xref target="header.content-location"/> 733 / <x:ref>Content-MD5</x:ref> ; <xref target="header.content-md5"/> 734 / <x:ref>Content-Range</x:ref> ; &header-content-range; 735 / <x:ref>Content-Type</x:ref> ; <xref target="header.content-type"/> 736 / <x:ref>Expires</x:ref> ; &header-expires; 737 / <x:ref>Last-Modified</x:ref> ; &header-last-modified; 738 / <x:ref>extension-header</x:ref> 739 740 <x:ref>extension-header</x:ref> = <x:ref>header-field</x:ref> 741 </artwork></figure> 742 <t> 743 The extension-header mechanism allows additional entity-header fields 744 to be defined without changing the protocol, but these fields cannot 745 be assumed to be recognizable by the recipient. Unrecognized header 746 fields &SHOULD; be ignored by the recipient and &MUST; be forwarded by 747 transparent proxies. 748 </t> 679 <section title="Payload" anchor="payload"> 680 <t> 681 HTTP messages &MAY; transfer a payload if not otherwise restricted by 682 the request method or response status code. The payload consists of 683 metadata, in the form of header fields, and data, in the form of the 684 sequence of octets in the message-body after any transfer-coding has 685 been decoded. 686 </t> 687 <iref item="payload"/> 688 <t> 689 A "<x:dfn>payload</x:dfn>" in HTTP is always a partial or complete 690 representation of some resource. We use separate terms for payload 691 and representation because some messages contain only the associated 692 representation's header fields (e.g., responses to HEAD) or only some 693 part(s) of the representation (e.g., the 206 status code). 694 </t> 695 <t> 696 define metadata for the whole representation, which we refer 697 to as "representation header fields", while others define only metadata 698 about what is included in the message, which we 699 </t> 700 <section title="Payload Header Fields" anchor="payload.header.fields"> 701 <x:anchor-alias value="payload-header"/> 702 <t> 703 HTTP header fields that specifically define the payload, rather than the 704 associated representation, are referred to as "payload header fields". 705 The following payload header fields are defined by HTTP/1.1: 706 </t> 707 <figure><artwork> 708 <x:ref>Content-Length</x:ref> ; &header-content-length; 709 <x:ref>Content-MD5</x:ref> ; <xref target="header.content-md5"/> 710 <x:ref>Content-Range</x:ref> ; &header-content-range; 711 </artwork></figure> 749 712 </section> 750 713 751 714 <section title="Payload Body" anchor="payload.body"> 752 715 <x:anchor-alias value="payload-body"/> 753 <t>754 The payload body (if any) sent with an HTTP request or response is in755 a format and encoding defined by the entity-header fields.756 </t>757 716 <t> 758 717 A payload body is only present in a message when a message-body is … … 761 720 have been applied to ensure safe and proper transfer of the message. 762 721 </t> 763 764 <section title="Type" anchor="type"> 765 <t> 766 When a payload body is included with a message, the data type of that 767 body is determined via the header fields Content-Type and Content-Encoding. 722 </section> 723 </section> 724 725 <section title="Representation" anchor="representation"> 726 <iref item="representation"/> 727 <t> 728 A "<x:dfn>representation</x:dfn>" is information in a format that can be readily 729 communicated from one party to another. A resource representation 730 is information that reflects the state of that resource, as observed 731 at some point in the past (e.g., in a response to GET) or to be 732 desired at some point in the future (e.g., in a PUT request). 733 </t> 734 <t> 735 Most, but not all, representations transferred via HTTP are intended 736 to be a representation of the target resource (the resource identified 737 by the effective request URI). The precise semantics of a representation 738 are determined by the type of message (request or response), the request 739 method, the response status code, and the representation metadata. 740 For example, the above semantic is true for the representation in any 741 200 (OK) response to GET and for the representation in any PUT request. 742 A 200 response to PUT, in contrast, contains either a representation 743 that describes the successful action or a representation of the target 744 resource, with the latter indicated by a Content-Location header field 745 with the same value as the effective request URI. Likewise, response 746 messages with an error status code usually contain a representation that 747 describes the error and what next steps are suggested for resolving it. 748 </t> 749 750 <section title="Representation Header Fields" anchor="representation.header.fields"> 751 <x:anchor-alias value="representation-header"/> 752 <t> 753 Representation header fields define metadata about the representation data 754 enclosed in the message-body or, if no message-body is present, about 755 the representation that would have been transferred in a 200 response 756 to a simultaneous GET request with the same effective request URI. 757 </t> 758 <t> 759 The following header fields are defined as representation metadata: 760 </t> 761 <figure><artwork> 762 <x:ref>Content-Encoding</x:ref> ; <xref target="header.content-encoding"/> 763 <x:ref>Content-Language</x:ref> ; <xref target="header.content-language"/> 764 <x:ref>Content-Location</x:ref> ; <xref target="header.content-location"/> 765 <x:ref>Content-Type</x:ref> ; <xref target="header.content-type"/> 766 <x:ref>Expires</x:ref> ; &header-expires; 767 <x:ref>Last-Modified</x:ref> ; &header-last-modified; 768 </artwork></figure> 769 </section> 770 771 <section title="Representation Data" anchor="representation.data"> 772 <x:anchor-alias value="representation-data"/> 773 <t> 774 The representation body associated with an HTTP message is 775 either provided as the payload body of the message or 776 referred to by the message semantics and the effective request 777 URI. The representation data is in a format and encoding defined by 778 the representation metadata header fields. 779 </t> 780 <t> 781 The data type of the representation data 782 is determined via the header fields Content-Type and Content-Encoding. 768 783 These define a two-layer, ordered encoding model: 769 784 </t> 770 785 <figure><artwork type="example"> 771 payload-body := Content-Encoding( Content-Type( data) )772 </artwork></figure> 773 <t> 774 Content-Type specifies the media type of the underlying data . Any HTTP/1.1775 message containing a payload body &SHOULD; include a Content-Type header776 field defining the media type of that body, unless that information is777 unknown.778 </t> 779 <t> 786 representation-data := Content-Encoding( Content-Type( bits ) ) 787 </artwork></figure> 788 <t> 789 Content-Type specifies the media type of the underlying data, which 790 defines both the data format and how that data &SHOULD; be processed 791 by the recipient (within the scope of the request method semantics). 792 Any HTTP/1.1 message containing a payload body &SHOULD; include a 793 Content-Type header field defining the media type of the associated 794 representation unless that metadata is unknown to the sender. 780 795 If the Content-Type header field is not present, it indicates that 781 the sender does not know the media type of the data; recipients &MAY; 782 either assume that it is "application/octet-stream" (<xref target="RFC2046" x:fmt="," x:sec="4.5.1"/>) 796 the sender does not know the media type of the representation; 797 recipients &MAY; either assume that the media type is 798 "application/octet-stream" (<xref target="RFC2046" x:fmt="," x:sec="4.5.1"/>) 783 799 or examine the content to determine its type. 784 800 </t> 785 801 <t> 786 In practice, currently-deployed servers sometimes provide a Content-Type 787 header which does not correctly convey the intended interpretation of the 788 content sent, with the result that some clients will examine the response 789 body's content and override the specified type. 790 </t> 791 <t> 802 In practice, resource owners do not always properly configure their origin 803 server to provide the correct Content-Type for a given representation, 804 with the result that some clients will examine a response body's content 805 and override the specified type. 792 806 Clients that do so risk drawing incorrect conclusions, which might expose 793 additional security risks (e.g., "privilege escalation"). Implementers are 794 encouraged to provide a means of disabling such "content sniffing" when it 795 is used. 807 additional security risks (e.g., "privilege escalation"). Furthermore, 808 it is impossible to determine the sender's intent by examining the data 809 format: many data formats match multiple media types that differ only in 810 processing semantics. Implementers are encouraged to provide a means of 811 disabling such "content sniffing" when it is used. 796 812 </t> 797 813 <t> 798 814 Content-Encoding is used to indicate any additional content 799 815 codings applied to the data, usually for the purpose of data 800 compression, that are a property of the representation. There is 801 no default encoding. 802 </t> 803 </section> 804 816 compression, that are a property of the representation. If 817 Content-Encoding is not present, then there is no additional 818 encoding beyond that defined by the Content-Type. 819 </t> 805 820 </section> 806 821 </section> … … 962 977 This section defines the syntax and semantics of HTTP/1.1 header fields 963 978 related to the payload of messages. 964 </t>965 <t>966 For entity-header fields, both sender and recipient refer to either the967 client or the server, depending on who sends and who receives the message.968 979 </t> 969 980 … … 1309 1320 <x:anchor-alias value="Content-Encoding-v"/> 1310 1321 <t> 1311 The "Content-Encoding" entity-header field indicates what content-codings1322 The "Content-Encoding" header field indicates what content-codings 1312 1323 have been applied to the representation, and thus what decoding mechanisms 1313 1324 must be applied in order to obtain the media-type referenced by the … … 1359 1370 <x:anchor-alias value="Content-Language-v"/> 1360 1371 <t> 1361 The "Content-Language" entity-header field describes the natural1372 The "Content-Language" header field describes the natural 1362 1373 language(s) of the intended audience for the representation. Note that this might 1363 1374 not be equivalent to all the languages used within the representation. … … 1434 1445 <t> 1435 1446 If Content-Location is included in a response message and its value 1436 is the same as the Effective Request URI, then the response payload1447 is the same as the effective request URI, then the response payload 1437 1448 &SHOULD; be considered the current representation of that resource. 1438 1449 For a GET or HEAD request, this is the same as the default semantics … … 1446 1457 <t> 1447 1458 If Content-Location is included in a response message and its value 1448 differs from the Effective Request URI, then the origin server is1459 differs from the effective request URI, then the origin server is 1449 1460 informing recipients that this representation has its own, presumably 1450 1461 more specific, identifier. For a GET or HEAD request, this is an 1451 indication that the Effective Request URI identifies a resource that1462 indication that the effective request URI identifies a resource that 1452 1463 is subject to content negotiation and the representation selected for 1453 1464 this response can also be found at the identified URI. For other … … 1491 1502 </t> 1492 1503 <t> 1493 If the Content-Location value is a partial URI, itis1494 interpreted relative to the Effective Request URI.1504 If the Content-Location value is a partial URI, the partial URI is 1505 interpreted relative to the effective request URI. 1495 1506 </t> 1496 1507 </section> … … 1502 1513 <x:anchor-alias value="Content-MD5-v"/> 1503 1514 <t> 1504 The "Content-MD5" entity-header field, as defined in <xref target="RFC1864"/>, is1515 The "Content-MD5" header field, as defined in <xref target="RFC1864"/>, is 1505 1516 an MD5 digest of the payload body that provides an end-to-end message 1506 1517 integrity check (MIC) of the payload body (the message-body after any … … 1577 1588 <x:anchor-alias value="Content-Type-v"/> 1578 1589 <t> 1579 The "Content-Type" entity-header field indicates the media type of the1590 The "Content-Type" header field indicates the media type of the 1580 1591 representation. In the case of responses to the HEAD method, the media type is 1581 1592 that which would have been sent had the request been a GET. … … 1592 1603 </artwork></figure> 1593 1604 <t> 1594 Further discussion of methods for identifying the media type of a 1595 representation is provided in <xref target="type"/>. 1605 Further discussion of Content-Type is provided in <xref target="representation.data"/>. 1596 1606 </t> 1597 1607 </section> … … 2818 2828 <x:ref>disposition-type</x:ref> = "attachment" / disp-extension-token 2819 2829 2820 <x:ref>entity-header</x:ref> = Content-Encoding / Content-Language / Content-Length2821 / Content-Location / Content-MD5 / Content-Range / Content-Type /2822 Expires / Last-Modified / extension-header2823 <x:ref>extension-header</x:ref> = header-field2824 2825 2830 <x:ref>filename-parm</x:ref> = "filename=" quoted-string 2826 2831 … … 2857 2862 ; MIME-Version defined but not used 2858 2863 ; content-disposition defined but not used 2859 ; entity-header defined but not used2860 2864 </artwork></figure></section> 2861 2865 <?ENDINC p3-payload.abnf-appendix ?> -
draft-ietf-httpbis/latest/p4-conditional.xml
r960 r965 312 312 <x:anchor-alias value="weak"/> 313 313 <t> 314 Entity-tags are used for comparing two or more representations fromthe same315 re quested resource. HTTP/1.1 uses entity-tags in the ETag (<xref target="header.etag"/>),314 Entity-tags are used for comparing two or more representations of the same 315 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 … … 725 725 related to conditional requests. 726 726 </t> 727 <t>728 For entity-header fields, both sender and recipient refer to either the729 client or the server, depending on who sends and who receives the message.730 </t>731 727 732 728 <section title="ETag" anchor="header.etag"> … … 738 734 The "ETag" response-header field provides the current value of the 739 735 entity-tag (see <xref target="entity.tags"/>) for one representation of 740 the resource identified by the Effective Request URI. An entity-tag736 the resource identified by the effective request URI. An entity-tag 741 737 is intended for use as a resource-local identifier for differentiating 742 738 between representations of the same resource that vary over time or via … … 1058 1054 <x:anchor-alias value="Last-Modified-v"/> 1059 1055 <t> 1060 The "Last-Modified" entity-header field indicates the date and time at1056 The "Last-Modified" header field indicates the date and time at 1061 1057 which the origin server believes the representation was last modified. 1062 1058 </t> … … 1098 1094 </t> 1099 1095 <t> 1100 The Last-Modified entity-header field value is often used as a cache1096 The Last-Modified header field value is often used as a cache 1101 1097 validator. In simple terms, a cache entry is considered to be valid 1102 1098 if the representation has not been modified since the Last-Modified value. -
draft-ietf-httpbis/latest/p5-range.xml
r962 r965 397 397 <t> 398 398 If the 206 response is the result of an If-Range request, the response 399 &SHOULD-NOT; include other entity-headers. Otherwise, the response400 &MUST; include all of the entity-headers that would have been returned399 &SHOULD-NOT; include other representation header fields. Otherwise, the response 400 &MUST; include all of the representation header fields that would have been returned 401 401 with a 200 (OK) response to the same request. 402 402 </t> … … 428 428 <t> 429 429 When this status code is returned for a byte-range request, the 430 response &SHOULD; include a Content-Range entity-header field431 specifying the current length of the selected resource(see <xref target="header.content-range"/>).430 response &SHOULD; include a Content-Range header field 431 specifying the current length of the representation (see <xref target="header.content-range"/>). 432 432 This response &MUST-NOT; use the multipart/byteranges content-type. 433 433 </t> … … 467 467 This section defines the syntax and semantics of HTTP/1.1 header fields 468 468 related to range requests and partial responses. 469 </t>470 <t>471 For entity-header fields, both sender and recipient refer to either the472 client or the server, depending on who sends and who receives the message.473 469 </t> 474 470 … … 523 519 <x:anchor-alias value="other-range-resp-spec"/> 524 520 <t> 525 The "Content-Range" entity-header field is sent with a partial representation to526 specify where in the full representation the pa rtialbody should be521 The "Content-Range" header field is sent with a partial representation to 522 specify where in the full representation the payload body should be 527 523 applied. 528 524 </t> … … 1632 1628 <t> 1633 1629 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/220"/>: 1634 "Clarify entity / representation / variant terminology"1635 </t>1636 <t>1637 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/220"/>:1638 1630 "consider removing the 'changes from 2068' sections" 1639 1631 </t> -
draft-ietf-httpbis/latest/p6-cache.xml
r951 r965 504 504 unless: 505 505 <list style="symbols"> 506 <t>The presented Effective Request URI (&effective-request-uri;) and506 <t>The presented effective request URI (&effective-request-uri;) and 507 507 that of the stored response match, and</t> 508 508 <t>the request method associated with the stored response allows it to … … 868 868 An invalidation based on a URI from a Location or Content-Location header 869 869 &MUST-NOT; be performed if the host part of that URI differs from the host 870 part in the Effective Request URI (&effective-request-uri;). This helps870 part in the effective request URI (&effective-request-uri;). This helps 871 871 prevent denial of service attacks. 872 872 </t> 873 873 <t> 874 874 A cache that passes through requests for methods it does not understand 875 &SHOULD; invalidate the Effective Request URI (&effective-request-uri;).875 &SHOULD; invalidate the effective request URI (&effective-request-uri;). 876 876 </t> 877 877 <t> 878 878 Here, "invalidate" means that the cache will either remove all stored 879 responses related to the Effective Request URI, or will mark these as879 responses related to the effective request URI, or will mark these as 880 880 "invalid" and in need of a mandatory validation before they can be returned 881 881 in response to a subsequent request. … … 1010 1010 related to caching. 1011 1011 </t> 1012 <t>1013 For entity-header fields, both sender and recipient refer to either the1014 client or the server, depending on who sends and who receives the message.1015 </t>1016 1012 1017 1013 <section anchor="header.age" title="Age"> … … 1435 1431 <x:anchor-alias value="Expires-v"/> 1436 1432 <t> 1437 The "Expires" entity-header field gives the date/time after which the1433 The "Expires" header field gives the date/time after which the 1438 1434 response is considered stale. See <xref target="expiration.model" /> for 1439 1435 further discussion of the freshness model. … … 2608 2604 <list style="symbols"> 2609 2605 <t> 2606 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/109"/>: 2607 "Clarify entity / representation / variant terminology" 2608 </t> 2609 <t> 2610 2610 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/220"/>: 2611 2611 "consider removing the 'changes from 2068' sections" -
draft-ietf-httpbis/latest/p7-auth.xml
r961 r965 303 303 The request requires user authentication. The response &MUST; include a 304 304 WWW-Authenticate header field (<xref target="header.www-authenticate"/>) containing a challenge 305 applicable to the requestedresource. The client &MAY; repeat the305 applicable to the target resource. The client &MAY; repeat the 306 306 request with a suitable Authorization header field (<xref target="header.authorization"/>). If 307 307 the request already included Authorization credentials, then the 401 … … 323 323 client must first authenticate itself with the proxy. The proxy &MUST; 324 324 return a Proxy-Authenticate header field (<xref target="header.proxy-authenticate"/>) containing a 325 challenge applicable to the proxy for the requestedresource. The325 challenge applicable to the proxy for the target resource. The 326 326 client &MAY; repeat the request with a suitable Proxy-Authorization 327 327 header field (<xref target="header.proxy-authorization"/>). HTTP access authentication is explained … … 402 402 The "Proxy-Authenticate" response-header field consists of a challenge that 403 403 indicates the authentication scheme and parameters applicable to the proxy 404 for this Effective Request URI (&effective-request-uri;). It &MUST; be included as part404 for this effective request URI (&effective-request-uri;). It &MUST; be included as part 405 405 of a 407 (Proxy Authentication Required) response. 406 406 </t> … … 461 461 The "WWW-Authenticate" response-header field consists of at least one 462 462 challenge that indicates the authentication scheme(s) and parameters 463 applicable to the Effective Request URI (&effective-request-uri;). It &MUST; be included in 401463 applicable to the effective request URI (&effective-request-uri;). It &MUST; be included in 401 464 464 (Unauthorized) response messages. 465 465 </t>
Note: See TracChangeset
for help on using the changeset viewer.