![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Changeset 2030 for draft-ietf-httpbis/latest/p1-messaging.xml
- Timestamp:
- Dec 4, 2012, 4:58:55 AM (7 years ago)
- File:
-
- 1 edited
-
draft-ietf-httpbis/latest/p1-messaging.xml (modified) (18 diffs)
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r2029 r2030 185 185 </t> 186 186 <t> 187 One consequence of HTTPflexibility is that the protocol cannot be187 One consequence of this flexibility is that the protocol cannot be 188 188 defined in terms of what occurs behind the interface. Instead, we 189 189 are limited to defining the syntax of communication, the intent … … 298 298 The terms client and server refer only to the roles that 299 299 these programs perform for a particular connection. The same program 300 might act as a client on some connections and a server on others. We use 301 the term "<x:dfn>user agent</x:dfn>" to refer to the program that initiates a request, 302 such as a WWW browser, editor, or spider (web-traversing robot), and 303 the term "<x:dfn>origin server</x:dfn>" to refer to the program that can originate 304 authoritative responses to a request. For general requirements, we use 305 the term "<x:dfn>sender</x:dfn>" to refer to whichever component sent a given message 306 and the term "<x:dfn>recipient</x:dfn>" to refer to any component that receives the 307 message. 300 might act as a client on some connections and a server on others. 301 We use the term "<x:dfn>user agent</x:dfn>" to refer to any of the various 302 client programs that initiate a request, including (but not limited to) 303 browsers, spiders (web-based robots), command-line tools, native 304 applications, and mobile apps. The term "<x:dfn>origin server</x:dfn>" is 305 used to refer to the program that can originate authoritative responses to 306 a request. For general requirements, we use the terms 307 "<x:dfn>sender</x:dfn>" and "<x:dfn>recipient</x:dfn>" to refer to any 308 component that sends or receives, respectively, a given message. 308 309 </t> 309 310 <t> … … 887 888 invocation options, configuration files, or bookmark lists, even 888 889 though such usage might expose a user identifier or password. 889 Senders &MUST -NOT; include auserinfo subcomponent (and its "@"890 delimiter) when transmitting an "http" URI in a message. Recipients891 of HTTP messages that contain a URI reference &SHOULD; parse for the892 existence of userinfo and treat its presence as an error, likely893 indicating that the deprecated subcomponent isbeing used to obscure890 Senders &MUST; exclude the userinfo subcomponent (and its "@" 891 delimiter) when an "http" URI is transmitted within a message as a 892 request target or header field value. 893 Recipients of an "http" URI reference &SHOULD; parse for userinfo and 894 treat its presence as an error, since it is likely being used to obscure 894 895 the authority for the sake of phishing attacks. 895 896 </t> … … 1068 1069 <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> 1069 1070 </artwork></figure> 1070 <t>1071 A server &MUST; be able to parse any received message that begins1072 with a request-line and matches the ABNF rule for HTTP-message.1073 </t>1074 1071 <iref primary="true" item="method"/> 1075 1072 <t anchor="method"> … … 1120 1117 Various ad-hoc limitations on request-line length are found in practice. 1121 1118 It is &RECOMMENDED; that all HTTP senders and recipients support, at a 1122 minimum, request-line lengths of up to8000 octets.1119 minimum, request-line lengths of 8000 octets. 1123 1120 </t> 1124 1121 </section> … … 1138 1135 <x:ref>status-line</x:ref> = <x:ref>HTTP-version</x:ref> <x:ref>SP</x:ref> <x:ref>status-code</x:ref> <x:ref>SP</x:ref> <x:ref>reason-phrase</x:ref> <x:ref>CRLF</x:ref> 1139 1136 </artwork></figure> 1140 <t>1141 A client &MUST; be able to parse any received message that begins1142 with a status-line and matches the ABNF rule for HTTP-message.1143 </t>1144 1137 <t> 1145 1138 The status-code element is a 3-digit integer code describing the … … 1193 1186 timestamp for the message in which it appears. 1194 1187 </t> 1188 1189 <section title="Field Extensibility" anchor="field.extensibility"> 1195 1190 <t> 1196 1191 HTTP header fields are fully extensible: there is no limit on the 1197 1192 introduction of new field names, each presumably defining new semantics, 1198 or on the number of header fields used in a given message. Existing1193 nor on the number of header fields used in a given message. Existing 1199 1194 fields are defined in each part of this specification and in many other 1200 specifications outside the standards process.1195 specifications outside the core standard. 1201 1196 New header fields can be introduced without changing the protocol version 1202 1197 if their defined semantics allow them to be safely ignored by recipients … … 1212 1207 Unrecognized header fields &SHOULD; be ignored by other recipients. 1213 1208 </t> 1209 </section> 1210 1211 <section title="Field Order" anchor="field.order"> 1214 1212 <t> 1215 1213 The order in which header fields with differing field names are … … 1227 1225 sent in a message unless the entire field value for that 1228 1226 header field is defined as a comma-separated list [i.e., #(values)]. 1227 </t> 1228 <t> 1229 1229 Multiple header fields with the same field name can be combined into 1230 1230 one "field-name: field-value" pair, without changing the semantics of the … … 1238 1238 <x:note> 1239 1239 <t> 1240 &Note; The "Set-Cookie" header field as implemented in 1241 practice can occur multiple times, but does not use the list syntax, and 1242 thus cannot be combined into a single line (<xref target="RFC6265"/>). (See Appendix A.2.3 of <xref target="Kri2001"/> 1243 for details.) 1244 </t> 1240 &Note; In practice, the "Set-Cookie" header field (<xref target="RFC6265"/>) 1241 often appears multiple times in a response message and does not use the 1242 list syntax, violating the above requirements on multiple header fields 1243 with the same name. Since it cannot be combined into a single field-value, 1244 recipients ought to handle "Set-Cookie" as a special case while processing 1245 header fields. (See Appendix A.2.3 of <xref target="Kri2001"/> for details.) 1246 </t> 1245 1247 </x:note> 1248 </section> 1246 1249 1247 1250 <section title="Whitespace" anchor="whitespace"> … … 1253 1256 <t anchor="rule.OWS"> 1254 1257 The OWS rule is used where zero or more linear whitespace octets might 1255 appear. OWS &SHOULD; either not be produced or be produced as a single1258 appear. OWS &SHOULD; either not be generated or be generated as a single 1256 1259 SP. Multiple OWS octets that occur within field-content &SHOULD; either 1257 1260 be replaced with a single SP or transformed to all SP octets (each … … 1261 1264 <t anchor="rule.RWS"> 1262 1265 RWS is used when at least one linear whitespace octet is required to 1263 separate field tokens. RWS &SHOULD; be produced as a single SP.1266 separate field tokens. RWS &SHOULD; be generated as a single SP. 1264 1267 Multiple RWS octets that occur within field-content &SHOULD; either 1265 1268 be replaced with a single SP or transformed to all SP octets before … … 1268 1271 <t anchor="rule.BWS"> 1269 1272 BWS is used where the grammar allows optional whitespace, for historical 1270 reasons, but senders &SHOULD-NOT; produce it in messages;1273 reasons, but senders &SHOULD-NOT; generate it in messages; 1271 1274 recipients &MUST; accept such bad optional whitespace and remove it before 1272 1275 interpreting the field value or forwarding the message downstream. … … 1311 1314 folding except within the message/http media type 1312 1315 (<xref target="internet.media.type.message.http"/>). 1313 HTTP senders &MUST-NOT; produce messages that include line folding1316 HTTP senders &MUST-NOT; generate messages that include line folding 1314 1317 (i.e., that contain any field-value that matches the obs-fold rule) unless 1315 1318 the message is intended for packaging within the message/http media type. … … 1331 1334 </section> 1332 1335 1333 <section title="Field Length" anchor="field.length"> 1334 <t> 1335 HTTP does not place a pre-defined limit on the length of header fields, 1336 either in isolation or as a set. A server &MUST; be prepared to receive 1337 request header fields of unbounded length and respond with a <x:ref>4xx 1338 (Client Error)</x:ref> status code if the received header field(s) would be 1339 longer than the server wishes to handle. 1340 </t> 1341 <t> 1342 A client that receives response header fields that are longer than it wishes 1343 to handle can only treat it as a server error. 1344 </t> 1345 <t> 1346 Various ad-hoc limitations on header field length are found in practice. It 1347 is &RECOMMENDED; that all HTTP senders and recipients support messages whose 1348 combined header fields have 4000 or more octets. 1336 <section title="Field Limits" anchor="field.limits"> 1337 <t> 1338 HTTP does not place a pre-defined limit on the length of each header field 1339 or on the length of the header block as a whole. Various ad-hoc 1340 limitations on individual header field length are found in practice, 1341 often depending on the specific field semantics. 1342 </t> 1343 <t> 1344 A server &MUST; be prepared to receive request header fields of unbounded 1345 length and respond with an appropriate <x:ref>4xx (Client Error)</x:ref> 1346 status code if the received header field(s) are larger than the server 1347 wishes to process. 1348 </t> 1349 <t> 1350 A client &MUST; be prepared to receive response header fields of unbounded 1351 length. A client &MAY; discard or truncate received header fields that are 1352 larger than the client wishes to process if the field semantics are such 1353 that the dropped value(s) can be safely ignored without changing the 1354 response semantics. 1349 1355 </t> 1350 1356 </section> … … 1398 1404 </artwork></figure> 1399 1405 <t> 1400 Recipients that process the value of thequoted-string &MUST; handle a1406 Recipients that process the value of a quoted-string &MUST; handle a 1401 1407 quoted-pair as if it were replaced by the octet following the backslash. 1402 1408 </t> 1403 1409 <t> 1404 Senders &SHOULD-NOT; escape octets in quoted-strings that do not require1405 escaping (i.e., other than DQUOTE and the backslash octet).1410 Senders &SHOULD-NOT; generate a quoted-pair in a quoted-string except where 1411 necessary to quote DQUOTE and backslash octets occurring within that string. 1406 1412 </t> 1407 1413 <t anchor="rule.comment"> … … 1891 1897 transfer it as a series of chunks, each with its own size indicator, 1892 1898 followed by an &OPTIONAL; trailer containing header fields. This 1893 allows dynamically produced content to be transferred along with the1899 allows dynamically generated content to be transferred along with the 1894 1900 information necessary for the recipient to verify that it has 1895 1901 received the full message. … … 4702 4708 with a "Connection: keep-alive" request header field. However, some 4703 4709 experimental implementations of HTTP/1.0 persistent connections are faulty; 4704 for example, if a HTTP/1.0 proxy server doesn't understand4710 for example, if an HTTP/1.0 proxy server doesn't understand 4705 4711 <x:ref>Connection</x:ref>, it will erroneously forward that header field 4706 4712 to the next inbound server, which would result in a hung connection.
Note: See TracChangeset
for help on using the changeset viewer.
