Changeset 1618 for draft-ietf-httpbis/latest/p2-semantics.xml
- Timestamp:
- 26/03/12 14:21:18 (11 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.xml
r1617 r1618 596 596 information which will explain the unusual status. 597 597 </t> 598 <t> 599 The first digit of the status-code defines the class of response. The 600 last two digits do not have any categorization role. There are 5 601 values for the first digit: 602 <list style="symbols"> 603 <t> 604 1xx: Informational - Request received, continuing process 605 </t> 606 <t> 607 2xx: Success - The action was successfully received, 608 understood, and accepted 609 </t> 610 <t> 611 3xx: Redirection - Further action needs to be taken in order to 612 complete the request 613 </t> 614 <t> 615 4xx: Client Error - The request contains bad syntax or cannot 616 be fulfilled 617 </t> 618 <t> 619 5xx: Server Error - The server failed to fulfill an apparently 620 valid request 621 </t> 622 </list> 623 </t> 598 624 599 625 <section title="Overview of Status Codes" anchor="overview.of.status.codes"> … … 713 739 </section> 714 740 715 </section>716 717 <section title="Representation" anchor="representation">718 <t>719 Request and Response messages &MAY; transfer a representation if not otherwise720 restricted by the request method or response status code. A representation721 consists of metadata (representation header fields) and data (representation722 body). When a complete or partial representation is enclosed in an HTTP message,723 it is referred to as the payload of the message. HTTP representations724 are defined in &payload;.725 </t>726 <t>727 A representation body is only present in a message when a message body is728 present, as described in &message-body;. The representation body is obtained729 from the message body by decoding any Transfer-Encoding that might730 have been applied to ensure safe and proper transfer of the message.731 </t>732 733 <section title="Identifying the Resource Associated with a Representation" anchor="identifying.response.associated.with.representation">734 <t>735 It is sometimes necessary to determine an identifier for the resource736 associated with a representation.737 </t>738 <t>739 An HTTP request representation, when present, is always associated with an740 anonymous (i.e., unidentified) resource.741 </t>742 <t>743 In the common case, an HTTP response is a representation of the target744 resource (see &effective-request-uri;). However, this is not always the745 case. To determine the URI of the resource a response is associated with,746 the following rules are used (with the first applicable one being selected):747 </t>748 <t><list style="numbers">749 <t>If the response status code is 200 or 203 and the request method was GET,750 the response payload is a representation of the target resource.</t>751 <t>If the response status code is 204, 206, or 304 and the request method was GET752 or HEAD, the response payload is a partial representation of the target753 resource.</t>754 <t>If the response has a Content-Location header field, and that URI is the same755 as the effective request URI, the response payload is a representation of the756 target resource.</t>757 <t>If the response has a Content-Location header field, and that URI is not the758 same as the effective request URI, then the response asserts that its759 payload is a representation of the resource identified by the760 Content-Location URI. However, such an assertion cannot be trusted unless761 it can be verified by other means (not defined by HTTP).</t>762 <t>Otherwise, the response is a representation of an anonymous (i.e.,763 unidentified) resource.</t>764 </list></t>765 <t>766 <cref anchor="TODO-req-uri">767 The comparison function is going to have to be defined somewhere,768 because we already need to compare URIs for things like cache invalidation.</cref>769 </t>770 </section>771 772 </section>773 774 775 <section title="Method Definitions" anchor="method.definitions">776 <t>777 The set of common request methods for HTTP/1.1 is defined below. Although778 this set can be expanded, additional methods cannot be assumed to779 share the same semantics for separately extended clients and servers.780 </t>781 782 <section title="Safe and Idempotent Methods" anchor="safe.and.idempotent">783 784 <section title="Safe Methods" anchor="safe.methods">785 <iref item="Safe Methods" primary="true"/>786 <t>787 Implementors need to be aware that the software represents the user in788 their interactions over the Internet, and need to allow789 the user to be aware of any actions they take which might have an790 unexpected significance to themselves or others.791 </t>792 <t>793 In particular, the convention has been established that the GET, HEAD,794 OPTIONS, and TRACE request methods &SHOULD-NOT; have the significance795 of taking an action other than retrieval. These request methods ought796 to be considered "<x:dfn anchor="safe">safe</x:dfn>".797 This allows user agents to represent other methods, such as POST, PUT798 and DELETE, in a special way, so that the user is made aware of the799 fact that a possibly unsafe action is being requested.800 </t>801 <t>802 Naturally, it is not possible to ensure that the server does not803 generate side-effects as a result of performing a GET request; in804 fact, some dynamic resources consider that a feature. The important805 distinction here is that the user did not request the side-effects,806 so therefore cannot be held accountable for them.807 </t>808 </section>809 810 <section title="Idempotent Methods" anchor="idempotent.methods">811 <iref item="Idempotent Methods" primary="true"/>812 <t>813 Request methods can also have the property of "idempotence" in that,814 aside from error or expiration issues, the intended effect of multiple815 identical requests is the same as for a single request.816 PUT, DELETE, and all safe request methods are idempotent.817 It is important to note that idempotence refers only to changes818 requested by the client: a server is free to change its state due819 to multiple requests for the purpose of tracking those requests,820 versioning of results, etc.821 </t>822 </section>823 </section>824 825 <section title="OPTIONS" anchor="OPTIONS">826 <rdf:Description>827 <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe>828 </rdf:Description>829 <iref primary="true" item="OPTIONS method" x:for-anchor=""/>830 <iref primary="true" item="Methods" subitem="OPTIONS" x:for-anchor=""/>831 <t>832 The OPTIONS method requests information about the833 communication options available on the request/response chain834 identified by the effective request URI. This method allows a client to835 determine the options and/or requirements associated with a resource,836 or the capabilities of a server, without implying a resource action837 or initiating a resource retrieval.838 </t>839 <t>840 Responses to the OPTIONS method are not cacheable.841 </t>842 <t>843 If the OPTIONS request includes a message body (as indicated by the844 presence of Content-Length or Transfer-Encoding), then the media type845 &MUST; be indicated by a Content-Type field. Although this846 specification does not define any use for such a body, future847 extensions to HTTP might use the OPTIONS body to make more detailed848 queries on the server.849 </t>850 <t>851 If the request-target (&request-target;) is an asterisk ("*"),852 the OPTIONS request is853 intended to apply to the server in general rather than to a specific854 resource. Since a server's communication options typically depend on855 the resource, the "*" request is only useful as a "ping" or "no-op"856 type of method; it does nothing beyond allowing the client to test857 the capabilities of the server. For example, this can be used to test858 a proxy for HTTP/1.1 conformance (or lack thereof).859 </t>860 <t>861 If the request-target is not an asterisk, the OPTIONS request applies862 only to the options that are available when communicating with that863 resource.864 </t>865 <t>866 A 200 response &SHOULD; include any header fields that indicate867 optional features implemented by the server and applicable to that868 resource (e.g., Allow), possibly including extensions not defined by869 this specification. The response body, if any, &SHOULD; also include870 information about the communication options. The format for such a871 body is not defined by this specification, but might be defined by872 future extensions to HTTP. Content negotiation &MAY; be used to select873 the appropriate response format. If no response body is included, the874 response &MUST; include a Content-Length field with a field-value of875 "0".876 </t>877 <t>878 The Max-Forwards header field &MAY; be used to target a879 specific proxy in the request chain (see <xref target="header.max-forwards"/>).880 If no Max-Forwards field is present in the request, then the forwarded881 request &MUST-NOT; include a Max-Forwards field.882 </t>883 </section>884 885 <section title="GET" anchor="GET">886 <rdf:Description>887 <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe>888 </rdf:Description>889 <iref primary="true" item="GET method" x:for-anchor=""/>890 <iref primary="true" item="Methods" subitem="GET" x:for-anchor=""/>891 <t>892 The GET method requests transfer of a current representation of893 the target resource.894 </t>895 <t>896 If the target resource is a data-producing process, it is the897 produced data which shall be returned as the representation in the response and not898 the source text of the process, unless that text happens to be the output of899 the process.900 </t>901 <t>902 The semantics of the GET method change to a "conditional GET" if the903 request message includes an If-Modified-Since, If-Unmodified-Since,904 If-Match, If-None-Match, or If-Range header field. A conditional GET905 requests that the representation be transferred only under the906 circumstances described by the conditional header field(s). The907 conditional GET request is intended to reduce unnecessary network908 usage by allowing cached representations to be refreshed without requiring909 multiple requests or transferring data already held by the client.910 </t>911 <t>912 The semantics of the GET method change to a "partial GET" if the913 request message includes a Range header field. A partial GET requests914 that only part of the representation be transferred, as described in &header-range;.915 The partial GET request is intended to reduce unnecessary916 network usage by allowing partially-retrieved representations to be917 completed without transferring data already held by the client.918 </t>919 <t>920 Bodies on GET requests have no defined semantics. Note that sending a body921 on a GET request might cause some existing implementations to reject the922 request.923 </t>924 <t>925 The response to a GET request is cacheable and &MAY; be used to satisfy926 subsequent GET and HEAD requests (see &caching;).927 </t>928 <t>929 See <xref target="encoding.sensitive.information.in.uris"/> for security considerations when used for forms.930 </t>931 </section>932 933 <section title="HEAD" anchor="HEAD">934 <rdf:Description>935 <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe>936 </rdf:Description>937 <iref primary="true" item="HEAD method" x:for-anchor=""/>938 <iref primary="true" item="Methods" subitem="HEAD" x:for-anchor=""/>939 <t>940 The HEAD method is identical to GET except that the server &MUST-NOT;941 return a message body in the response. The metadata contained942 in the HTTP header fields in response to a HEAD request &SHOULD; be identical943 to the information sent in response to a GET request. This method can944 be used for obtaining metadata about the representation implied by the945 request without transferring the representation body. This method is946 often used for testing hypertext links for validity, accessibility,947 and recent modification.948 </t>949 <t>950 The response to a HEAD request is cacheable and &MAY; be used to satisfy951 a subsequent HEAD request. It also has potential side effects on952 previously stored responses to GET; see &p6-head;.953 </t>954 <t>955 Bodies on HEAD requests have no defined semantics. Note that sending a body956 on a HEAD request might cause some existing implementations to reject the957 request.958 </t>959 </section>960 961 <section title="POST" anchor="POST">962 <iref primary="true" item="POST method" x:for-anchor=""/>963 <iref primary="true" item="Methods" subitem="POST" x:for-anchor=""/>964 <t>965 The POST method requests that the origin server accept the966 representation enclosed in the request as data to be processed by the967 target resource. POST is designed to allow a uniform method to cover the968 following functions:969 <list style="symbols">970 <t>971 Annotation of existing resources;972 </t>973 <t>974 Posting a message to a bulletin board, newsgroup, mailing list,975 or similar group of articles;976 </t>977 <t>978 Providing a block of data, such as the result of submitting a979 form, to a data-handling process;980 </t>981 <t>982 Extending a database through an append operation.983 </t>984 </list>985 </t>986 <t>987 The actual function performed by the POST method is determined by the988 server and is usually dependent on the effective request URI.989 </t>990 <t>991 The action performed by the POST method might not result in a992 resource that can be identified by a URI. In this case, either 200993 (OK) or 204 (No Content) is the appropriate response status code,994 depending on whether or not the response includes a representation that995 describes the result.996 </t>997 <t>998 If a resource has been created on the origin server, the response999 &SHOULD; be 201 (Created) and contain a representation which describes the1000 status of the request and refers to the new resource, and a Location1001 header field (see <xref target="header.location"/>).1002 </t>1003 <t>1004 Responses to POST requests are only cacheable when they1005 include explicit freshness information (see &p6-explicit;). A1006 cached POST response with a Content-Location header field1007 (see &header-content-location;) whose value is the effective1008 Request URI &MAY; be used to satisfy subsequent GET and HEAD requests.1009 </t>1010 <t>1011 Note that POST caching is not widely implemented.1012 However, the 303 (See Other) response can be used to direct the1013 user agent to retrieve a cacheable representation of the resource.1014 </t>1015 </section>1016 1017 <section title="PUT" anchor="PUT">1018 <iref primary="true" item="PUT method" x:for-anchor=""/>1019 <iref primary="true" item="Methods" subitem="PUT" x:for-anchor=""/>1020 <t>1021 The PUT method requests that the state of the target resource1022 be created or replaced with the state defined by the representation1023 enclosed in the request message payload. A successful PUT of a given1024 representation would suggest that a subsequent GET on that same target1025 resource will result in an equivalent representation being returned in1026 a 200 (OK) response. However, there is no guarantee that such a state1027 change will be observable, since the target resource might be acted1028 upon by other user agents in parallel, or might be subject to dynamic1029 processing by the origin server, before any subsequent GET is received.1030 A successful response only implies that the user agent's intent was1031 achieved at the time of its processing by the origin server.1032 </t>1033 <t>1034 If the target resource does not have a current representation and1035 the PUT successfully creates one, then the origin server &MUST; inform1036 the user agent by sending a 201 (Created) response. If the target1037 resource does have a current representation and that representation is1038 successfully modified in accordance with the state of the enclosed1039 representation, then either a 200 (OK) or 204 (No Content) response1040 &SHOULD; be sent to indicate successful completion of the request.1041 </t>1042 <t>1043 Unrecognized header fields &SHOULD; be ignored (i.e., not saved1044 as part of the resource state).1045 </t>1046 <t>1047 An origin server &SHOULD; verify that the PUT representation is1048 consistent with any constraints which the server has for the target1049 resource that cannot or will not be changed by the PUT. This is1050 particularly important when the origin server uses internal1051 configuration information related to the URI in order to set the1052 values for representation metadata on GET responses. When a PUT1053 representation is inconsistent with the target resource, the origin1054 server &SHOULD; either make them consistent, by transforming the1055 representation or changing the resource configuration, or respond1056 with an appropriate error message containing sufficient information1057 to explain why the representation is unsuitable. The 409 (Conflict)1058 or 415 (Unsupported Media Type) status codes are suggested, with the1059 latter being specific to constraints on Content-Type values.1060 </t>1061 <t>1062 For example, if the target resource is configured to always have a1063 Content-Type of "text/html" and the representation being PUT has a1064 Content-Type of "image/jpeg", then the origin server &SHOULD; do one of:1065 (a) reconfigure the target resource to reflect the new media type;1066 (b) transform the PUT representation to a format consistent with that1067 of the resource before saving it as the new resource state; or,1068 (c) reject the request with a 415 response indicating that the target1069 resource is limited to "text/html", perhaps including a link to a1070 different resource that would be a suitable target for the new1071 representation.1072 </t>1073 <t>1074 HTTP does not define exactly how a PUT method affects the state1075 of an origin server beyond what can be expressed by the intent of1076 the user agent request and the semantics of the origin server response.1077 It does not define what a resource might be, in any sense of that1078 word, beyond the interface provided via HTTP. It does not define1079 how resource state is "stored", nor how such storage might change1080 as a result of a change in resource state, nor how the origin server1081 translates resource state into representations. Generally speaking,1082 all implementation details behind the resource interface are1083 intentionally hidden by the server.1084 </t>1085 <t>1086 The fundamental difference between the POST and PUT methods is1087 highlighted by the different intent for the target resource.1088 The target resource in a POST request is intended to handle the1089 enclosed representation as a data-accepting process, such as for1090 a gateway to some other protocol or a document that accepts annotations.1091 In contrast, the target resource in a PUT request is intended to1092 take the enclosed representation as a new or replacement value.1093 Hence, the intent of PUT is idempotent and visible to intermediaries,1094 even though the exact effect is only known by the origin server.1095 </t>1096 <t>1097 Proper interpretation of a PUT request presumes that the user agent1098 knows what target resource is desired. A service that is intended1099 to select a proper URI on behalf of the client, after receiving1100 a state-changing request, &SHOULD; be implemented using the POST1101 method rather than PUT. If the origin server will not make the1102 requested PUT state change to the target resource and instead1103 wishes to have it applied to a different resource, such as when the1104 resource has been moved to a different URI, then the origin server1105 &MUST; send a 301 (Moved Permanently) response; the user agent &MAY;1106 then make its own decision regarding whether or not to redirect the1107 request.1108 </t>1109 <t>1110 A PUT request applied to the target resource &MAY; have side-effects1111 on other resources. For example, an article might have a URI for1112 identifying "the current version" (a resource) which is separate1113 from the URIs identifying each particular version (different1114 resources that at one point shared the same state as the current version1115 resource). A successful PUT request on "the current version" URI might1116 therefore create a new version resource in addition to changing the1117 state of the target resource, and might also cause links to be added1118 between the related resources.1119 </t>1120 <t>1121 An origin server &SHOULD; reject any PUT request that contains a1122 Content-Range header field, since it might be misinterpreted as1123 partial content (or might be partial content that is being mistakenly1124 PUT as a full representation). Partial content updates are1125 possible by targeting a separately identified resource with state1126 that overlaps a portion of the larger resource, or by using a1127 different method that has been specifically defined for partial1128 updates (for example, the PATCH method defined in1129 <xref target="RFC5789"/>).1130 </t>1131 <t>1132 Responses to the PUT method are not cacheable. If a PUT request passes1133 through a cache that has one or more stored responses for the effective1134 request URI, those stored responses will be invalidated (see1135 &p6-invalid;).1136 </t>1137 </section>1138 1139 <section title="DELETE" anchor="DELETE">1140 <iref primary="true" item="DELETE method" x:for-anchor=""/>1141 <iref primary="true" item="Methods" subitem="DELETE" x:for-anchor=""/>1142 <t>1143 The DELETE method requests that the origin server delete the target1144 resource. This method &MAY; be overridden by1145 human intervention (or other means) on the origin server. The client cannot1146 be guaranteed that the operation has been carried out, even if the1147 status code returned from the origin server indicates that the action1148 has been completed successfully. However, the server &SHOULD-NOT;1149 indicate success unless, at the time the response is given, it1150 intends to delete the resource or move it to an inaccessible1151 location.1152 </t>1153 <t>1154 A successful response &SHOULD; be 200 (OK) if the response includes an1155 representation describing the status, 202 (Accepted) if the action has not1156 yet been enacted, or 204 (No Content) if the action has been enacted1157 but the response does not include a representation.1158 </t>1159 <t>1160 Bodies on DELETE requests have no defined semantics. Note that sending a body1161 on a DELETE request might cause some existing implementations to reject the1162 request.1163 </t>1164 <t>1165 Responses to the DELETE method are not cacheable. If a DELETE request1166 passes through a cache that has one or more stored responses for the1167 effective request URI, those stored responses will be invalidated (see1168 &p6-invalid;).1169 </t>1170 </section>1171 1172 <section title="TRACE" anchor="TRACE">1173 <rdf:Description>1174 <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe>1175 </rdf:Description>1176 <iref primary="true" item="TRACE method" x:for-anchor=""/>1177 <iref primary="true" item="Methods" subitem="TRACE" x:for-anchor=""/>1178 <t>1179 The TRACE method requests a remote, application-layer loop-back1180 of the request message. The final recipient of the request1181 &SHOULD; reflect the message received back to the client as the1182 message body of a 200 (OK) response. The final recipient is either the1183 origin server or the first proxy to receive a Max-Forwards1184 value of zero (0) in the request (see <xref target="header.max-forwards"/>).1185 A TRACE request &MUST-NOT; include a message body.1186 </t>1187 <t>1188 TRACE allows the client to see what is being received at the other1189 end of the request chain and use that data for testing or diagnostic1190 information. The value of the Via header field (&header-via;) is of1191 particular interest, since it acts as a trace of the request chain.1192 Use of the Max-Forwards header field allows the client to limit the1193 length of the request chain, which is useful for testing a chain of1194 proxies forwarding messages in an infinite loop.1195 </t>1196 <t>1197 If the request is valid, the response &SHOULD; have a Content-Type of1198 "message/http" (see &media-type-message-http;) and contain a message body1199 that encloses a copy of the entire request message.1200 Responses to the TRACE method are not cacheable.1201 </t>1202 </section>1203 1204 <section title="CONNECT" anchor="CONNECT">1205 <iref primary="true" item="CONNECT method" x:for-anchor=""/>1206 <iref primary="true" item="Methods" subitem="CONNECT" x:for-anchor=""/>1207 <t>1208 The CONNECT method requests that the proxy establish a tunnel1209 to the request-target and, if successful, thereafter restrict its behavior1210 to blind forwarding of packets until the connection is closed.1211 </t>1212 <t>1213 When using CONNECT, the request-target &MUST; use the authority form1214 (&request-target;); i.e., the request-target consists of only the1215 host name and port number of the tunnel destination, separated by a colon.1216 For example,1217 </t>1218 <figure><artwork type="message/http; msgtype="request"" x:indent-with=" ">1219 CONNECT server.example.com:80 HTTP/1.11220 Host: server.example.com:801221 1222 </artwork></figure>1223 <t>1224 Any successful (2xx) response to a CONNECT request indicates that the1225 proxy has established a connection to the requested host and port,1226 and has switched to tunneling the current connection to that server1227 connection.1228 The tunneled data from the server begins immediately after the blank line1229 that concludes the successful response's header block.1230 A server &SHOULD-NOT; send any Transfer-Encoding or Content-Length1231 header fields in a successful response.1232 A client &MUST; ignore any Content-Length or Transfer-Encoding header1233 fields received in a successful response.1234 </t>1235 <t>1236 Any response other than a successful response indicates that the tunnel1237 has not yet been formed and that the connection remains governed by HTTP.1238 </t>1239 <t>1240 Proxy authentication might be used to establish the1241 authority to create a tunnel:1242 </t>1243 <figure><artwork type="message/http; msgtype="request"" x:indent-with=" ">1244 CONNECT server.example.com:80 HTTP/1.11245 Host: server.example.com:801246 Proxy-Authorization: basic aGVsbG86d29ybGQ=1247 1248 </artwork></figure>1249 <t>1250 A message body on a CONNECT request has no defined semantics. Sending a1251 body on a CONNECT request might cause existing implementations to reject1252 the request.1253 </t>1254 <t>1255 Similar to a pipelined HTTP/1.1 request, data to be tunneled from client1256 to server &MAY; be sent immediately after the request (before a response1257 is received). The usual caveats also apply:1258 data may be discarded if the eventual response is negative, and the1259 connection may be reset with no response if more than one TCP segment1260 is outstanding.1261 </t>1262 <t>1263 It may be the case that the proxy itself can only reach the requested1264 origin server through another proxy. In this case, the first proxy1265 &SHOULD; make a CONNECT request of that next proxy, requesting a tunnel1266 to the authority. A proxy &MUST-NOT; respond with any 2xx status code1267 unless it has either a direct or tunnel connection established to the1268 authority.1269 </t>1270 <t>1271 If at any point either one of the peers gets disconnected, any1272 outstanding data that came from that peer will be passed to the other1273 one, and after that also the other connection will be terminated by1274 the proxy. If there is outstanding data to that peer undelivered,1275 that data will be discarded.1276 </t>1277 <t>1278 An origin server which receives a CONNECT request for itself &MAY;1279 respond with a 2xx status code to indicate that a connection is1280 established. However, most origin servers do not implement CONNECT.1281 </t>1282 </section>1283 </section>1284 1285 1286 741 <section title="Status Code Definitions" anchor="status.codes"> 1287 <t>1288 The first digit of the status-code defines the class of response. The1289 last two digits do not have any categorization role. There are 51290 values for the first digit:1291 <list style="symbols">1292 <t>1293 1xx: Informational - Request received, continuing process1294 </t>1295 <t>1296 2xx: Success - The action was successfully received,1297 understood, and accepted1298 </t>1299 <t>1300 3xx: Redirection - Further action needs to be taken in order to1301 complete the request1302 </t>1303 <t>1304 4xx: Client Error - The request contains bad syntax or cannot1305 be fulfilled1306 </t>1307 <t>1308 5xx: Server Error - The server failed to fulfill an apparently1309 valid request1310 </t>1311 </list>1312 </t>1313 742 <t> 1314 743 Each status-code is described below, including any metadata required … … 2147 1576 </section> 2148 1577 1578 </section> 1579 1580 <section title="Representation" anchor="representation"> 1581 <t> 1582 Request and Response messages &MAY; transfer a representation if not otherwise 1583 restricted by the request method or response status code. A representation 1584 consists of metadata (representation header fields) and data (representation 1585 body). When a complete or partial representation is enclosed in an HTTP message, 1586 it is referred to as the payload of the message. HTTP representations 1587 are defined in &payload;. 1588 </t> 1589 <t> 1590 A representation body is only present in a message when a message body is 1591 present, as described in &message-body;. The representation body is obtained 1592 from the message body by decoding any Transfer-Encoding that might 1593 have been applied to ensure safe and proper transfer of the message. 1594 </t> 1595 1596 <section title="Identifying the Resource Associated with a Representation" anchor="identifying.response.associated.with.representation"> 1597 <t> 1598 It is sometimes necessary to determine an identifier for the resource 1599 associated with a representation. 1600 </t> 1601 <t> 1602 An HTTP request representation, when present, is always associated with an 1603 anonymous (i.e., unidentified) resource. 1604 </t> 1605 <t> 1606 In the common case, an HTTP response is a representation of the target 1607 resource (see &effective-request-uri;). However, this is not always the 1608 case. To determine the URI of the resource a response is associated with, 1609 the following rules are used (with the first applicable one being selected): 1610 </t> 1611 <t><list style="numbers"> 1612 <t>If the response status code is 200 or 203 and the request method was GET, 1613 the response payload is a representation of the target resource.</t> 1614 <t>If the response status code is 204, 206, or 304 and the request method was GET 1615 or HEAD, the response payload is a partial representation of the target 1616 resource.</t> 1617 <t>If the response has a Content-Location header field, and that URI is the same 1618 as the effective request URI, the response payload is a representation of the 1619 target resource.</t> 1620 <t>If the response has a Content-Location header field, and that URI is not the 1621 same as the effective request URI, then the response asserts that its 1622 payload is a representation of the resource identified by the 1623 Content-Location URI. However, such an assertion cannot be trusted unless 1624 it can be verified by other means (not defined by HTTP).</t> 1625 <t>Otherwise, the response is a representation of an anonymous (i.e., 1626 unidentified) resource.</t> 1627 </list></t> 1628 <t> 1629 <cref anchor="TODO-req-uri"> 1630 The comparison function is going to have to be defined somewhere, 1631 because we already need to compare URIs for things like cache invalidation.</cref> 1632 </t> 1633 </section> 1634 1635 </section> 1636 1637 1638 <section title="Method Definitions" anchor="method.definitions"> 1639 <t> 1640 The set of common request methods for HTTP/1.1 is defined below. Although 1641 this set can be expanded, additional methods cannot be assumed to 1642 share the same semantics for separately extended clients and servers. 1643 </t> 1644 1645 <section title="Safe and Idempotent Methods" anchor="safe.and.idempotent"> 1646 1647 <section title="Safe Methods" anchor="safe.methods"> 1648 <iref item="Safe Methods" primary="true"/> 1649 <t> 1650 Implementors need to be aware that the software represents the user in 1651 their interactions over the Internet, and need to allow 1652 the user to be aware of any actions they take which might have an 1653 unexpected significance to themselves or others. 1654 </t> 1655 <t> 1656 In particular, the convention has been established that the GET, HEAD, 1657 OPTIONS, and TRACE request methods &SHOULD-NOT; have the significance 1658 of taking an action other than retrieval. These request methods ought 1659 to be considered "<x:dfn anchor="safe">safe</x:dfn>". 1660 This allows user agents to represent other methods, such as POST, PUT 1661 and DELETE, in a special way, so that the user is made aware of the 1662 fact that a possibly unsafe action is being requested. 1663 </t> 1664 <t> 1665 Naturally, it is not possible to ensure that the server does not 1666 generate side-effects as a result of performing a GET request; in 1667 fact, some dynamic resources consider that a feature. The important 1668 distinction here is that the user did not request the side-effects, 1669 so therefore cannot be held accountable for them. 1670 </t> 1671 </section> 1672 1673 <section title="Idempotent Methods" anchor="idempotent.methods"> 1674 <iref item="Idempotent Methods" primary="true"/> 1675 <t> 1676 Request methods can also have the property of "idempotence" in that, 1677 aside from error or expiration issues, the intended effect of multiple 1678 identical requests is the same as for a single request. 1679 PUT, DELETE, and all safe request methods are idempotent. 1680 It is important to note that idempotence refers only to changes 1681 requested by the client: a server is free to change its state due 1682 to multiple requests for the purpose of tracking those requests, 1683 versioning of results, etc. 1684 </t> 1685 </section> 1686 </section> 1687 1688 <section title="OPTIONS" anchor="OPTIONS"> 1689 <rdf:Description> 1690 <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe> 1691 </rdf:Description> 1692 <iref primary="true" item="OPTIONS method" x:for-anchor=""/> 1693 <iref primary="true" item="Methods" subitem="OPTIONS" x:for-anchor=""/> 1694 <t> 1695 The OPTIONS method requests information about the 1696 communication options available on the request/response chain 1697 identified by the effective request URI. This method allows a client to 1698 determine the options and/or requirements associated with a resource, 1699 or the capabilities of a server, without implying a resource action 1700 or initiating a resource retrieval. 1701 </t> 1702 <t> 1703 Responses to the OPTIONS method are not cacheable. 1704 </t> 1705 <t> 1706 If the OPTIONS request includes a message body (as indicated by the 1707 presence of Content-Length or Transfer-Encoding), then the media type 1708 &MUST; be indicated by a Content-Type field. Although this 1709 specification does not define any use for such a body, future 1710 extensions to HTTP might use the OPTIONS body to make more detailed 1711 queries on the server. 1712 </t> 1713 <t> 1714 If the request-target (&request-target;) is an asterisk ("*"), 1715 the OPTIONS request is 1716 intended to apply to the server in general rather than to a specific 1717 resource. Since a server's communication options typically depend on 1718 the resource, the "*" request is only useful as a "ping" or "no-op" 1719 type of method; it does nothing beyond allowing the client to test 1720 the capabilities of the server. For example, this can be used to test 1721 a proxy for HTTP/1.1 conformance (or lack thereof). 1722 </t> 1723 <t> 1724 If the request-target is not an asterisk, the OPTIONS request applies 1725 only to the options that are available when communicating with that 1726 resource. 1727 </t> 1728 <t> 1729 A 200 response &SHOULD; include any header fields that indicate 1730 optional features implemented by the server and applicable to that 1731 resource (e.g., Allow), possibly including extensions not defined by 1732 this specification. The response body, if any, &SHOULD; also include 1733 information about the communication options. The format for such a 1734 body is not defined by this specification, but might be defined by 1735 future extensions to HTTP. Content negotiation &MAY; be used to select 1736 the appropriate response format. If no response body is included, the 1737 response &MUST; include a Content-Length field with a field-value of 1738 "0". 1739 </t> 1740 <t> 1741 The Max-Forwards header field &MAY; be used to target a 1742 specific proxy in the request chain (see <xref target="header.max-forwards"/>). 1743 If no Max-Forwards field is present in the request, then the forwarded 1744 request &MUST-NOT; include a Max-Forwards field. 1745 </t> 1746 </section> 1747 1748 <section title="GET" anchor="GET"> 1749 <rdf:Description> 1750 <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe> 1751 </rdf:Description> 1752 <iref primary="true" item="GET method" x:for-anchor=""/> 1753 <iref primary="true" item="Methods" subitem="GET" x:for-anchor=""/> 1754 <t> 1755 The GET method requests transfer of a current representation of 1756 the target resource. 1757 </t> 1758 <t> 1759 If the target resource is a data-producing process, it is the 1760 produced data which shall be returned as the representation in the response and not 1761 the source text of the process, unless that text happens to be the output of 1762 the process. 1763 </t> 1764 <t> 1765 The semantics of the GET method change to a "conditional GET" if the 1766 request message includes an If-Modified-Since, If-Unmodified-Since, 1767 If-Match, If-None-Match, or If-Range header field. A conditional GET 1768 requests that the representation be transferred only under the 1769 circumstances described by the conditional header field(s). The 1770 conditional GET request is intended to reduce unnecessary network 1771 usage by allowing cached representations to be refreshed without requiring 1772 multiple requests or transferring data already held by the client. 1773 </t> 1774 <t> 1775 The semantics of the GET method change to a "partial GET" if the 1776 request message includes a Range header field. A partial GET requests 1777 that only part of the representation be transferred, as described in &header-range;. 1778 The partial GET request is intended to reduce unnecessary 1779 network usage by allowing partially-retrieved representations to be 1780 completed without transferring data already held by the client. 1781 </t> 1782 <t> 1783 Bodies on GET requests have no defined semantics. Note that sending a body 1784 on a GET request might cause some existing implementations to reject the 1785 request. 1786 </t> 1787 <t> 1788 The response to a GET request is cacheable and &MAY; be used to satisfy 1789 subsequent GET and HEAD requests (see &caching;). 1790 </t> 1791 <t> 1792 See <xref target="encoding.sensitive.information.in.uris"/> for security considerations when used for forms. 1793 </t> 1794 </section> 1795 1796 <section title="HEAD" anchor="HEAD"> 1797 <rdf:Description> 1798 <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe> 1799 </rdf:Description> 1800 <iref primary="true" item="HEAD method" x:for-anchor=""/> 1801 <iref primary="true" item="Methods" subitem="HEAD" x:for-anchor=""/> 1802 <t> 1803 The HEAD method is identical to GET except that the server &MUST-NOT; 1804 return a message body in the response. The metadata contained 1805 in the HTTP header fields in response to a HEAD request &SHOULD; be identical 1806 to the information sent in response to a GET request. This method can 1807 be used for obtaining metadata about the representation implied by the 1808 request without transferring the representation body. This method is 1809 often used for testing hypertext links for validity, accessibility, 1810 and recent modification. 1811 </t> 1812 <t> 1813 The response to a HEAD request is cacheable and &MAY; be used to satisfy 1814 a subsequent HEAD request. It also has potential side effects on 1815 previously stored responses to GET; see &p6-head;. 1816 </t> 1817 <t> 1818 Bodies on HEAD requests have no defined semantics. Note that sending a body 1819 on a HEAD request might cause some existing implementations to reject the 1820 request. 1821 </t> 1822 </section> 1823 1824 <section title="POST" anchor="POST"> 1825 <iref primary="true" item="POST method" x:for-anchor=""/> 1826 <iref primary="true" item="Methods" subitem="POST" x:for-anchor=""/> 1827 <t> 1828 The POST method requests that the origin server accept the 1829 representation enclosed in the request as data to be processed by the 1830 target resource. POST is designed to allow a uniform method to cover the 1831 following functions: 1832 <list style="symbols"> 1833 <t> 1834 Annotation of existing resources; 1835 </t> 1836 <t> 1837 Posting a message to a bulletin board, newsgroup, mailing list, 1838 or similar group of articles; 1839 </t> 1840 <t> 1841 Providing a block of data, such as the result of submitting a 1842 form, to a data-handling process; 1843 </t> 1844 <t> 1845 Extending a database through an append operation. 1846 </t> 1847 </list> 1848 </t> 1849 <t> 1850 The actual function performed by the POST method is determined by the 1851 server and is usually dependent on the effective request URI. 1852 </t> 1853 <t> 1854 The action performed by the POST method might not result in a 1855 resource that can be identified by a URI. In this case, either 200 1856 (OK) or 204 (No Content) is the appropriate response status code, 1857 depending on whether or not the response includes a representation that 1858 describes the result. 1859 </t> 1860 <t> 1861 If a resource has been created on the origin server, the response 1862 &SHOULD; be 201 (Created) and contain a representation which describes the 1863 status of the request and refers to the new resource, and a Location 1864 header field (see <xref target="header.location"/>). 1865 </t> 1866 <t> 1867 Responses to POST requests are only cacheable when they 1868 include explicit freshness information (see &p6-explicit;). A 1869 cached POST response with a Content-Location header field 1870 (see &header-content-location;) whose value is the effective 1871 Request URI &MAY; be used to satisfy subsequent GET and HEAD requests. 1872 </t> 1873 <t> 1874 Note that POST caching is not widely implemented. 1875 However, the 303 (See Other) response can be used to direct the 1876 user agent to retrieve a cacheable representation of the resource. 1877 </t> 1878 </section> 1879 1880 <section title="PUT" anchor="PUT"> 1881 <iref primary="true" item="PUT method" x:for-anchor=""/> 1882 <iref primary="true" item="Methods" subitem="PUT" x:for-anchor=""/> 1883 <t> 1884 The PUT method requests that the state of the target resource 1885 be created or replaced with the state defined by the representation 1886 enclosed in the request message payload. A successful PUT of a given 1887 representation would suggest that a subsequent GET on that same target 1888 resource will result in an equivalent representation being returned in 1889 a 200 (OK) response. However, there is no guarantee that such a state 1890 change will be observable, since the target resource might be acted 1891 upon by other user agents in parallel, or might be subject to dynamic 1892 processing by the origin server, before any subsequent GET is received. 1893 A successful response only implies that the user agent's intent was 1894 achieved at the time of its processing by the origin server. 1895 </t> 1896 <t> 1897 If the target resource does not have a current representation and 1898 the PUT successfully creates one, then the origin server &MUST; inform 1899 the user agent by sending a 201 (Created) response. If the target 1900 resource does have a current representation and that representation is 1901 successfully modified in accordance with the state of the enclosed 1902 representation, then either a 200 (OK) or 204 (No Content) response 1903 &SHOULD; be sent to indicate successful completion of the request. 1904 </t> 1905 <t> 1906 Unrecognized header fields &SHOULD; be ignored (i.e., not saved 1907 as part of the resource state). 1908 </t> 1909 <t> 1910 An origin server &SHOULD; verify that the PUT representation is 1911 consistent with any constraints which the server has for the target 1912 resource that cannot or will not be changed by the PUT. This is 1913 particularly important when the origin server uses internal 1914 configuration information related to the URI in order to set the 1915 values for representation metadata on GET responses. When a PUT 1916 representation is inconsistent with the target resource, the origin 1917 server &SHOULD; either make them consistent, by transforming the 1918 representation or changing the resource configuration, or respond 1919 with an appropriate error message containing sufficient information 1920 to explain why the representation is unsuitable. The 409 (Conflict) 1921 or 415 (Unsupported Media Type) status codes are suggested, with the 1922 latter being specific to constraints on Content-Type values. 1923 </t> 1924 <t> 1925 For example, if the target resource is configured to always have a 1926 Content-Type of "text/html" and the representation being PUT has a 1927 Content-Type of "image/jpeg", then the origin server &SHOULD; do one of: 1928 (a) reconfigure the target resource to reflect the new media type; 1929 (b) transform the PUT representation to a format consistent with that 1930 of the resource before saving it as the new resource state; or, 1931 (c) reject the request with a 415 response indicating that the target 1932 resource is limited to "text/html", perhaps including a link to a 1933 different resource that would be a suitable target for the new 1934 representation. 1935 </t> 1936 <t> 1937 HTTP does not define exactly how a PUT method affects the state 1938 of an origin server beyond what can be expressed by the intent of 1939 the user agent request and the semantics of the origin server response. 1940 It does not define what a resource might be, in any sense of that 1941 word, beyond the interface provided via HTTP. It does not define 1942 how resource state is "stored", nor how such storage might change 1943 as a result of a change in resource state, nor how the origin server 1944 translates resource state into representations. Generally speaking, 1945 all implementation details behind the resource interface are 1946 intentionally hidden by the server. 1947 </t> 1948 <t> 1949 The fundamental difference between the POST and PUT methods is 1950 highlighted by the different intent for the target resource. 1951 The target resource in a POST request is intended to handle the 1952 enclosed representation as a data-accepting process, such as for 1953 a gateway to some other protocol or a document that accepts annotations. 1954 In contrast, the target resource in a PUT request is intended to 1955 take the enclosed representation as a new or replacement value. 1956 Hence, the intent of PUT is idempotent and visible to intermediaries, 1957 even though the exact effect is only known by the origin server. 1958 </t> 1959 <t> 1960 Proper interpretation of a PUT request presumes that the user agent 1961 knows what target resource is desired. A service that is intended 1962 to select a proper URI on behalf of the client, after receiving 1963 a state-changing request, &SHOULD; be implemented using the POST 1964 method rather than PUT. If the origin server will not make the 1965 requested PUT state change to the target resource and instead 1966 wishes to have it applied to a different resource, such as when the 1967 resource has been moved to a different URI, then the origin server 1968 &MUST; send a 301 (Moved Permanently) response; the user agent &MAY; 1969 then make its own decision regarding whether or not to redirect the 1970 request. 1971 </t> 1972 <t> 1973 A PUT request applied to the target resource &MAY; have side-effects 1974 on other resources. For example, an article might have a URI for 1975 identifying "the current version" (a resource) which is separate 1976 from the URIs identifying each particular version (different 1977 resources that at one point shared the same state as the current version 1978 resource). A successful PUT request on "the current version" URI might 1979 therefore create a new version resource in addition to changing the 1980 state of the target resource, and might also cause links to be added 1981 between the related resources. 1982 </t> 1983 <t> 1984 An origin server &SHOULD; reject any PUT request that contains a 1985 Content-Range header field, since it might be misinterpreted as 1986 partial content (or might be partial content that is being mistakenly 1987 PUT as a full representation). Partial content updates are 1988 possible by targeting a separately identified resource with state 1989 that overlaps a portion of the larger resource, or by using a 1990 different method that has been specifically defined for partial 1991 updates (for example, the PATCH method defined in 1992 <xref target="RFC5789"/>). 1993 </t> 1994 <t> 1995 Responses to the PUT method are not cacheable. If a PUT request passes 1996 through a cache that has one or more stored responses for the effective 1997 request URI, those stored responses will be invalidated (see 1998 &p6-invalid;). 1999 </t> 2000 </section> 2001 2002 <section title="DELETE" anchor="DELETE"> 2003 <iref primary="true" item="DELETE method" x:for-anchor=""/> 2004 <iref primary="true" item="Methods" subitem="DELETE" x:for-anchor=""/> 2005 <t> 2006 The DELETE method requests that the origin server delete the target 2007 resource. This method &MAY; be overridden by 2008 human intervention (or other means) on the origin server. The client cannot 2009 be guaranteed that the operation has been carried out, even if the 2010 status code returned from the origin server indicates that the action 2011 has been completed successfully. However, the server &SHOULD-NOT; 2012 indicate success unless, at the time the response is given, it 2013 intends to delete the resource or move it to an inaccessible 2014 location. 2015 </t> 2016 <t> 2017 A successful response &SHOULD; be 200 (OK) if the response includes an 2018 representation describing the status, 202 (Accepted) if the action has not 2019 yet been enacted, or 204 (No Content) if the action has been enacted 2020 but the response does not include a representation. 2021 </t> 2022 <t> 2023 Bodies on DELETE requests have no defined semantics. Note that sending a body 2024 on a DELETE request might cause some existing implementations to reject the 2025 request. 2026 </t> 2027 <t> 2028 Responses to the DELETE method are not cacheable. If a DELETE request 2029 passes through a cache that has one or more stored responses for the 2030 effective request URI, those stored responses will be invalidated (see 2031 &p6-invalid;). 2032 </t> 2033 </section> 2034 2035 <section title="TRACE" anchor="TRACE"> 2036 <rdf:Description> 2037 <safe xmlns="urn:ietf:id:draft-ietf-httpbis-p2-semantics#">yes</safe> 2038 </rdf:Description> 2039 <iref primary="true" item="TRACE method" x:for-anchor=""/> 2040 <iref primary="true" item="Methods" subitem="TRACE" x:for-anchor=""/> 2041 <t> 2042 The TRACE method requests a remote, application-layer loop-back 2043 of the request message. The final recipient of the request 2044 &SHOULD; reflect the message received back to the client as the 2045 message body of a 200 (OK) response. The final recipient is either the 2046 origin server or the first proxy to receive a Max-Forwards 2047 value of zero (0) in the request (see <xref target="header.max-forwards"/>). 2048 A TRACE request &MUST-NOT; include a message body. 2049 </t> 2050 <t> 2051 TRACE allows the client to see what is being received at the other 2052 end of the request chain and use that data for testing or diagnostic 2053 information. The value of the Via header field (&header-via;) is of 2054 particular interest, since it acts as a trace of the request chain. 2055 Use of the Max-Forwards header field allows the client to limit the 2056 length of the request chain, which is useful for testing a chain of 2057 proxies forwarding messages in an infinite loop. 2058 </t> 2059 <t> 2060 If the request is valid, the response &SHOULD; have a Content-Type of 2061 "message/http" (see &media-type-message-http;) and contain a message body 2062 that encloses a copy of the entire request message. 2063 Responses to the TRACE method are not cacheable. 2064 </t> 2065 </section> 2066 2067 <section title="CONNECT" anchor="CONNECT"> 2068 <iref primary="true" item="CONNECT method" x:for-anchor=""/> 2069 <iref primary="true" item="Methods" subitem="CONNECT" x:for-anchor=""/> 2070 <t> 2071 The CONNECT method requests that the proxy establish a tunnel 2072 to the request-target and, if successful, thereafter restrict its behavior 2073 to blind forwarding of packets until the connection is closed. 2074 </t> 2075 <t> 2076 When using CONNECT, the request-target &MUST; use the authority form 2077 (&request-target;); i.e., the request-target consists of only the 2078 host name and port number of the tunnel destination, separated by a colon. 2079 For example, 2080 </t> 2081 <figure><artwork type="message/http; msgtype="request"" x:indent-with=" "> 2082 CONNECT server.example.com:80 HTTP/1.1 2083 Host: server.example.com:80 2084 2085 </artwork></figure> 2086 <t> 2087 Any successful (2xx) response to a CONNECT request indicates that the 2088 proxy has established a connection to the requested host and port, 2089 and has switched to tunneling the current connection to that server 2090 connection. 2091 The tunneled data from the server begins immediately after the blank line 2092 that concludes the successful response's header block. 2093 A server &SHOULD-NOT; send any Transfer-Encoding or Content-Length 2094 header fields in a successful response. 2095 A client &MUST; ignore any Content-Length or Transfer-Encoding header 2096 fields received in a successful response. 2097 </t> 2098 <t> 2099 Any response other than a successful response indicates that the tunnel 2100 has not yet been formed and that the connection remains governed by HTTP. 2101 </t> 2102 <t> 2103 Proxy authentication might be used to establish the 2104 authority to create a tunnel: 2105 </t> 2106 <figure><artwork type="message/http; msgtype="request"" x:indent-with=" "> 2107 CONNECT server.example.com:80 HTTP/1.1 2108 Host: server.example.com:80 2109 Proxy-Authorization: basic aGVsbG86d29ybGQ= 2110 2111 </artwork></figure> 2112 <t> 2113 A message body on a CONNECT request has no defined semantics. Sending a 2114 body on a CONNECT request might cause existing implementations to reject 2115 the request. 2116 </t> 2117 <t> 2118 Similar to a pipelined HTTP/1.1 request, data to be tunneled from client 2119 to server &MAY; be sent immediately after the request (before a response 2120 is received). The usual caveats also apply: 2121 data may be discarded if the eventual response is negative, and the 2122 connection may be reset with no response if more than one TCP segment 2123 is outstanding. 2124 </t> 2125 <t> 2126 It may be the case that the proxy itself can only reach the requested 2127 origin server through another proxy. In this case, the first proxy 2128 &SHOULD; make a CONNECT request of that next proxy, requesting a tunnel 2129 to the authority. A proxy &MUST-NOT; respond with any 2xx status code 2130 unless it has either a direct or tunnel connection established to the 2131 authority. 2132 </t> 2133 <t> 2134 If at any point either one of the peers gets disconnected, any 2135 outstanding data that came from that peer will be passed to the other 2136 one, and after that also the other connection will be terminated by 2137 the proxy. If there is outstanding data to that peer undelivered, 2138 that data will be discarded. 2139 </t> 2140 <t> 2141 An origin server which receives a CONNECT request for itself &MAY; 2142 respond with a 2xx status code to indicate that a connection is 2143 established. However, most origin servers do not implement CONNECT. 2144 </t> 2145 </section> 2146 </section> 2147 2149 2148 <section title="Common Protocol Parameters" anchor="common.protocol.parameters"> 2150 2149 <section title="Date/Time Formats" anchor="http.date"> … … 3685 3684 </t> 3686 3685 <t> 3687 Clarify definition of POST.3688 (<xref target="POST"/>)3689 </t>3690 <t>3691 Remove requirement to handle all Content-* header fields; ban use of3692 Content-Range with PUT.3693 (<xref target="PUT"/>)3694 </t>3695 <t>3696 Take over definition of CONNECT method from <xref target="RFC2817"/>.3697 (<xref target="CONNECT"/>)3698 </t>3699 <t>3700 3686 Broadened the definition of 203 (Non-Authoritative Information) to include 3701 3687 cases of payload transformations as well. … … 3728 3714 <xref target="RFC2817"/>). 3729 3715 (<xref target="status.426"/>) 3716 </t> 3717 <t> 3718 Clarify definition of POST. 3719 (<xref target="POST"/>) 3720 </t> 3721 <t> 3722 Remove requirement to handle all Content-* header fields; ban use of 3723 Content-Range with PUT. 3724 (<xref target="PUT"/>) 3725 </t> 3726 <t> 3727 Take over definition of CONNECT method from <xref target="RFC2817"/>. 3728 (<xref target="CONNECT"/>) 3730 3729 </t> 3731 3730 <t>
Note: See TracChangeset
for help on using the changeset viewer.