Ignore:
Timestamp:
Dec 6, 2012, 3:51:08 AM (7 years ago)
Author:
fielding@…
Message:

Move new user agent requirement on rendering incomplete responses to
a suggestion in security considerations. Addresses #408 and #415

Consolidate more stuff on persistent connection reuse. Addresses #396

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r2032 r2033  
    17621762   when a connection is closed prematurely or when decoding a supposedly
    17631763   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>
    17641768   If a response terminates in the middle of the header block (before the
    17651769   empty line is received) and the status code might rely on header fields to
     
    17781782   message body octets received, provided that the header block was received
    17791783   intact.
    1780 </t>
    1781 <t>
    1782    A user agent &MUST-NOT; render an incomplete response message body as if
    1783    it were complete (i.e., some indication needs to be given to the user that an
    1784    error occurred).  Cache requirements for incomplete responses are defined
    1785    in &cache-incomplete;.
    1786 </t>
    1787 <t>
    1788    A server &MUST; read the entire request message body or close
    1789    the connection after sending its response, since otherwise the
    1790    remaining data on a persistent connection would be misinterpreted
    1791    as the next request.  Likewise,
    1792    a client &MUST; read the entire response message body if it intends
    1793    to reuse the same connection for a subsequent request.  Pipelining
    1794    multiple requests on a connection is described in <xref target="pipelining"/>.
    17951784</t>
    17961785</section>
     
    28232812</t>
    28242813<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>
    28252835   A proxy server &MUST-NOT; maintain a persistent connection with an
    28262836   HTTP/1.0 client (see <xref x:sec="19.7.1" x:fmt="of" target="RFC2068"/> for
    28272837   information and discussion of the problems with the Keep-Alive header field
    28282838   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 closure
    2833    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 a
    2840    persistent connection until a <x:ref>close</x:ref> connection option
    2841    is received in a request.
    2842 </t>
    2843 <t>
    2844    A client &MAY; reuse a persistent connection until it sends or receives
    2845    a <x:ref>close</x:ref> connection option or receives an HTTP/1.0 response
    2846    without a "keep-alive" connection option.
    28472839</t>
    28482840<t>
     
    36103602</section>
    36113603
    3612 <section title="Protocol Element Size Overflows" anchor="attack.protocol.element.size.overflows">
     3604<section title="Buffer Overflows" anchor="attack.protocol.element.size.overflows">
    36133605<t>
    36143606   Because HTTP uses mostly textual, character-delimited fields, attackers can
     
    36353627   phrases, header field-names, and body chunks, so as to avoid denial of
    36363628   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.
    36373657</t>
    36383658</section>
     
    48404860  The requirement to retry requests under certain circumstances when the
    48414861  server prematurely closes the connection has been removed.
    4842   (<xref target="persistent.reuse"/>)
     4862  (<xref target="persistent.connections"/>)
    48434863</t>
    48444864<t>
Note: See TracChangeset for help on using the changeset viewer.