Changeset 2033 for draft-ietf-httpbis/latest/p1-messaging.xml
- Timestamp:
- 06/12/12 11:51:08 (9 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r2032 r2033 1762 1762 when a connection is closed prematurely or when decoding a supposedly 1763 1763 chunked transfer coding fails, &MUST; record the message as incomplete. 1764 Cache requirements for incomplete responses are defined in 1765 &cache-incomplete;. 1766 </t> 1767 <t> 1764 1768 If a response terminates in the middle of the header block (before the 1765 1769 empty line is received) and the status code might rely on header fields to … … 1778 1782 message body octets received, provided that the header block was received 1779 1783 intact. 1780 </t>1781 <t>1782 A user agent &MUST-NOT; render an incomplete response message body as if1783 it were complete (i.e., some indication needs to be given to the user that an1784 error occurred). Cache requirements for incomplete responses are defined1785 in &cache-incomplete;.1786 </t>1787 <t>1788 A server &MUST; read the entire request message body or close1789 the connection after sending its response, since otherwise the1790 remaining data on a persistent connection would be misinterpreted1791 as the next request. Likewise,1792 a client &MUST; read the entire response message body if it intends1793 to reuse the same connection for a subsequent request. Pipelining1794 multiple requests on a connection is described in <xref target="pipelining"/>.1795 1784 </t> 1796 1785 </section> … … 2823 2812 </t> 2824 2813 <t> 2814 A server &MAY; assume that an HTTP/1.1 client intends to maintain a 2815 persistent connection until a <x:ref>close</x:ref> connection option 2816 is received in a request. 2817 </t> 2818 <t> 2819 A client &MAY; reuse a persistent connection until it sends or receives 2820 a <x:ref>close</x:ref> connection option or receives an HTTP/1.0 response 2821 without a "keep-alive" connection option. 2822 </t> 2823 <t> 2824 In order to remain persistent, all messages on a connection &MUST; 2825 have a self-defined message length (i.e., one not defined by closure 2826 of the connection), as described in <xref target="message.body"/>. 2827 A server &MUST; read the entire request message body or close 2828 the connection after sending its response, since otherwise the 2829 remaining data on a persistent connection would be misinterpreted 2830 as the next request. Likewise, 2831 a client &MUST; read the entire response message body if it intends 2832 to reuse the same connection for a subsequent request. 2833 </t> 2834 <t> 2825 2835 A proxy server &MUST-NOT; maintain a persistent connection with an 2826 2836 HTTP/1.0 client (see <xref x:sec="19.7.1" x:fmt="of" target="RFC2068"/> for 2827 2837 information and discussion of the problems with the Keep-Alive header field 2828 2838 implemented by many HTTP/1.0 clients). 2829 </t>2830 <t>2831 In order to remain persistent, all messages on a connection &MUST;2832 have a self-defined message length (i.e., one not defined by closure2833 of the connection), as described in <xref target="message.body"/>.2834 </t>2835 </section>2836 2837 <section title="Reuse" anchor="persistent.reuse">2838 <t>2839 A server &MAY; assume that an HTTP/1.1 client intends to maintain a2840 persistent connection until a <x:ref>close</x:ref> connection option2841 is received in a request.2842 </t>2843 <t>2844 A client &MAY; reuse a persistent connection until it sends or receives2845 a <x:ref>close</x:ref> connection option or receives an HTTP/1.0 response2846 without a "keep-alive" connection option.2847 2839 </t> 2848 2840 <t> … … 3610 3602 </section> 3611 3603 3612 <section title=" Protocol Element SizeOverflows" anchor="attack.protocol.element.size.overflows">3604 <section title="Buffer Overflows" anchor="attack.protocol.element.size.overflows"> 3613 3605 <t> 3614 3606 Because HTTP uses mostly textual, character-delimited fields, attackers can … … 3635 3627 phrases, header field-names, and body chunks, so as to avoid denial of 3636 3628 service attacks without impeding interoperability. 3629 </t> 3630 </section> 3631 3632 <section title="Message Integrity" anchor="message.integrity"> 3633 <t> 3634 HTTP does not define a specific mechanism for ensuring message integrity, 3635 instead relying on the error-detection ability of underlying transport 3636 protocols and the use of length or chunk-delimited framing to detect 3637 completeness. Additional integrity mechanisms, such as hash functions or 3638 digital signatures applied to the content, can be selectively added to 3639 messages via extensible metadata header fields. Historically, the lack of 3640 a single integrity mechanism has been justified by the informal nature of 3641 most HTTP communication. However, the prevalence of HTTP as an information 3642 access mechanism has resulted in its increasing use within environments 3643 where verification of message integrity is crucial. 3644 </t> 3645 <t> 3646 User agents are encouraged to implement configurable means for detecting 3647 and reporting failures of message integrity such that those means can be 3648 enabled within environments for which integrity is necessary. For example, 3649 a browser being used to view medical history or drug interaction 3650 information needs to indicate to the user when such information is detected 3651 by the protocol to be incomplete, expired, or corrupted during transfer. 3652 Such mechanisms might be selectively enabled via user agent extensions or 3653 the presence of message integrity metadata in a response. 3654 At a minimum, user agents ought to provide some indication that allows a 3655 user to distinguish between a complete and incomplete response message 3656 (<xref target="incomplete.messages"/>) when such verification is desired. 3637 3657 </t> 3638 3658 </section> … … 4840 4860 The requirement to retry requests under certain circumstances when the 4841 4861 server prematurely closes the connection has been removed. 4842 (<xref target="persistent. reuse"/>)4862 (<xref target="persistent.connections"/>) 4843 4863 </t> 4844 4864 <t>
Note: See TracChangeset
for help on using the changeset viewer.