Changeset 1579 for draft-ietf-httpbis
- Timestamp:
- 11/03/12 05:42:53 (9 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r1576 r1579 1119 1119 <x:ref>request-line</x:ref> = <x:ref>method</x:ref> <x:ref>SP</x:ref> <x:ref>request-target</x:ref> <x:ref>SP</x:ref> <x:ref>HTTP-version</x:ref> <x:ref>CRLF</x:ref> 1120 1120 </artwork></figure> 1121 1122 <section title="Method" anchor="method"> 1123 <x:anchor-alias value="method"/> 1124 <t> 1121 <iref primary="true" item="method"/> 1122 <t anchor="method"> 1125 1123 The method token indicates the request method to be performed on the 1126 1124 target resource. The request method is case-sensitive. … … 1134 1132 and considerations for defining new methods. 1135 1133 </t> 1136 </section> 1137 1138 <section title="Request Target" anchor="request-target"> 1139 <x:anchor-alias value="request-target"/> 1134 <iref item="request-target"/> 1140 1135 <t> 1141 1136 The request-target identifies the target resource upon which to apply 1142 the request. The four options for request-target are described in 1143 <xref target="request-target-types"/>. 1144 </t> 1145 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="request-target"/> 1146 <x:ref>request-target</x:ref> = "*" 1147 / <x:ref>absolute-URI</x:ref> 1148 / ( <x:ref>path-absolute</x:ref> [ "?" <x:ref>query</x:ref> ] ) 1149 / <x:ref>authority</x:ref> 1150 </artwork></figure> 1151 <t> 1152 HTTP does not place a pre-defined limit on the length of a request-target. 1137 the request, as defined in <xref target="request-target"/>. 1138 </t> 1139 <t> 1140 No whitespace is allowed inside the method, request-target, and 1141 protocol version. Hence, recipients typically parse the request-line 1142 into its component parts by splitting on the SP characters. 1143 </t> 1144 <t> 1145 Unfortunately, some user agents fail to properly encode hypertext 1146 references that have embedded whitespace, sending the characters 1147 directly instead of properly percent-encoding the disallowed characters. 1148 Recipients of an invalid request-line &SHOULD; respond with either a 1149 400 (Bad Request) error or a 301 (Moved Permanently) redirect with the 1150 request-target properly encoded. Recipients &SHOULD-NOT; attempt to 1151 autocorrect and then process the request without a redirect, since the 1152 invalid request-line might be deliberately crafted to bypass 1153 security filters along the request chain. 1154 </t> 1155 <t> 1156 HTTP does not place a pre-defined limit on the length of a request-line. 1157 A server that receives a method longer than any that it implements 1158 &SHOULD; respond with either a 404 (Not Allowed), if it is an origin 1159 server, or a 501 (Not Implemented) status code. 1153 1160 A server &MUST; be prepared to receive URIs of unbounded length and 1154 1161 respond with the 414 (URI Too Long) status code if the received … … 1157 1164 </t> 1158 1165 <t> 1159 Various ad-hoc limitations on request-target length are found in practice. 1160 It is &RECOMMENDED; that all HTTP senders and recipients support 1161 request-target lengths of 8000 or more octets. 1162 </t> 1163 <x:note> 1164 <t> 1165 <x:h>Note:</x:h> Fragments (<xref target="RFC3986" x:fmt="," x:sec="3.5"/>) 1166 are not part of the request-target and thus will not be transmitted 1167 in an HTTP request. 1168 </t> 1169 </x:note> 1170 </section> 1171 </section> 1172 1173 <section title="Response Status Line" anchor="status.line"> 1166 Various ad-hoc limitations on request-line length are found in practice. 1167 It is &RECOMMENDED; that all HTTP senders and recipients support, at a 1168 minimum, request-line lengths of up to 8000 octets. 1169 </t> 1170 </section> 1171 1172 <section title="Status Line" anchor="status.line"> 1174 1173 <x:anchor-alias value="response"/> 1175 1174 <x:anchor-alias value="status-line"/> … … 1184 1183 </artwork></figure> 1185 1184 1186 <section title="Status Code" anchor="status.code"> 1187 <x:anchor-alias value="status-code"/> 1188 <t> 1185 <t anchor="status-code"> 1189 1186 The status-code element is a 3-digit integer result code of the attempt to 1190 1187 understand and satisfy the request. See &status-code-reasonphr; for … … 1195 1192 <x:ref>status-code</x:ref> = 3<x:ref>DIGIT</x:ref> 1196 1193 </artwork></figure> 1197 </section> 1198 1199 <section title="Reason Phrase" anchor="reason.phrase"> 1200 <x:anchor-alias value="reason-phrase"/> 1201 <t> 1194 1195 <t anchor="reason-phrase"> 1202 1196 The reason-phrase element exists for the sole purpose of providing a 1203 1197 textual description associated with the numeric status code, mostly … … 1209 1203 <x:ref>reason-phrase</x:ref> = *( <x:ref>HTAB</x:ref> / <x:ref>SP</x:ref> / <x:ref>VCHAR</x:ref> / <x:ref>obs-text</x:ref> ) 1210 1204 </artwork></figure> 1211 </section>1212 1205 </section> 1213 1206 </section> … … 1571 1564 The presence of a message body in a response depends on both 1572 1565 the request method to which it is responding and the response 1573 status code (<xref target="status .code"/>).1566 status code (<xref target="status-code"/>). 1574 1567 Responses to the HEAD request method never include a message body 1575 1568 because the associated response header fields (e.g., Transfer-Encoding, … … 2302 2295 2303 2296 <section title="Identifying a Target Resource" anchor="target-resource"> 2297 <iref primary="true" item="target resource"/> 2298 <iref primary="true" item="target URI"/> 2304 2299 <t> 2305 2300 HTTP is used in a wide variety of applications, ranging from … … 2317 2312 its absolute form in order to obtain the target URI. The target URI 2318 2313 excludes the reference's fragment identifier component, if any, 2319 since fragment identifiers are for client-side processing only. 2314 since fragment identifiers are reserved for client-side processing 2315 (<xref target="RFC3986" x:fmt="," x:sec="3.5"/>). 2320 2316 </t> 2321 2317 <t> … … 2356 2352 </section> 2357 2353 2358 <section title=" Types of Request Target" anchor="request-target-types">2359 <t> 2360 Once an inbound connection is obtained , the client sends an HTTP request2361 message (<xref target="http.message"/>) with a request-target derived from2362 the target URI. There are four distinct formats for the request-target2363 (<xref target="request-target"/>), depending on both the method being2364 requested and whether the request is to a proxy.2354 <section title="Request Target" anchor="request-target"> 2355 <t> 2356 Once an inbound connection is obtained (<xref target="connections"/>), 2357 the client sends an HTTP request message (<xref target="http.message"/>) 2358 with a request-target derived from the target URI. 2359 There are four distinct formats for the request-target, depending on both 2360 the method being requested and whether the request is to a proxy. 2365 2361 </t> 2362 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="request-target"/> 2363 <x:ref>request-target</x:ref> = "*" 2364 / <x:ref>absolute-URI</x:ref> 2365 / ( <x:ref>path-absolute</x:ref> [ "?" <x:ref>query</x:ref> ] ) 2366 / <x:ref>authority</x:ref> 2367 </artwork></figure> 2366 2368 <t anchor="origin-form"><iref item="origin form (of request-target)"/> 2367 2369 The most common form of request-target is that used when making … … 2578 2580 <section title="Effective Request URI" anchor="effective.request.uri"> 2579 2581 <iref primary="true" item="effective request URI"/> 2580 <iref primary="true" item="target resource"/>2581 2582 <t> 2582 2583 HTTP requests often do not carry the absolute URI (<xref target="RFC3986" x:fmt="," x:sec="4.3"/>) … … 3931 3932 <t> 3932 3933 To promote interoperability, this specification makes specific 3933 recommendations for size limits on request-targets (<xref target="request-target"/>) 3934 recommendations for minimum size limits on request-line 3935 (<xref target="request.line"/>) 3934 3936 and blocks of header fields (<xref target="header.fields"/>). These are 3935 3937 minimum recommendations, chosen to be supportable even by implementations 3936 with limited resources; it is expected that most implementations will choose3937 substantially higher limits.3938 with limited resources; it is expected that most implementations will 3939 choose substantially higher limits. 3938 3940 </t> 3939 3941 <t> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1577 r1579 938 938 </t> 939 939 <t> 940 If the request-target is an asterisk ("*"), the OPTIONS request is 940 If the request-target (&request-target;) is an asterisk ("*"), 941 the OPTIONS request is 941 942 intended to apply to the server in general rather than to a specific 942 943 resource. Since a server's communication options typically depend on
Note: See TracChangeset
for help on using the changeset viewer.