Ignore:
Timestamp:
Sep 1, 2011, 5:24:29 PM (8 years ago)
Author:
fielding@…
Message:

(editorial) rearrange some sections for better readability and
adjust some of the headings.

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r1427 r1431  
    478478</section>
    479479
    480 <section title="HTTP-related architecture" anchor="architecture">
     480<section title="Architecture" anchor="architecture">
    481481<t>
    482482   HTTP was created for the World Wide Web architecture
    … …  
    11351135   indicating the end of the header section, and an optional message-body.
    11361136</t>
     1137<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="HTTP-message"/>
     1138  <x:ref>HTTP-message</x:ref>    = <x:ref>start-line</x:ref>
     1139                    *( <x:ref>header-field</x:ref> <x:ref>CRLF</x:ref> )
     1140                    <x:ref>CRLF</x:ref>
     1141                    [ <x:ref>message-body</x:ref> ]
     1142</artwork></figure>
     1143<t>
     1144   The normal procedure for parsing an HTTP message is to read the
     1145   start-line into a structure, read each header field into a hash
     1146   table by field name until the empty line, and then use the parsed
     1147   data to determine if a message-body is expected.  If a message-body
     1148   has been indicated, then it is read as a stream until an amount
     1149   of octets equal to the message-body length is read or the connection
     1150   is closed.
     1151</t>
     1152<t>
     1153   Recipients &MUST; parse an HTTP message as a sequence of octets in an
     1154   encoding that is a superset of US-ASCII <xref target="USASCII"/>.
     1155   Parsing an HTTP message as a stream of Unicode characters, without regard
     1156   for the specific encoding, creates security vulnerabilities due to the
     1157   varying ways that string processing libraries handle invalid multibyte
     1158   character sequences that contain the octet LF (%x0A).  String-based
     1159   parsers can only be safely used within protocol elements after the element
     1160   has been extracted from the message, such as within a header field-value
     1161   after message parsing has delineated the individual fields.
     1162</t>
     1163
     1164<section anchor="start.line" title="Start Line">
    11371165<t>
    11381166   An HTTP message can either be a request from client to server or a
    … …  
    11471175   and clients are implemented to only expect a response.
    11481176</t>
    1149 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="HTTP-message"/>
    1150   <x:ref>HTTP-message</x:ref>    = <x:ref>start-line</x:ref>
    1151                     *( <x:ref>header-field</x:ref> <x:ref>CRLF</x:ref> )
    1152                     <x:ref>CRLF</x:ref>
    1153                     [ <x:ref>message-body</x:ref> ]
     1177<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="start-line"/>
    11541178  <x:ref>start-line</x:ref>      = <x:ref>Request-Line</x:ref> / <x:ref>Status-Line</x:ref>
    11551179</artwork></figure>
     1180<t>
     1181</t>
    11561182<t>
    11571183   Implementations &MUST-NOT; send whitespace between the start-line and
    … …  
    11631189   Likewise, the presence of such whitespace in a response might be
    11641190   ignored by some clients or cause others to cease parsing.
    1165 </t>
    1166 
    1167 <section title="Message Parsing and Robustness" anchor="message.robustness">
    1168 <t>
    1169    The normal procedure for parsing an HTTP message is to read the
    1170    start-line into a structure, read each header field into a hash
    1171    table by field name until the empty line, and then use the parsed
    1172    data to determine if a message-body is expected.  If a message-body
    1173    has been indicated, then it is read as a stream until an amount
    1174    of octets equal to the message-body length is read or the connection
    1175    is closed.
    1176 </t>
    1177 <t>
    1178    Recipients &MUST; parse an HTTP message as a sequence of octets in an
    1179    encoding that is a superset of US-ASCII <xref target="USASCII"/>.
    1180    Parsing an HTTP message as a stream of Unicode characters, without regard
    1181    for the specific encoding, creates security vulnerabilities due to the
    1182    varying ways that string processing libraries handle invalid multibyte
    1183    character sequences that contain the octet LF (%x0A).  String-based
    1184    parsers can only be safely used within protocol elements after the element
    1185    has been extracted from the message, such as within a header field-value
    1186    after message parsing has delineated the individual fields.
    1187 </t>
    1188 <t>
    1189    Older HTTP/1.0 client implementations might send an extra CRLF
    1190    after a POST request as a lame workaround for some early server
    1191    applications that failed to read message-body content that was
    1192    not terminated by a line-ending. An HTTP/1.1 client &MUST-NOT;
    1193    preface or follow a request with an extra CRLF.  If terminating
    1194    the request message-body with a line-ending is desired, then the
    1195    client &MUST; include the terminating CRLF octets as part of the
    1196    message-body length.
    1197 </t>
    1198 <t>
    1199    In the interest of robustness, servers &SHOULD; ignore at least one
    1200    empty line received where a Request-Line is expected. In other words, if
    1201    the server is reading the protocol stream at the beginning of a
    1202    message and receives a CRLF first, it &SHOULD; ignore the CRLF.
    1203    Likewise, although the line terminator for the start-line and header
    1204    fields is the sequence CRLF, we recommend that recipients recognize a
    1205    single LF as a line terminator and ignore any CR.
    1206 </t>
    1207 <t>
    1208    When a server listening only for HTTP request messages, or processing
    1209    what appears from the start-line to be an HTTP request message,
    1210    receives a sequence of octets that does not match the HTTP-message
    1211    grammar aside from the robustness exceptions listed above, the
    1212    server &MUST; respond with an HTTP/1.1 400 (Bad Request) response. 
    12131191</t>
    12141192</section>
    … …  
    16041582</section>
    16051583
    1606 <section anchor="incomplete.messages" title="Incomplete Messages">
     1584<section anchor="incomplete.messages" title="Handling Incomplete Messages">
    16071585<t>
    16081586   Request messages that are prematurely terminated, possibly due to a
    … …  
    16471625</section>
    16481626
    1649 <section title="General Header Fields" anchor="general.header.fields">
    1650   <x:anchor-alias value="general-header"/>
    1651 <t>
    1652    There are a few header fields which have general applicability for
    1653    both request and response messages, but which do not apply to the
    1654    payload being transferred. These header fields apply only to the
    1655    message being transmitted.
    1656 </t>
    1657 <texttable align="left">
    1658   <ttcol>Header Field Name</ttcol>
    1659   <ttcol>Defined in...</ttcol>
    1660  
    1661   <c>Connection</c> <c><xref target="header.connection"/></c>
    1662   <c>Date</c> <c><xref target="header.date"/></c>
    1663   <c>Trailer</c> <c><xref target="header.trailer"/></c>
    1664   <c>Transfer-Encoding</c> <c><xref target="header.transfer-encoding"/></c>
    1665   <c>Upgrade</c> <c><xref target="header.upgrade"/></c>
    1666   <c>Via</c> <c><xref target="header.via"/></c>
    1667 </texttable>
     1627<section title="Message Parsing Robustness" anchor="message.robustness">
     1628<t>
     1629   Older HTTP/1.0 client implementations might send an extra CRLF
     1630   after a POST request as a lame workaround for some early server
     1631   applications that failed to read message-body content that was
     1632   not terminated by a line-ending. An HTTP/1.1 client &MUST-NOT;
     1633   preface or follow a request with an extra CRLF.  If terminating
     1634   the request message-body with a line-ending is desired, then the
     1635   client &MUST; include the terminating CRLF octets as part of the
     1636   message-body length.
     1637</t>
     1638<t>
     1639   In the interest of robustness, servers &SHOULD; ignore at least one
     1640   empty line received where a Request-Line is expected. In other words, if
     1641   the server is reading the protocol stream at the beginning of a
     1642   message and receives a CRLF first, it &SHOULD; ignore the CRLF.
     1643   Likewise, although the line terminator for the start-line and header
     1644   fields is the sequence CRLF, we recommend that recipients recognize a
     1645   single LF as a line terminator and ignore any CR.
     1646</t>
     1647<t>
     1648   When a server listening only for HTTP request messages, or processing
     1649   what appears from the start-line to be an HTTP request message,
     1650   receives a sequence of octets that does not match the HTTP-message
     1651   grammar aside from the robustness exceptions listed above, the
     1652   server &MUST; respond with an HTTP/1.1 400 (Bad Request) response. 
     1653</t>
    16681654</section>
    16691655</section>
    … …  
    30813067<t>
    30823068   This section defines the syntax and semantics of HTTP header fields
    3083    related to message framing and transport protocols.
    3084 </t>
     3069   related to message origination, framing, and routing.
     3070</t>
     3071<texttable align="left">
     3072  <ttcol>Header Field Name</ttcol>
     3073  <ttcol>Defined in...</ttcol>
     3074 
     3075  <c>Connection</c> <c><xref target="header.connection"/></c>
     3076  <c>Content-Length</c> <c><xref target="header.content-length"/></c>
     3077  <c>Date</c> <c><xref target="header.date"/></c>
     3078  <c>Host</c> <c><xref target="header.host"/></c>
     3079  <c>TE</c> <c><xref target="header.te"/></c>
     3080  <c>Trailer</c> <c><xref target="header.trailer"/></c>
     3081  <c>Transfer-Encoding</c> <c><xref target="header.transfer-encoding"/></c>
     3082  <c>Upgrade</c> <c><xref target="header.upgrade"/></c>
     3083  <c>Via</c> <c><xref target="header.via"/></c>
     3084</texttable>
    30853085
    30863086<section title="Connection" anchor="header.connection">
Note: See TracChangeset for help on using the changeset viewer.