Changeset 2260 for draft-ietf-httpbis
- Timestamp:
- 19/05/13 22:21:45 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r2259 r2260 1132 1132 sake of network efficiency, security checks, or payload transformations. 1133 1133 </p> 1134 <p id="rfc.section.3.p.6">A sender <em class="bcp14">MUST NOT</em> send whitespace between the start-line and the first header field. A recipient that receives whitespace between the start-line 1135 and the first header field <em class="bcp14">MUST</em> either reject the message as invalid or consume each whitespace-preceded line without further processing of it (i.e., ignore 1136 the entire line, along with any subsequent lines preceded by whitespace, until a properly formed header field is received 1137 or the header block is terminated). 1138 </p> 1139 <p id="rfc.section.3.p.7">The presence of such whitespace in a request might be an attempt to trick a server into ignoring that field or processing 1140 the line after it as a new request, either of which might result in a security vulnerability if other implementations within 1141 the request chain interpret the same message differently. Likewise, the presence of such whitespace in a response might be 1142 ignored by some clients or cause others to cease parsing. 1143 </p> 1134 1144 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="start.line" href="#start.line">Start Line</a></h2> 1135 1145 <p id="rfc.section.3.1.p.1">An HTTP message can either be a request from client to server or a response from server to client. Syntactically, the two … … 1142 1152 </p> 1143 1153 <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.28"></span> <a href="#http.message" class="smpl">start-line</a> = <a href="#request.line" class="smpl">request-line</a> / <a href="#status.line" class="smpl">status-line</a> 1144 </pre><p id="rfc.section.3.1.p.4">A sender <em class="bcp14">MUST NOT</em> send whitespace between the start-line and the first header field. The presence of such whitespace in a request might be an 1145 attempt to trick a server into ignoring that field or processing the line after it as a new request, either of which might 1146 result in a security vulnerability if other implementations within the request chain interpret the same message differently. 1147 Likewise, the presence of such whitespace in a response might be ignored by some clients or cause others to cease parsing. 1148 </p> 1149 <p id="rfc.section.3.1.p.5">A recipient that receives whitespace between the start-line and the first header field <em class="bcp14">MUST</em> either reject the message as invalid or consume each whitespace-preceded line without further processing of it (i.e., ignore 1150 the entire line, along with any subsequent lines preceded by whitespace, until a properly formed header field is received 1151 or the header block is terminated). 1152 </p> 1153 <h3 id="rfc.section.3.1.1"><a href="#rfc.section.3.1.1">3.1.1</a> <a id="request.line" href="#request.line">Request Line</a></h3> 1154 </pre><h3 id="rfc.section.3.1.1"><a href="#rfc.section.3.1.1">3.1.1</a> <a id="request.line" href="#request.line">Request Line</a></h3> 1154 1155 <p id="rfc.section.3.1.1.p.1">A request-line begins with a method token, followed by a single space (SP), the request-target, another single space (SP), 1155 1156 the protocol version, and ending with CRLF. … … 1275 1276 <p id="rfc.section.3.2.4.p.4">Historically, HTTP header field values could be extended over multiple lines by preceding each extra line with at least one 1276 1277 space or horizontal tab (obs-fold). This specification deprecates such line folding except within the message/http media type 1277 (<a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section 7.3.1</a>). Senders <em class="bcp14">MUST NOT</em> generate messages that include line folding (i.e., that contain any field-value that contains a match to the <a href="#header.fields" class="smpl">obs-fold</a> rule) unless the message is intended for packaging within the message/http media type. When an <a href="#header.fields" class="smpl">obs-fold</a> is received in a message, recipients <em class="bcp14">MUST</em> do one of: 1278 </p> 1279 <ul> 1280 <li>accept the message and replace any embedded <a href="#header.fields" class="smpl">obs-fold</a> whitespace with either a single <a href="#core.rules" class="smpl">SP</a> or a matching number of <a href="#core.rules" class="smpl">SP</a> octets (to avoid buffer copying) prior to interpreting the field value or forwarding the message downstream; 1281 </li> 1282 <li>if it is a request, reject the message by sending a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> response with a representation explaining that obsolete line folding is unacceptable; or, 1283 </li> 1284 <li>if it is a response, discard the message and generate a <a href="p2-semantics.html#status.502" class="smpl">502 (Bad Gateway)</a> response with a representation explaining that unacceptable line folding was received. 1285 </li> 1286 </ul> 1287 <p> Recipients that choose not to implement <a href="#header.fields" class="smpl">obs-fold</a> processing (as described above) <em class="bcp14">MUST NOT</em> accept messages containing header fields with leading whitespace, as this can expose them to attacks that exploit this difference 1288 in processing. 1289 </p> 1290 <p id="rfc.section.3.2.4.p.5">Historically, HTTP has allowed field content with text in the ISO-8859-1 <a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a> charset, supporting other charsets only through use of <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a> encoding. In practice, most HTTP header field values use only a subset of the US-ASCII charset <a href="#USASCII" id="rfc.xref.USASCII.3"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a>. Newly defined header fields <em class="bcp14">SHOULD</em> limit their field values to US-ASCII octets. Recipients <em class="bcp14">SHOULD</em> treat other octets in field content (obs-text) as opaque data. 1278 (<a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section 7.3.1</a>). Senders <em class="bcp14">MUST NOT</em> generate messages that include line folding (i.e., that contain any field-value that contains a match to the <a href="#header.fields" class="smpl">obs-fold</a> rule) unless the message is intended for packaging within the message/http media type. 1279 </p> 1280 <p id="rfc.section.3.2.4.p.5">A server that receives an <a href="#header.fields" class="smpl">obs-fold</a> in a request message that is not within a message/http container <em class="bcp14">MUST</em> either reject the message by sending a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a>, preferably with a representation explaining that obsolete line folding is unacceptable, or replace each received <a href="#header.fields" class="smpl">obs-fold</a> with one or more <a href="#core.rules" class="smpl">SP</a> octets prior to interpreting the field value or forwarding the message downstream. 1281 </p> 1282 <p id="rfc.section.3.2.4.p.6">A proxy or gateway that receives an <a href="#header.fields" class="smpl">obs-fold</a> in a response message that is not within a message/http container <em class="bcp14">MUST</em> either discard the message and replace it with a <a href="p2-semantics.html#status.502" class="smpl">502 (Bad Gateway)</a> response, preferably with a representation explaining that unacceptable line folding was received, or replace each received <a href="#header.fields" class="smpl">obs-fold</a> with one or more <a href="#core.rules" class="smpl">SP</a> octets prior to interpreting the field value or forwarding the message downstream. 1283 </p> 1284 <p id="rfc.section.3.2.4.p.7">A user agent that receives an <a href="#header.fields" class="smpl">obs-fold</a> in a response message that is not within a message/http container <em class="bcp14">MUST</em> replace each received <a href="#header.fields" class="smpl">obs-fold</a> with one or more <a href="#core.rules" class="smpl">SP</a> octets prior to interpreting the field value. 1285 </p> 1286 <p id="rfc.section.3.2.4.p.8">Historically, HTTP has allowed field content with text in the ISO-8859-1 <a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a> charset, supporting other charsets only through use of <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a> encoding. In practice, most HTTP header field values use only a subset of the US-ASCII charset <a href="#USASCII" id="rfc.xref.USASCII.3"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a>. Newly defined header fields <em class="bcp14">SHOULD</em> limit their field values to US-ASCII octets. Recipients <em class="bcp14">SHOULD</em> treat other octets in field content (obs-text) as opaque data. 1291 1287 </p> 1292 1288 <h3 id="rfc.section.3.2.5"><a href="#rfc.section.3.2.5">3.2.5</a> <a id="field.limits" href="#field.limits">Field Limits</a></h3> -
draft-ietf-httpbis/latest/p1-messaging.xml
r2259 r2260 1017 1017 checks, or payload transformations. 1018 1018 </t> 1019 1020 <section title="Start Line" anchor="start.line">1021 <x:anchor-alias value="Start-Line"/>1022 <t>1023 An HTTP message can either be a request from client to server or a1024 response from server to client. Syntactically, the two types of message1025 differ only in the start-line, which is either a request-line (for requests)1026 or a status-line (for responses), and in the algorithm for determining1027 the length of the message body (<xref target="message.body"/>).1028 </t>1029 <t>1030 In theory, a client could receive requests and a server could receive1031 responses, distinguishing them by their different start-line formats,1032 but in practice servers are implemented to only expect a request1033 (a response is interpreted as an unknown or invalid request method)1034 and clients are implemented to only expect a response.1035 </t>1036 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="start-line"/>1037 <x:ref>start-line</x:ref> = <x:ref>request-line</x:ref> / <x:ref>status-line</x:ref>1038 </artwork></figure>1039 1019 <t> 1040 1020 A sender &MUST-NOT; send whitespace between the start-line and 1041 the first header field. The presence of such whitespace in a request 1021 the first header field. 1022 A recipient that receives whitespace between the start-line and 1023 the first header field &MUST; either reject the message as invalid or 1024 consume each whitespace-preceded line without further processing of it 1025 (i.e., ignore the entire line, along with any subsequent lines preceded 1026 by whitespace, until a properly formed header field is received or the 1027 header block is terminated). 1028 </t> 1029 <t> 1030 The presence of such whitespace in a request 1042 1031 might be an attempt to trick a server into ignoring that field or 1043 1032 processing the line after it as a new request, either of which might … … 1047 1036 ignored by some clients or cause others to cease parsing. 1048 1037 </t> 1049 <t> 1050 A recipient that receives whitespace between the start-line and 1051 the first header field &MUST; either reject the message as invalid or 1052 consume each whitespace-preceded line without further processing of it 1053 (i.e., ignore the entire line, along with any subsequent lines preceded 1054 by whitespace, until a properly formed header field is received or the 1055 header block is terminated). 1056 </t> 1038 1039 <section title="Start Line" anchor="start.line"> 1040 <x:anchor-alias value="Start-Line"/> 1041 <t> 1042 An HTTP message can either be a request from client to server or a 1043 response from server to client. Syntactically, the two types of message 1044 differ only in the start-line, which is either a request-line (for requests) 1045 or a status-line (for responses), and in the algorithm for determining 1046 the length of the message body (<xref target="message.body"/>). 1047 </t> 1048 <t> 1049 In theory, a client could receive requests and a server could receive 1050 responses, distinguishing them by their different start-line formats, 1051 but in practice servers are implemented to only expect a request 1052 (a response is interpreted as an unknown or invalid request method) 1053 and clients are implemented to only expect a response. 1054 </t> 1055 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="start-line"/> 1056 <x:ref>start-line</x:ref> = <x:ref>request-line</x:ref> / <x:ref>status-line</x:ref> 1057 </artwork></figure> 1057 1058 1058 1059 <section title="Request Line" anchor="request.line"> … … 1318 1319 (i.e., that contain any field-value that contains a match to the 1319 1320 <x:ref>obs-fold</x:ref> rule) unless the message is intended for packaging 1320 within the message/http media type. When an <x:ref>obs-fold</x:ref> is 1321 received in a message, recipients &MUST; do one of: 1322 <list style="symbols"> 1323 <t>accept the message and replace any embedded <x:ref>obs-fold</x:ref> 1324 whitespace with either a single <x:ref>SP</x:ref> or a matching 1325 number of <x:ref>SP</x:ref> octets (to avoid buffer copying) prior to 1326 interpreting the field value or forwarding the message 1327 downstream;</t> 1328 1329 <t>if it is a request, reject the message by sending a 1330 <x:ref>400 (Bad Request)</x:ref> response with a representation 1331 explaining that obsolete line folding is unacceptable; or,</t> 1332 1333 <t>if it is a response, discard the message and generate a 1334 <x:ref>502 (Bad Gateway)</x:ref> response with a representation 1335 explaining that unacceptable line folding was received.</t> 1336 </list> 1337 Recipients that choose not to implement <x:ref>obs-fold</x:ref> processing 1338 (as described above) &MUST-NOT; accept messages containing header fields 1339 with leading whitespace, as this can expose them to attacks that exploit 1340 this difference in processing. 1321 within the message/http media type. 1322 </t> 1323 <t> 1324 A server that receives an <x:ref>obs-fold</x:ref> in a request message that 1325 is not within a message/http container &MUST; either reject the message by 1326 sending a <x:ref>400 (Bad Request)</x:ref>, preferably with a 1327 representation explaining that obsolete line folding is unacceptable, or 1328 replace each received <x:ref>obs-fold</x:ref> with one or more 1329 <x:ref>SP</x:ref> octets prior to interpreting the field value or 1330 forwarding the message downstream. 1331 </t> 1332 <t> 1333 A proxy or gateway that receives an <x:ref>obs-fold</x:ref> in a response 1334 message that is not within a message/http container &MUST; either discard 1335 the message and replace it with a <x:ref>502 (Bad Gateway)</x:ref> 1336 response, preferably with a representation explaining that unacceptable 1337 line folding was received, or replace each received <x:ref>obs-fold</x:ref> 1338 with one or more <x:ref>SP</x:ref> octets prior to interpreting the field 1339 value or forwarding the message downstream. 1340 </t> 1341 <t> 1342 A user agent that receives an <x:ref>obs-fold</x:ref> in a response message 1343 that is not within a message/http container &MUST; replace each received 1344 <x:ref>obs-fold</x:ref> with one or more <x:ref>SP</x:ref> octets prior to 1345 interpreting the field value. 1341 1346 </t> 1342 1347 <t>
Note: See TracChangeset
for help on using the changeset viewer.