Changeset 2098 for draft-ietf-httpbis/latest/p2-semantics.xml
- Timestamp:
- 07/01/13 09:02:41 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.xml
r2097 r2098 1654 1654 The response payload, if any, might also describe the communication options 1655 1655 in a machine or human-readable representation. A standard format for such a 1656 payloadis not defined by this specification, but might be defined by1656 representation is not defined by this specification, but might be defined by 1657 1657 future extensions to HTTP. 1658 1658 A server &MUST; generate a <x:ref>Content-Length</x:ref> field with a value … … 2516 2516 For example, if an unrecognized status code of 471 is received by a client, 2517 2517 the client can assume that there was something wrong with its request and 2518 treat the response as if it had received a 400 status code. If the response 2519 includes a message body, it will usually include a representation that 2520 explains the response status. 2518 treat the response as if it had received a 400 status code. The response 2519 message will usually contain a representation that explains the status. 2521 2520 </t> 2522 2521 <t> … … 2700 2699 <t> 2701 2700 The <x:dfn>200 (OK)</x:dfn> status code indicates that the request has 2702 succeeded. The payload sent in the response2703 is dependent on the method used in the request, for example:2701 succeeded. The meaning of a payload sent in the response depends on the 2702 request method, as follows: 2704 2703 <list style="hanging"> 2705 2704 <t hangText="GET"> … … 2707 2706 </t> 2708 2707 <t hangText="HEAD"> 2709 the same representation as GET, except without the message body;2708 the same representation as GET, but without the representation data; 2710 2709 </t> 2711 2710 <t hangText="POST"> … … 2754 2753 completed. The request might or might not eventually be acted upon, as it 2755 2754 might be disallowed when processing actually takes place. There is no 2756 facility for re-sending a status code from an asynchronous operation such2757 as this.2755 facility in HTTP for re-sending a status code from an asynchronous 2756 operation. 2758 2757 </t> 2759 2758 <t> … … 2763 2762 requiring that the user agent's connection to the server persist 2764 2763 until the process is completed. The representation sent with this 2765 response ought to describe the request's current status 2766 and either a pointer to a status monitor or some estimate of when the2767 user can expect the request tobe fulfilled.2764 response ought to describe the request's current status and point to 2765 (or embed) a status monitor that can provide the user with an estimate of 2766 when the request will be fulfilled. 2768 2767 </t> 2769 2768 </section> … … 2796 2795 has successfully fulfilled the request and that there is no additional 2797 2796 content to send in the response payload body. Metadata in the response 2798 header fields refer to the <x:ref>target resource</x:ref> and its current representation2799 after the requested action.2797 header fields refer to the <x:ref>target resource</x:ref> and its 2798 selected representation after the requested action was applied. 2800 2799 </t> 2801 2800 <t> … … 2822 2821 </t> 2823 2822 <t> 2824 A 204 response does not include a message body, and thus is always2825 terminated by the first empty line after the header fields.2823 A 204 response is terminated by the first empty line after the header 2824 fields because it cannot contain a message body. 2826 2825 </t> 2827 2826 </section> … … 2941 2940 <t> 2942 2941 The <x:dfn>300 (Multiple Choices)</x:dfn> status code indicates that the 2943 <x:ref>target resource</x:ref> has more than one representation, each with its own more2944 specific identifier, and information about the alternatives is being2945 provided so that the user (or user agent) can select a preferred2942 <x:ref>target resource</x:ref> has more than one representation, each with 2943 its own more specific identifier, and information about the alternatives is 2944 being provided so that the user (or user agent) can select a preferred 2946 2945 representation by redirecting its request to one or more of those 2947 2946 identifiers. In other words, the server desires that the user agent engage 2948 2947 in reactive negotiation to select the most appropriate representation(s) 2949 2948 for its needs (&content-negotiation;). 2949 </t> 2950 <t> 2951 If the server has a preferred choice, the server &SHOULD; generate a 2952 <x:ref>Location</x:ref> header field containing a preferred choice's URI 2953 reference. The user agent &MAY; use the Location field value for automatic 2954 redirection. 2950 2955 </t> 2951 2956 <t> … … 2958 2963 </t> 2959 2964 <t> 2960 If the server has a preferred choice, the server &SHOULD; generate a2961 <x:ref>Location</x:ref> header field containing a preferred choice's URI2962 reference. The user agent &MAY; use the Location field value for automatic2963 redirection.2964 </t>2965 <t>2966 2965 Caches &MAY; use a heuristic (see &p6-heuristic;) to determine 2967 2966 freshness for 300 responses. 2968 2967 </t> 2969 2968 <x:note> 2969 <t> 2970 &Note; The original proposal for 300 defined the URI header field as 2971 providing a list of alternative representations, such that it would be 2972 usable for 200, 300, and 406 responses and be transferred in responses to 2973 the HEAD method. However, lack of deployment and disagreement over syntax 2974 led to both URI and Alternates (a subsequent proposal) being dropped from 2975 this specification. It is possible to communicate the list using a set of 2976 Link header fields <xref target="RFC5988"/>, each with a relationship of 2977 "alternate", though deployment is a chicken-and-egg problem. 2978 </t> 2979 </x:note> 2970 2980 </section> 2971 2981 … … 3221 3231 A user agent &MAY; automatically select the most appropriate choice from 3222 3232 that list. However, this specification does not define any standard for 3223 such automatic selection. [The original proposal for 406 defined the 3224 Alternates header field as providing a list of alternative representations, 3225 such that it would be available for responses to the HEAD method, but lack 3226 of deployment led to Alternates being dropped from the specification.] 3233 such automatic selection, as described in <xref target="status.300"/>. 3227 3234 </t> 3228 3235 </section> … … 5516 5523 </reference> 5517 5524 5525 <reference anchor='RFC5988'> 5526 <front> 5527 <title>Web Linking</title> 5528 <author initials='M.' surname='Nottingham' fullname='M. Nottingham'> 5529 <organization /></author> 5530 <date year='2010' month='October' /> 5531 </front> 5532 <seriesInfo name='RFC' value='5988' /> 5533 </reference> 5534 5518 5535 <reference anchor="RFC6265"> 5519 5536 <front>
Note: See TracChangeset
for help on using the changeset viewer.