Changeset 994 for draft-ietf-httpbis/latest/p1-messaging.xml
- Timestamp:
- 07/09/10 11:46:12 (12 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r992 r994 1199 1199 <x:note> 1200 1200 <t> 1201 <x:h>Note:</x:h> The "Set-Cookie" header as implemented in1201 <x:h>Note:</x:h> The "Set-Cookie" header field as implemented in 1202 1202 practice (as opposed to how it is specified in <xref target="RFC2109"/>) 1203 1203 can occur multiple times, but does not use the list syntax, and thus cannot 1204 1204 be combined into a single line. (See Appendix A.2.3 of <xref target="Kri2001"/> 1205 for details.) Also note that the Set-Cookie2 header specified in1205 for details.) Also note that the Set-Cookie2 header field specified in 1206 1206 <xref target="RFC2965"/> does not share this problem. 1207 1207 </t> … … 2263 2263 <x:anchor-alias value="qvalue"/> 2264 2264 <t> 2265 Both transfer codings (TE request header , <xref target="header.te"/>)2265 Both transfer codings (TE request header field, <xref target="header.te"/>) 2266 2266 and content negotiation (&content.negotiation;) use short "floating point" 2267 2267 numbers to indicate the relative importance ("weight") of various … … 2362 2362 <t> 2363 2363 An HTTP/1.1 server &MAY; assume that a HTTP/1.1 client intends to 2364 maintain a persistent connection unless a Connection header including2364 maintain a persistent connection unless a Connection header field including 2365 2365 the connection-token "close" was sent in the request. If the server 2366 2366 chooses to close the connection immediately after sending the 2367 response, it &SHOULD; send a Connection header including the2367 response, it &SHOULD; send a Connection header field including the 2368 2368 connection-token "close". 2369 2369 </t> … … 2371 2371 An HTTP/1.1 client &MAY; expect a connection to remain open, but would 2372 2372 decide to keep it open based on whether the response from a server 2373 contains a Connection header with the connection-token close. In case2373 contains a Connection header field with the connection-token close. In case 2374 2374 the client does not want to maintain a connection for more than that 2375 request, it &SHOULD; send a Connection header including the2375 request, it &SHOULD; send a Connection header field including the 2376 2376 connection-token close. 2377 2377 </t> 2378 2378 <t> 2379 2379 If either the client or the server sends the close token in the 2380 Connection header , that request becomes the last one for the2380 Connection header field, that request becomes the last one for the 2381 2381 connection. 2382 2382 </t> … … 2435 2435 A proxy server &MUST-NOT; establish a HTTP/1.1 persistent connection 2436 2436 with an HTTP/1.0 client (but see <xref x:sec="19.7.1" x:fmt="of" target="RFC2068"/> 2437 for information and discussion of the problems with the Keep-Alive header 2437 for information and discussion of the problems with the Keep-Alive header field 2438 2438 implemented by many HTTP/1.0 clients). 2439 2439 </t> 2440 2440 2441 <section title="End-to-end and Hop-by-hop Header s" anchor="end-to-end.and.hop-by-hop.headers">2441 <section title="End-to-end and Hop-by-hop Header Fields" anchor="end-to-end.and.hop-by-hop.header-fields"> 2442 2442 <!--<t> 2443 2443 <cref anchor="TODO-end-to-end" source="jre"> … … 2448 2448 <t> 2449 2449 For the purpose of defining the behavior of caches and non-caching 2450 proxies, we divide HTTP header s into two categories:2450 proxies, we divide HTTP header fields into two categories: 2451 2451 <list style="symbols"> 2452 <t>End-to-end header s, which are transmitted to the ultimate2453 recipient of a request or response. End-to-end header s in2452 <t>End-to-end header fields, which are transmitted to the ultimate 2453 recipient of a request or response. End-to-end header fields in 2454 2454 responses MUST be stored as part of a cache entry and &MUST; be 2455 2455 transmitted in any response formed from a cache entry.</t> 2456 2456 2457 <t>Hop-by-hop header s, which are meaningful only for a single2457 <t>Hop-by-hop header fields, which are meaningful only for a single 2458 2458 transport-level connection, and are not stored by caches or 2459 2459 forwarded by proxies.</t> … … 2461 2461 </t> 2462 2462 <t> 2463 The following HTTP/1.1 header s are hop-by-hop headers:2463 The following HTTP/1.1 header fields are hop-by-hop header fields: 2464 2464 <list style="symbols"> 2465 2465 <t>Connection</t> … … 2474 2474 </t> 2475 2475 <t> 2476 All other header s defined by HTTP/1.1 are end-to-end headers.2477 </t> 2478 <t> 2479 Other hop-by-hop header s &MUST; be listed in a Connection header2476 All other header fields defined by HTTP/1.1 are end-to-end header fields. 2477 </t> 2478 <t> 2479 Other hop-by-hop header fields &MUST; be listed in a Connection header field 2480 2480 (<xref target="header.connection"/>). 2481 2481 </t> 2482 2482 </section> 2483 2483 2484 <section title="Non-modifiable Header s" anchor="non-modifiable.headers">2484 <section title="Non-modifiable Header Fields" anchor="non-modifiable.header-fields"> 2485 2485 <!--<t> 2486 2486 <cref anchor="TODO-non-mod-headers" source="jre"> … … 2491 2491 <t> 2492 2492 Some features of HTTP/1.1, such as Digest Authentication, depend on the 2493 value of certain end-to-end header s. A transparent proxy &SHOULD-NOT;2494 modify an end-to-end header unless the definition of that headerrequires2493 value of certain end-to-end header fields. A transparent proxy &SHOULD-NOT; 2494 modify an end-to-end header field unless the definition of that header field requires 2495 2495 or specifically allows that. 2496 2496 </t> … … 2515 2515 <t> 2516 2516 but it &MAY; add any of these fields if not already present. If an 2517 Expires header is added, it &MUST; be given a field-value identical to2518 that of the Date header in that response.2517 Expires header field is added, it &MUST; be given a field-value identical to 2518 that of the Date header field in that response. 2519 2519 </t> 2520 2520 <t> … … 2536 2536 <x:note> 2537 2537 <t> 2538 <x:h>Warning:</x:h> Unnecessary modification of end-to-end header s might2538 <x:h>Warning:</x:h> Unnecessary modification of end-to-end header fields might 2539 2539 cause authentication failures if stronger authentication 2540 2540 mechanisms are introduced in later versions of HTTP. Such … … 2640 2640 using a "chunked" encoding (<xref target="transfer.codings"/>), a zero length chunk and 2641 2641 empty trailer &MAY; be used to prematurely mark the end of the message. 2642 If the body was preceded by a Content-Length header , the client &MUST;2642 If the body was preceded by a Content-Length header field, the client &MUST; 2643 2643 close the connection. 2644 2644 </t> … … 2650 2650 allow a client that is sending a request message with a request body 2651 2651 to determine if the origin server is willing to accept the request 2652 (based on the request header s) before the client sends the request2652 (based on the request header fields) before the client sends the request 2653 2653 body. In some cases, it might either be inappropriate or highly 2654 2654 inefficient for the client to send the body if the server will reject … … 2771 2771 </t> 2772 2772 <t> 2773 Transmit the request-header s2773 Transmit the request-header fields 2774 2774 </t> 2775 2775 <t> … … 2864 2864 </t> 2865 2865 <t> 2866 The Connection header 's value has the following grammar:2866 The Connection header field's value has the following grammar: 2867 2867 </t> 2868 2868 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Connection"/><iref primary="true" item="Grammar" subitem="Connection-v"/><iref primary="true" item="Grammar" subitem="connection-token"/> … … 2882 2882 </t> 2883 2883 <t> 2884 Message header s listed in the Connection header&MUST-NOT; include2885 end-to-end header s, such as Cache-Control.2884 Message header fields listed in the Connection header field &MUST-NOT; include 2885 end-to-end header fields, such as Cache-Control. 2886 2886 </t> 2887 2887 <t> … … 2909 2909 <t> 2910 2910 A system receiving an HTTP/1.0 (or lower-version) message that 2911 includes a Connection header &MUST;, for each connection-token in this2911 includes a Connection header field &MUST;, for each connection-token in this 2912 2912 field, remove and ignore any header field(s) from the message with 2913 2913 the same name as the connection-token. This protects against mistaken … … 3015 3015 </t> 3016 3016 <t> 3017 The HTTP-date sent in a Date header &SHOULD-NOT; represent a date and3017 The HTTP-date sent in a Date header field &SHOULD-NOT; represent a date and 3018 3018 time subsequent to the generation of the message. It &SHOULD; represent 3019 3019 the best available approximation of the date and time of message … … 3239 3239 <t> 3240 3240 Many older HTTP/1.0 applications do not understand the Transfer-Encoding 3241 header .3241 header field. 3242 3242 </t> 3243 3243 </section> … … 4686 4686 <t> 4687 4687 The line terminator for header fields is the sequence CRLF. 4688 However, we recommend that applications, when parsing such headers ,4688 However, we recommend that applications, when parsing such headers fields, 4689 4689 recognize a single LF as a line terminator and ignore the leading CR. 4690 4690 </t> … … 4718 4718 of an age or expiration time.</t> 4719 4719 4720 <t>If an HTTP header incorrectly carries a date value with a time4720 <t>If an HTTP header field incorrectly carries a date value with a time 4721 4721 zone other than GMT, it &MUST; be converted into GMT using the 4722 4722 most conservative possible conversion.</t> … … 4784 4784 <section title="Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses" anchor="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses"> 4785 4785 <t> 4786 The requirements that clients and servers support the Host request-header ,4787 report an error if the Host request-header (<xref target="header.host"/>)is4786 The requirements that clients and servers support the Host request-header 4787 field (<xref target="header.host"/>), report an error if it is 4788 4788 missing from an HTTP/1.1 request, and accept absolute URIs (<xref target="request-target"/>) 4789 4789 are among the most important changes defined by this … … 4807 4807 requirements: 4808 4808 <list style="symbols"> 4809 <t>Both clients and servers &MUST; support the Host request-header .</t>4810 4811 <t>A client that sends an HTTP/1.1 request &MUST; send a Host header .</t>4809 <t>Both clients and servers &MUST; support the Host request-header field.</t> 4810 4811 <t>A client that sends an HTTP/1.1 request &MUST; send a Host header field.</t> 4812 4812 4813 4813 <t>Servers &MUST; report a 400 (Bad Request) error if an HTTP/1.1 4814 request does not include a Host request-header .</t>4814 request does not include a Host request-header field.</t> 4815 4815 4816 4816 <t>Servers &MUST; accept absolute URIs.</t> … … 4847 4847 <t> 4848 4848 The original HTTP/1.0 form of persistent connections (the Connection: 4849 Keep-Alive and Keep-Alive header ) is documented in <xref x:sec="19.7.1" x:fmt="of" target="RFC2068"/>.4849 Keep-Alive and Keep-Alive header field) is documented in <xref x:sec="19.7.1" x:fmt="of" target="RFC2068"/>. 4850 4850 </t> 4851 4851 </section> … … 5273 5273 <t> 5274 5274 Move "Product Tokens" section (back) into Part 1, as "token" is used 5275 in the definition of the Upgrade header .5275 in the definition of the Upgrade header field. 5276 5276 </t> 5277 5277 <t> … … 5300 5300 </t> 5301 5301 <t> 5302 Ongoing work on IANA Message Header Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40"/>):5302 Ongoing work on IANA Message Header Field Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40"/>): 5303 5303 <list style="symbols"> 5304 5304 <t> 5305 Reference RFC 3984, and update header registrations for headers defined5305 Reference RFC 3984, and update header field registrations for headers defined 5306 5306 in this document. 5307 5307 </t> … … 5393 5393 <t> 5394 5394 Rewrite ABNFs to spell out whitespace rules, factor out 5395 header value format definitions.5395 header field value format definitions. 5396 5396 </t> 5397 5397 </list> … … 5464 5464 <t> 5465 5465 Move definition of quality values from Part 3 into Part 1; 5466 make TE request header grammar independent of accept-params (defined in Part 3).5466 make TE request header field grammar independent of accept-params (defined in Part 3). 5467 5467 </t> 5468 5468 </list>
Note: See TracChangeset
for help on using the changeset viewer.