Changeset 391 for draft-ietf-httpbis/latest/p2-semantics.xml
- Timestamp:
- 15/11/08 00:44:55 (14 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.xml
r386 r391 333 333 <x:anchor-alias value="If-Range"/> 334 334 <x:anchor-alias value="If-Unmodified-Since"/> 335 <x:anchor-alias value="partial-URI"/> 335 336 <x:anchor-alias value="product"/> 336 337 <x:anchor-alias value="Proxy-Authenticate"/> 337 338 <x:anchor-alias value="Proxy-Authorization"/> 338 339 <x:anchor-alias value="Range"/> 339 <x:anchor-alias value="relativeURI"/>340 340 <x:anchor-alias value="TE"/> 341 341 <x:anchor-alias value="Vary"/> … … 348 348 <x:ref>Host</x:ref> = <Host, defined in &uri;> 349 349 <x:ref>HTTP-date</x:ref> = <HTTP-date, defined in &full-date;> 350 <x:ref>partial-URI</x:ref> = <partial-URI, defined in &uri;> 350 351 <x:ref>product</x:ref> = <product, defined in &product-tokens;> 351 <x:ref>relativeURI</x:ref> = <relativeURI, defined in &uri;>352 352 <x:ref>TE</x:ref> = <TE, defined in &header-te;> 353 353 </artwork></figure> … … 395 395 <t> 396 396 The Method token indicates the method to be performed on the 397 resource identified by the Request-URI. The method is case-sensitive.397 resource identified by the request-target. The method is case-sensitive. 398 398 </t> 399 399 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Method"/><iref primary="true" item="Grammar" subitem="extension-method"/> … … 541 541 / "412" ; <xref target="status.412"/>: Precondition Failed 542 542 / "413" ; <xref target="status.413"/>: Request Entity Too Large 543 / "414" ; <xref target="status.414"/>: Request- URIToo Large543 / "414" ; <xref target="status.414"/>: Request-target Too Large 544 544 / "415" ; <xref target="status.415"/>: Unsupported Media Type 545 545 / "416" ; <xref target="status.416"/>: Requested range not satisfiable … … 596 596 information about the response which cannot be placed in the Status-Line. 597 597 These header fields give information about the server and about 598 further access to the resource identified by the Request-URI.598 further access to the resource identified by the request-target. 599 599 </t> 600 600 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="response-header"/> … … 706 706 The OPTIONS method represents a request for information about the 707 707 communication options available on the request/response chain 708 identified by the Request-URI. This method allows the client to708 identified by the request-target. This method allows the client to 709 709 determine the options and/or requirements associated with a resource, 710 710 or the capabilities of a server, without implying a resource action … … 723 723 </t> 724 724 <t> 725 If the Request-URIis an asterisk ("*"), the OPTIONS request is725 If the request-target is an asterisk ("*"), the OPTIONS request is 726 726 intended to apply to the server in general rather than to a specific 727 727 resource. Since a server's communication options typically depend on … … 732 732 </t> 733 733 <t> 734 If the Request-URIis not an asterisk, the OPTIONS request applies734 If the request-target is not an asterisk, the OPTIONS request applies 735 735 only to the options that are available when communicating with that 736 736 resource. … … 770 770 <t> 771 771 The GET method means retrieve whatever information (in the form of an 772 entity) is identified by the Request-URI. If the Request-URIrefers772 entity) is identified by the request-target. If the request-target refers 773 773 to a data-producing process, it is the produced data which shall be 774 774 returned as the entity in the response and not the source text of the … … 835 835 The POST method is used to request that the origin server accept the 836 836 entity enclosed in the request as data to be processed by the resource 837 identified by the Request-URIin the Request-Line. POST is designed837 identified by the request-target in the Request-Line. POST is designed 838 838 to allow a uniform method to cover the following functions: 839 839 <list style="symbols"> … … 856 856 <t> 857 857 The actual function performed by the POST method is determined by the 858 server and is usually dependent on the Request-URI.858 server and is usually dependent on the request-target. 859 859 </t> 860 860 <t> … … 884 884 <t> 885 885 The PUT method requests that the enclosed entity be stored at the 886 supplied Request-URI. If the Request-URIrefers to an already886 supplied request-target. If the request-target refers to an already 887 887 existing resource, the enclosed entity &SHOULD; be considered as a 888 888 modified version of the one residing on the origin server. If the 889 Request-URIdoes not point to an existing resource, and that URI is889 request-target does not point to an existing resource, and that URI is 890 890 capable of being defined as a new resource by the requesting user 891 891 agent, the origin server can create the resource with that URI. If a 892 new resource is created at the Request-URI, the origin server &MUST;892 new resource is created at the request-target, the origin server &MUST; 893 893 inform the user agent 894 894 via the 201 (Created) response. If an existing resource is modified, 895 895 either the 200 (OK) or 204 (No Content) response codes &SHOULD; be sent 896 896 to indicate successful completion of the request. If the resource 897 could not be created or modified with the Request-URI, an appropriate897 could not be created or modified with the request-target, an appropriate 898 898 error response &SHOULD; be given that reflects the nature of the 899 899 problem. The recipient of the entity &MUST-NOT; ignore any Content-* … … 903 903 </t> 904 904 <t> 905 If the request passes through a cache and the Request-URIidentifies905 If the request passes through a cache and the request-target identifies 906 906 one or more currently cached entities, those entries &SHOULD; be 907 907 treated as stale. Responses to this method are not cacheable. … … 909 909 <t> 910 910 The fundamental difference between the POST and PUT requests is 911 reflected in the different meaning of the Request-URI. The URI in a911 reflected in the different meaning of the request-target. The URI in a 912 912 POST request identifies the resource that will handle the enclosed 913 913 entity. That resource might be a data-accepting process, a gateway to … … 944 944 <t> 945 945 The DELETE method requests that the origin server delete the resource 946 identified by the Request-URI. This method &MAY; be overridden by human946 identified by the request-target. This method &MAY; be overridden by human 947 947 intervention (or other means) on the origin server. The client cannot 948 948 be guaranteed that the operation has been carried out, even if the … … 960 960 </t> 961 961 <t> 962 If the request passes through a cache and the Request-URIidentifies962 If the request passes through a cache and the request-target identifies 963 963 one or more currently cached entities, those entries &SHOULD; be 964 964 treated as stale. Responses to this method are not cacheable. … … 1267 1267 future references to this resource &SHOULD; use one of the returned 1268 1268 URIs. Clients with link editing capabilities ought to automatically 1269 re-link references to the Request-URIto one or more of the new1269 re-link references to the request-target to one or more of the new 1270 1270 references returned by the server, where possible. This response is 1271 1271 cacheable unless indicated otherwise. … … 1298 1298 The requested resource resides temporarily under a different URI. 1299 1299 Since the redirection might be altered on occasion, the client &SHOULD; 1300 continue to use the Request-URIfor future requests. This response1300 continue to use the request-target for future requests. This response 1301 1301 is only cacheable if indicated by a Cache-Control or Expires header 1302 1302 field. … … 1400 1400 The requested resource resides temporarily under a different URI. 1401 1401 Since the redirection &MAY; be altered on occasion, the client &SHOULD; 1402 continue to use the Request-URIfor future requests. This response1402 continue to use the request-target for future requests. This response 1403 1403 is only cacheable if indicated by a Cache-Control or Expires header 1404 1404 field. … … 1487 1487 <iref primary="true" item="Status Codes" subitem="404 Not Found" x:for-anchor=""/> 1488 1488 <t> 1489 The server has not found anything matching the Request-URI. No1489 The server has not found anything matching the request-target. No 1490 1490 indication is given of whether the condition is temporary or 1491 1491 permanent. The 410 (Gone) status code &SHOULD; be used if the server … … 1503 1503 <t> 1504 1504 The method specified in the Request-Line is not allowed for the 1505 resource identified by the Request-URI. The response &MUST; include an1505 resource identified by the request-target. The response &MUST; include an 1506 1506 Allow header containing a list of valid methods for the requested 1507 1507 resource. … … 1592 1592 forwarding address is known. This condition is expected to be 1593 1593 considered permanent. Clients with link editing capabilities &SHOULD; 1594 delete references to the Request-URIafter user approval. If the1594 delete references to the request-target after user approval. If the 1595 1595 server does not know, or has no facility to determine, whether or not 1596 1596 the condition is permanent, the status code 404 (Not Found) &SHOULD; be … … 1647 1647 </section> 1648 1648 1649 <section title="414 Request- URIToo Long" anchor="status.414">1650 <iref primary="true" item="414 Request- URIToo Long (status code)" x:for-anchor=""/>1651 <iref primary="true" item="Status Codes" subitem="414 Request- URIToo Long" x:for-anchor=""/>1652 <t> 1653 The server is refusing to service the request because the Request-URI1649 <section title="414 Request-target Too Long" anchor="status.414"> 1650 <iref primary="true" item="414 Request-target Too Long (status code)" x:for-anchor=""/> 1651 <iref primary="true" item="Status Codes" subitem="414 Request-target Too Long" x:for-anchor=""/> 1652 <t> 1653 The server is refusing to service the request because the request-target 1654 1654 is longer than the server is willing to interpret. This rare 1655 1655 condition is only likely to occur when a client has improperly … … 1659 1659 itself), or when the server is under attack by a client attempting to 1660 1660 exploit security holes present in some servers using fixed-length 1661 buffers for reading or manipulating the Request-URI.1661 buffers for reading or manipulating the request-target. 1662 1662 </t> 1663 1663 </section> … … 1804 1804 <t> 1805 1805 The response-header field "Allow" lists the set of methods advertised as 1806 supported by the resource identified by the Request-URI. The purpose of1806 supported by the resource identified by the request-target. The purpose of 1807 1807 this field is strictly to inform the recipient of valid methods 1808 1808 associated with the resource. An Allow header field &MUST; be … … 1943 1943 The response-header field "Location" is used for the identification of a 1944 1944 new resource or to redirect the recipient to a location other than the 1945 Request-URIfor completion of the request. For 201 (Created)1945 request-target for completion of the request. For 201 (Created) 1946 1946 responses, the Location is that of the new resource which was created 1947 1947 by the request. For 3xx responses, the location &SHOULD; indicate the … … 2023 2023 The request-header field "Referer" [sic] allows the client to specify, 2024 2024 for the server's benefit, the address (URI) of the resource from 2025 which the Request-URIwas obtained (the "referrer", although the2025 which the request-target was obtained (the "referrer", although the 2026 2026 header field is misspelled.) The Referer request-header allows a 2027 2027 server to generate lists of back-links to resources for interest, 2028 2028 logging, optimized caching, etc. It also allows obsolete or mistyped 2029 2029 links to be traced for maintenance. The Referer field &MUST-NOT; be 2030 sent if the Request-URIwas obtained from a source that does not have2030 sent if the request-target was obtained from a source that does not have 2031 2031 its own URI, such as input from the user keyboard. 2032 2032 </t> 2033 2033 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Referer"/><iref primary="true" item="Grammar" subitem="Referer-v"/> 2034 2034 <x:ref>Referer</x:ref> = "Referer" ":" <x:ref>OWS</x:ref> <x:ref>Referer-v</x:ref> 2035 <x:ref>Referer-v</x:ref> = <x:ref>absolute-URI</x:ref> / <x:ref> relativeURI</x:ref>2035 <x:ref>Referer-v</x:ref> = <x:ref>absolute-URI</x:ref> / <x:ref>partial-URI</x:ref> 2036 2036 </artwork></figure> 2037 2037 <t> … … 2043 2043 <t> 2044 2044 If the field value is a relative URI, it &SHOULD; be interpreted 2045 relative to the Request-URI. The URI &MUST-NOT; include a fragment. See2045 relative to the request-target. The URI &MUST-NOT; include a fragment. See 2046 2046 <xref target="encoding.sensitive.information.in.uris"/> for security considerations. 2047 2047 </t> … … 2387 2387 </c> 2388 2388 <c>414</c> 2389 <c>Request- URIToo Long</c>2389 <c>Request-target Too Long</c> 2390 2390 <c> 2391 2391 <xref target="status.414"/> … … 2592 2592 Authors of services should not use 2593 2593 GET-based forms for the submission of sensitive data because that 2594 data will be encoded in the Request- URI. Many existing2595 servers, proxies, and user agents log or display the Request- URIin2594 data will be encoded in the Request-target. Many existing 2595 servers, proxies, and user agents log or display the Request-target in 2596 2596 places where it might be visible to third parties. Such services can 2597 2597 use POST-based form submission instead.
Note: See TracChangeset
for help on using the changeset viewer.