Changeset 1431 for draft-ietf-httpbis/latest/p1-messaging.xml
- Timestamp:
- 02/09/11 00:24:29 (11 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r1427 r1431 478 478 </section> 479 479 480 <section title=" HTTP-related architecture" anchor="architecture">480 <section title="Architecture" anchor="architecture"> 481 481 <t> 482 482 HTTP was created for the World Wide Web architecture … … 1135 1135 indicating the end of the header section, and an optional message-body. 1136 1136 </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"> 1137 1165 <t> 1138 1166 An HTTP message can either be a request from client to server or a … … 1147 1175 and clients are implemented to only expect a response. 1148 1176 </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"/> 1154 1178 <x:ref>start-line</x:ref> = <x:ref>Request-Line</x:ref> / <x:ref>Status-Line</x:ref> 1155 1179 </artwork></figure> 1180 <t> 1181 </t> 1156 1182 <t> 1157 1183 Implementations &MUST-NOT; send whitespace between the start-line and … … 1163 1189 Likewise, the presence of such whitespace in a response might be 1164 1190 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 the1170 start-line into a structure, read each header field into a hash1171 table by field name until the empty line, and then use the parsed1172 data to determine if a message-body is expected. If a message-body1173 has been indicated, then it is read as a stream until an amount1174 of octets equal to the message-body length is read or the connection1175 is closed.1176 </t>1177 <t>1178 Recipients &MUST; parse an HTTP message as a sequence of octets in an1179 encoding that is a superset of US-ASCII <xref target="USASCII"/>.1180 Parsing an HTTP message as a stream of Unicode characters, without regard1181 for the specific encoding, creates security vulnerabilities due to the1182 varying ways that string processing libraries handle invalid multibyte1183 character sequences that contain the octet LF (%x0A). String-based1184 parsers can only be safely used within protocol elements after the element1185 has been extracted from the message, such as within a header field-value1186 after message parsing has delineated the individual fields.1187 </t>1188 <t>1189 Older HTTP/1.0 client implementations might send an extra CRLF1190 after a POST request as a lame workaround for some early server1191 applications that failed to read message-body content that was1192 not terminated by a line-ending. An HTTP/1.1 client &MUST-NOT;1193 preface or follow a request with an extra CRLF. If terminating1194 the request message-body with a line-ending is desired, then the1195 client &MUST; include the terminating CRLF octets as part of the1196 message-body length.1197 </t>1198 <t>1199 In the interest of robustness, servers &SHOULD; ignore at least one1200 empty line received where a Request-Line is expected. In other words, if1201 the server is reading the protocol stream at the beginning of a1202 message and receives a CRLF first, it &SHOULD; ignore the CRLF.1203 Likewise, although the line terminator for the start-line and header1204 fields is the sequence CRLF, we recommend that recipients recognize a1205 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 processing1209 what appears from the start-line to be an HTTP request message,1210 receives a sequence of octets that does not match the HTTP-message1211 grammar aside from the robustness exceptions listed above, the1212 server &MUST; respond with an HTTP/1.1 400 (Bad Request) response.1213 1191 </t> 1214 1192 </section> … … 1604 1582 </section> 1605 1583 1606 <section anchor="incomplete.messages" title=" Incomplete Messages">1584 <section anchor="incomplete.messages" title="Handling Incomplete Messages"> 1607 1585 <t> 1608 1586 Request messages that are prematurely terminated, possibly due to a … … 1647 1625 </section> 1648 1626 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> 1668 1654 </section> 1669 1655 </section> … … 3081 3067 <t> 3082 3068 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> 3085 3085 3086 3086 <section title="Connection" anchor="header.connection">
Note: See TracChangeset
for help on using the changeset viewer.