11/03/12 05:42:53 (10 years ago)

Consolidate request-target under message routing. Simplify the
sections on Request Line and Status Line, since what they contain
is defined elsewhere.

Change request-target size limit to request-line size limit, since
that is how it is implemented in practice.

Add SHOULDs for error handling when the method is too long or
embedded whitespace is sent in the request-target.

1 edited


  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1576 r1579  
    11191119  <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>
    1122 <section title="Method" anchor="method">
    1123   <x:anchor-alias value="method"/>
    1124 <t>
     1121<iref primary="true" item="method"/>
     1122<t anchor="method">
    11251123   The method token indicates the request method to be performed on the
    11261124   target resource. The request method is case-sensitive.
    11341132   and considerations for defining new methods.
    1136 </section>
    1138 <section title="Request Target" anchor="request-target">
    1139   <x:anchor-alias value="request-target"/>
     1134<iref item="request-target"/>
    11411136   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"/>.
     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.
     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.
     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.
    11531160   A server &MUST; be prepared to receive URIs of unbounded length and
    11541161   respond with the 414 (URI Too Long) status code if the received
    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>
    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.
     1172<section title="Status Line" anchor="status.line">
    11741173  <x:anchor-alias value="response"/>
    11751174  <x:anchor-alias value="status-line"/>
    1186 <section title="Status Code" anchor="status.code">
    1187   <x:anchor-alias value="status-code"/>
    1188 <t>
     1185<t anchor="status-code">
    11891186   The status-code element is a 3-digit integer result code of the attempt to
    11901187   understand and satisfy the request. See &status-code-reasonphr; for
    11951192  <x:ref>status-code</x:ref>    = 3<x:ref>DIGIT</x:ref>
    1197 </section>
    1199 <section title="Reason Phrase" anchor="reason.phrase">
    1200   <x:anchor-alias value="reason-phrase"/>
    1201 <t>   
     1195<t anchor="reason-phrase">   
    12021196   The reason-phrase element exists for the sole purpose of providing a
    12031197   textual description associated with the numeric status code, mostly
    12091203  <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> )
    1211 </section>
    15711564   The presence of a message body in a response depends on both
    15721565   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"/>).
    15741567   Responses to the HEAD request method never include a message body
    15751568   because the associated response header fields (e.g., Transfer-Encoding,
    23032296<section title="Identifying a Target Resource" anchor="target-resource">
     2297  <iref primary="true" item="target resource"/>
     2298  <iref primary="true" item="target URI"/>
    23052300   HTTP is used in a wide variety of applications, ranging from
    23172312   its absolute form in order to obtain the target URI.  The target URI
    23182313   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"/>).
    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 request
    2361    message (<xref target="http.message"/>) with a request-target derived from
    2362    the target URI.  There are four distinct formats for the request-target
    2363    (<xref target="request-target"/>), depending on both the method being
    2364    requested and whether the request is to a proxy.
     2354<section title="Request Target" anchor="request-target">
     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.
     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>
    23662368<t anchor="origin-form"><iref item="origin form (of request-target)"/>
    23672369   The most common form of request-target is that used when making
    25782580<section title="Effective Request URI" anchor="effective.request.uri">
    25792581  <iref primary="true" item="effective request URI"/>
    2580   <iref primary="true" item="target resource"/>
    25822583   HTTP requests often do not carry the absolute URI (<xref target="RFC3986" x:fmt="," x:sec="4.3"/>)
    39323933   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"/>)
    39343936   and blocks of header fields (<xref target="header.fields"/>). These are
    39353937   minimum recommendations, chosen to be supportable even by implementations
    3936    with limited resources; it is expected that most implementations will choose
    3937    substantially higher limits.
     3938   with limited resources; it is expected that most implementations will
     3939   choose substantially higher limits.
Note: See TracChangeset for help on using the changeset viewer.