Changeset 965 for draft-ietf-httpbis/latest/p2-semantics.xml
- Timestamp:
- 30/07/10 06:11:34 (12 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
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.
Note: See TracChangeset
for help on using the changeset viewer.