source: draft-ietf-httpbis/latest/auth48/rfc7230.abdiff.txt @ 2647

INTRODUCTION, paragraph 1:
OLD:

 HTTPbis Working Group                                   R. Fielding, Ed.
 Internet-Draft                                                     Adobe
 Obsoletes: 2145, 2616                                    J. Reschke, Ed.
 (if approved)                                                 greenbytes
 Updates: 2817, 2818 (if approved)                            May 6, 2014
 Intended status: Standards Track
 Expires: November 7, 2014

NEW:

 Internet Engineering Task Force (IETF)                  R. Fielding, Ed.
 Request for Comments: 7230                                         Adobe
 Obsoletes: 2145, 2616                                    J. Reschke, Ed.
 Updates: 2817, 2818                                           greenbytes
 Category: Standards Track                                       May 2014
 ISSN: 2070-1721


INTRODUCTION, paragraph 2:
OLD:

    Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
                  draft-ietf-httpbis-p1-messaging-latest

NEW:

    Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing


INTRODUCTION, paragraph 5:
OLD:

 Editorial Note (To be removed by RFC Editor)
 
    Discussion of this draft takes place on the HTTPBIS working group
    mailing list (ietf-http-wg@w3.org), which is archived at
    <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
 
    The current issues list is at
    <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
    documents (including fancy diffs) can be found at
    <http://tools.ietf.org/wg/httpbis/>.
 
    _This is a temporary document for the purpose of tracking the
    editorial changes made during the AUTH48 (RFC publication) phase._
 
 Status of This Memo

NEW:

 Status of This Memo


INTRODUCTION, paragraph 6:
OLD:

    This Internet-Draft is submitted in full conformance with the
    provisions of BCP 78 and BCP 79.
 
    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF).  Note that other groups may also distribute
    working documents as Internet-Drafts.  The list of current Internet-
    Drafts is at http://datatracker.ietf.org/drafts/current/.

NEW:

    This is an Internet Standards Track document.


INTRODUCTION, paragraph 7:
OLD:

    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."

NEW:

    This document is a product of the Internet Engineering Task Force
    (IETF).  It represents the consensus of the IETF community.  It has
    received public review and has been approved for publication by the
    Internet Engineering Steering Group (IESG).  Further information on
    Internet Standards is available in Section 2 of RFC 5741.


INTRODUCTION, paragraph 8:
OLD:

    This Internet-Draft will expire on November 7, 2014.

NEW:

    Information about the current status of this document, any errata,
    and how to provide feedback on it may be obtained at
    http://www.rfc-editor.org/info/rfc7230.


Section 11., paragraph 0:
OLD:

    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
      1.1.  Requirements Notation  . . . . . . . . . . . . . . . . . .  6
      1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  6
    2.  Architecture . . . . . . . . . . . . . . . . . . . . . . . . .  6
      2.1.  Client/Server Messaging  . . . . . . . . . . . . . . . . .  7
      2.2.  Implementation Diversity . . . . . . . . . . . . . . . . .  8
      2.3.  Intermediaries . . . . . . . . . . . . . . . . . . . . . .  9
      2.4.  Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 11
      2.5.  Conformance and Error Handling . . . . . . . . . . . . . . 12
      2.6.  Protocol Versioning  . . . . . . . . . . . . . . . . . . . 13
      2.7.  Uniform Resource Identifiers . . . . . . . . . . . . . . . 16
        2.7.1.  http URI Scheme  . . . . . . . . . . . . . . . . . . . 16
        2.7.2.  https URI Scheme . . . . . . . . . . . . . . . . . . . 18
        2.7.3.  http and https URI Normalization and Comparison  . . . 19
 
    3.  Message Format . . . . . . . . . . . . . . . . . . . . . . . . 19
      3.1.  Start Line . . . . . . . . . . . . . . . . . . . . . . . . 20
        3.1.1.  Request Line . . . . . . . . . . . . . . . . . . . . . 21
        3.1.2.  Status Line  . . . . . . . . . . . . . . . . . . . . . 22
      3.2.  Header Fields  . . . . . . . . . . . . . . . . . . . . . . 22
        3.2.1.  Field Extensibility  . . . . . . . . . . . . . . . . . 23
        3.2.2.  Field Order  . . . . . . . . . . . . . . . . . . . . . 23
        3.2.3.  Whitespace . . . . . . . . . . . . . . . . . . . . . . 24
        3.2.4.  Field Parsing  . . . . . . . . . . . . . . . . . . . . 25
        3.2.5.  Field Limits . . . . . . . . . . . . . . . . . . . . . 26
        3.2.6.  Field Value Components . . . . . . . . . . . . . . . . 26
      3.3.  Message Body . . . . . . . . . . . . . . . . . . . . . . . 27
        3.3.1.  Transfer-Encoding  . . . . . . . . . . . . . . . . . . 28
        3.3.2.  Content-Length . . . . . . . . . . . . . . . . . . . . 30
        3.3.3.  Message Body Length  . . . . . . . . . . . . . . . . . 31
      3.4.  Handling Incomplete Messages . . . . . . . . . . . . . . . 33
      3.5.  Message Parsing Robustness . . . . . . . . . . . . . . . . 34
    4.  Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 35
      4.1.  Chunked Transfer Coding  . . . . . . . . . . . . . . . . . 35
        4.1.1.  Chunk Extensions . . . . . . . . . . . . . . . . . . . 36
        4.1.2.  Chunked Trailer Part . . . . . . . . . . . . . . . . . 36
        4.1.3.  Decoding Chunked . . . . . . . . . . . . . . . . . . . 37
      4.2.  Compression Codings  . . . . . . . . . . . . . . . . . . . 38
        4.2.1.  Compress Coding  . . . . . . . . . . . . . . . . . . . 38
        4.2.2.  Deflate Coding . . . . . . . . . . . . . . . . . . . . 38
        4.2.3.  Gzip Coding  . . . . . . . . . . . . . . . . . . . . . 38
      4.3.  TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
      4.4.  Trailer  . . . . . . . . . . . . . . . . . . . . . . . . . 39
    5.  Message Routing  . . . . . . . . . . . . . . . . . . . . . . . 40
      5.1.  Identifying a Target Resource  . . . . . . . . . . . . . . 40
      5.2.  Connecting Inbound . . . . . . . . . . . . . . . . . . . . 40
      5.3.  Request Target . . . . . . . . . . . . . . . . . . . . . . 41
        5.3.1.  origin-form  . . . . . . . . . . . . . . . . . . . . . 41
        5.3.2.  absolute-form  . . . . . . . . . . . . . . . . . . . . 42
        5.3.3.  authority-form . . . . . . . . . . . . . . . . . . . . 42
        5.3.4.  asterisk-form  . . . . . . . . . . . . . . . . . . . . 42
      5.4.  Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
      5.5.  Effective Request URI  . . . . . . . . . . . . . . . . . . 44
      5.6.  Associating a Response to a Request  . . . . . . . . . . . 46
      5.7.  Message Forwarding . . . . . . . . . . . . . . . . . . . . 46
        5.7.1.  Via  . . . . . . . . . . . . . . . . . . . . . . . . . 47
        5.7.2.  Transformations  . . . . . . . . . . . . . . . . . . . 48
    6.  Connection Management  . . . . . . . . . . . . . . . . . . . . 49
      6.1.  Connection . . . . . . . . . . . . . . . . . . . . . . . . 50
      6.2.  Establishment  . . . . . . . . . . . . . . . . . . . . . . 51
      6.3.  Persistence  . . . . . . . . . . . . . . . . . . . . . . . 52
        6.3.1.  Retrying Requests  . . . . . . . . . . . . . . . . . . 53
        6.3.2.  Pipelining . . . . . . . . . . . . . . . . . . . . . . 53
 
      6.4.  Concurrency  . . . . . . . . . . . . . . . . . . . . . . . 54
      6.5.  Failures and Timeouts  . . . . . . . . . . . . . . . . . . 54
      6.6.  Tear-down  . . . . . . . . . . . . . . . . . . . . . . . . 55
      6.7.  Upgrade  . . . . . . . . . . . . . . . . . . . . . . . . . 56
    7.  ABNF List Extension: #rule . . . . . . . . . . . . . . . . . . 58
    8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 60
      8.1.  Header Field Registration  . . . . . . . . . . . . . . . . 60
      8.2.  URI Scheme Registration  . . . . . . . . . . . . . . . . . 60
      8.3.  Internet Media Type Registration . . . . . . . . . . . . . 61
        8.3.1.  Internet Media Type message/http . . . . . . . . . . . 61
        8.3.2.  Internet Media Type application/http . . . . . . . . . 62
      8.4.  Transfer Coding Registry . . . . . . . . . . . . . . . . . 63
        8.4.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 63
        8.4.2.  Registration . . . . . . . . . . . . . . . . . . . . . 64
      8.5.  Content Coding Registration  . . . . . . . . . . . . . . . 64
      8.6.  Upgrade Token Registry . . . . . . . . . . . . . . . . . . 65
        8.6.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 65
        8.6.2.  Upgrade Token Registration . . . . . . . . . . . . . . 66
    9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 66
      9.1.  Establishing Authority . . . . . . . . . . . . . . . . . . 66
      9.2.  Risks of Intermediaries  . . . . . . . . . . . . . . . . . 67
      9.3.  Attacks via Protocol Element Length  . . . . . . . . . . . 68
      9.4.  Response Splitting . . . . . . . . . . . . . . . . . . . . 68
      9.5.  Request Smuggling  . . . . . . . . . . . . . . . . . . . . 69
      9.6.  Message Integrity  . . . . . . . . . . . . . . . . . . . . 69
      9.7.  Message Confidentiality  . . . . . . . . . . . . . . . . . 70
      9.8.  Privacy of Server Log Information  . . . . . . . . . . . . 70
    10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 71
    11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72
      11.1. Normative References . . . . . . . . . . . . . . . . . . . 72
      11.2. Informative References . . . . . . . . . . . . . . . . . . 74
    Appendix A.  HTTP Version History  . . . . . . . . . . . . . . . . 76
      A.1.  Changes from HTTP/1.0  . . . . . . . . . . . . . . . . . . 77
        A.1.1.  Multi-homed Web Servers  . . . . . . . . . . . . . . . 77
        A.1.2.  Keep-Alive Connections . . . . . . . . . . . . . . . . 77
        A.1.3.  Introduction of Transfer-Encoding  . . . . . . . . . . 78
      A.2.  Changes from RFC 2616  . . . . . . . . . . . . . . . . . . 78
    Appendix B.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 80
    Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

NEW:

    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
      1.1.  Requirements Notation  . . . . . . . . . . . . . . . . . .  6
      1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  6
    2.  Architecture . . . . . . . . . . . . . . . . . . . . . . . . .  6
      2.1.  Client/Server Messaging  . . . . . . . . . . . . . . . . .  7
      2.2.  Implementation Diversity . . . . . . . . . . . . . . . . .  8
      2.3.  Intermediaries . . . . . . . . . . . . . . . . . . . . . .  9
      2.4.  Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 11
      2.5.  Conformance and Error Handling . . . . . . . . . . . . . . 12
      2.6.  Protocol Versioning  . . . . . . . . . . . . . . . . . . . 13
      2.7.  Uniform Resource Identifiers . . . . . . . . . . . . . . . 16
        2.7.1.  http URI Scheme  . . . . . . . . . . . . . . . . . . . 16
        2.7.2.  https URI Scheme . . . . . . . . . . . . . . . . . . . 18
        2.7.3.  http and https URI Normalization and Comparison  . . . 19
    3.  Message Format . . . . . . . . . . . . . . . . . . . . . . . . 19
      3.1.  Start Line . . . . . . . . . . . . . . . . . . . . . . . . 20
        3.1.1.  Request Line . . . . . . . . . . . . . . . . . . . . . 21
        3.1.2.  Status Line  . . . . . . . . . . . . . . . . . . . . . 22
      3.2.  Header Fields  . . . . . . . . . . . . . . . . . . . . . . 22
        3.2.1.  Field Extensibility  . . . . . . . . . . . . . . . . . 23
        3.2.2.  Field Order  . . . . . . . . . . . . . . . . . . . . . 23
        3.2.3.  Whitespace . . . . . . . . . . . . . . . . . . . . . . 24
        3.2.4.  Field Parsing  . . . . . . . . . . . . . . . . . . . . 25
        3.2.5.  Field Limits . . . . . . . . . . . . . . . . . . . . . 26
        3.2.6.  Field Value Components . . . . . . . . . . . . . . . . 26
      3.3.  Message Body . . . . . . . . . . . . . . . . . . . . . . . 27
        3.3.1.  Transfer-Encoding  . . . . . . . . . . . . . . . . . . 28
        3.3.2.  Content-Length . . . . . . . . . . . . . . . . . . . . 30
        3.3.3.  Message Body Length  . . . . . . . . . . . . . . . . . 31
      3.4.  Handling Incomplete Messages . . . . . . . . . . . . . . . 33
      3.5.  Message Parsing Robustness . . . . . . . . . . . . . . . . 34
    4.  Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 35
      4.1.  Chunked Transfer Coding  . . . . . . . . . . . . . . . . . 35
        4.1.1.  Chunk Extensions . . . . . . . . . . . . . . . . . . . 36
        4.1.2.  Chunked Trailer Part . . . . . . . . . . . . . . . . . 36
        4.1.3.  Decoding Chunked . . . . . . . . . . . . . . . . . . . 37
      4.2.  Compression Codings  . . . . . . . . . . . . . . . . . . . 38
        4.2.1.  Compress Coding  . . . . . . . . . . . . . . . . . . . 38
        4.2.2.  Deflate Coding . . . . . . . . . . . . . . . . . . . . 38
        4.2.3.  Gzip Coding  . . . . . . . . . . . . . . . . . . . . . 38
      4.3.  TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
      4.4.  Trailer  . . . . . . . . . . . . . . . . . . . . . . . . . 39
    5.  Message Routing  . . . . . . . . . . . . . . . . . . . . . . . 40
      5.1.  Identifying a Target Resource  . . . . . . . . . . . . . . 40
      5.2.  Connecting Inbound . . . . . . . . . . . . . . . . . . . . 40
      5.3.  Request Target . . . . . . . . . . . . . . . . . . . . . . 41
        5.3.1.  origin-form  . . . . . . . . . . . . . . . . . . . . . 41
        5.3.2.  absolute-form  . . . . . . . . . . . . . . . . . . . . 42
        5.3.3.  authority-form . . . . . . . . . . . . . . . . . . . . 42
        5.3.4.  asterisk-form  . . . . . . . . . . . . . . . . . . . . 42
      5.4.  Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
      5.5.  Effective Request URI  . . . . . . . . . . . . . . . . . . 44
      5.6.  Associating a Response to a Request  . . . . . . . . . . . 46
      5.7.  Message Forwarding . . . . . . . . . . . . . . . . . . . . 46
        5.7.1.  Via  . . . . . . . . . . . . . . . . . . . . . . . . . 47
        5.7.2.  Transformations  . . . . . . . . . . . . . . . . . . . 48
    6.  Connection Management  . . . . . . . . . . . . . . . . . . . . 49
      6.1.  Connection . . . . . . . . . . . . . . . . . . . . . . . . 50
      6.2.  Establishment  . . . . . . . . . . . . . . . . . . . . . . 51
      6.3.  Persistence  . . . . . . . . . . . . . . . . . . . . . . . 52
        6.3.1.  Retrying Requests  . . . . . . . . . . . . . . . . . . 53
        6.3.2.  Pipelining . . . . . . . . . . . . . . . . . . . . . . 53
      6.4.  Concurrency  . . . . . . . . . . . . . . . . . . . . . . . 54
      6.5.  Failures and Timeouts  . . . . . . . . . . . . . . . . . . 54
      6.6.  Teardown . . . . . . . . . . . . . . . . . . . . . . . . . 55
      6.7.  Upgrade  . . . . . . . . . . . . . . . . . . . . . . . . . 56
    7.  ABNF List Extension: #rule . . . . . . . . . . . . . . . . . . 58
    8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 60
      8.1.  Header Field Registration  . . . . . . . . . . . . . . . . 60
      8.2.  URI Scheme Registration  . . . . . . . . . . . . . . . . . 60
      8.3.  Internet Media Type Registration . . . . . . . . . . . . . 61
        8.3.1.  Internet Media Type message/http . . . . . . . . . . . 61
        8.3.2.  Internet Media Type application/http . . . . . . . . . 62
      8.4.  Transfer Coding Registry . . . . . . . . . . . . . . . . . 63
        8.4.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 63
        8.4.2.  Registration . . . . . . . . . . . . . . . . . . . . . 64
      8.5.  Content Coding Registration  . . . . . . . . . . . . . . . 64
      8.6.  Upgrade Token Registry . . . . . . . . . . . . . . . . . . 65
        8.6.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 65
        8.6.2.  Upgrade Token Registration . . . . . . . . . . . . . . 66
    9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 66
      9.1.  Establishing Authority . . . . . . . . . . . . . . . . . . 66
      9.2.  Risks of Intermediaries  . . . . . . . . . . . . . . . . . 67
      9.3.  Attacks via Protocol Element Length  . . . . . . . . . . . 68
      9.4.  Response Splitting . . . . . . . . . . . . . . . . . . . . 68
      9.5.  Request Smuggling  . . . . . . . . . . . . . . . . . . . . 69
      9.6.  Message Integrity  . . . . . . . . . . . . . . . . . . . . 69
      9.7.  Message Confidentiality  . . . . . . . . . . . . . . . . . 70
      9.8.  Privacy of Server Log Information  . . . . . . . . . . . . 70
    10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 71
    11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72
      11.1. Normative References . . . . . . . . . . . . . . . . . . . 72
      11.2. Informative References . . . . . . . . . . . . . . . . . . 74
    Appendix A.  HTTP Version History  . . . . . . . . . . . . . . . . 76
      A.1.  Changes from HTTP/1.0  . . . . . . . . . . . . . . . . . . 76
        A.1.1.  Multihomed Web Servers . . . . . . . . . . . . . . . . 77
        A.1.2.  Keep-Alive Connections . . . . . . . . . . . . . . . . 77
        A.1.3.  Introduction of Transfer-Encoding  . . . . . . . . . . 78
      A.2.  Changes from RFC 2616  . . . . . . . . . . . . . . . . . . 78
    Appendix B.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 80
    Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82


Section 1., paragraph 8:
OLD:

    This HTTP/1.1 specification obsoletes RFC 2616 and RFC 2145 (on HTTP
    versioning).  This specification also updates the use of CONNECT to
    establish a tunnel, previously defined in RFC 2817, and defines the
    "https" URI scheme that was described informally in RFC 2818.

NEW:

    This HTTP/1.1 specification obsoletes [RFC2616] and [RFC2145] (on
    HTTP versioning).  This specification also updates the use of
    CONNECT, previously defined in RFC 2817, to establish a tunnel, and
    defines the "https" URI scheme that was described informally in RFC
    2818.


Section 2.1., paragraph 1:
OLD:

    HTTP is a stateless request/response protocol that operates by
    exchanging messages (Section 3) across a reliable transport or
    session-layer "connection" (Section 6).  An HTTP "client" is a
    program that establishes a connection to a server for the purpose of
    sending one or more HTTP requests.  An HTTP "server" is a program
    that accepts connections in order to service HTTP requests by sending
    HTTP responses.

NEW:

    HTTP is a stateless request/response protocol that operates by
    exchanging messages (Section 3) across a reliable transport- or
    session-layer "connection" (Section 6).  An HTTP "client" is a
    program that establishes a connection to a server for the purpose of
    sending one or more HTTP requests.  An HTTP "server" is a program
    that accepts connections in order to service HTTP requests by sending
    HTTP responses.


Section 2.3., paragraph 7:
OLD:

    All HTTP requirements applicable to an origin server also apply to
    the outbound communication of a gateway.  A gateway communicates with
    inbound servers using any protocol that it desires, including private
    extensions to HTTP that are outside the scope of this specification.
    However, an HTTP-to-HTTP gateway that wishes to interoperate with
    third-party HTTP servers ought to conform to user agent requirements
    on the gateway's inbound connection.

NEW:

    All HTTP requirements applicable to an origin server also apply to
    the outbound communication of a gateway.  A gateway communicates with
    inbound servers using any protocol that it desires, including private
    extensions to HTTP that are outside the scope of this specification.
    However, an HTTP-to-HTTP gateway that wishes to interoperate with
    third-party HTTP servers ought to conform to user-agent requirements
    on the gateway's inbound connection.


Section 2.3., paragraph 11:
OLD:

    HTTP is defined as a stateless protocol, meaning that each request
    message can be understood in isolation.  Many implementations depend
    on HTTP's stateless design in order to reuse proxied connections or
    dynamically load-balance requests across multiple servers.  Hence, a
    server MUST NOT assume that two requests on the same connection are
    from the same user agent unless the connection is secured and
    specific to that agent.  Some non-standard HTTP extensions (e.g.,
    [RFC4559]) have been known to violate this requirement, resulting in
    security and interoperability problems.

NEW:

    HTTP is defined as a stateless protocol, meaning that each request
    message can be understood in isolation.  Many implementations depend
    on HTTP's stateless design in order to reuse proxied connections or
    dynamically load balance requests across multiple servers.  Hence, a
    server MUST NOT assume that two requests on the same connection are
    from the same user agent unless the connection is secured and
    specific to that agent.  Some non-standard HTTP extensions (e.g.,
    [RFC4559]) have been known to violate this requirement, resulting in
    security and interoperability problems.


Section 2.6., paragraph 2:
OLD:

    The version of an HTTP message is indicated by an HTTP-version field
    in the first line of the message.  HTTP-version is case-sensitive.

NEW:

    The version of an HTTP message is indicated by an HTTP-version field
    in the first line of the message.  HTTP-version is case sensitive.


Section 2.6., paragraph 3:
OLD:

      HTTP-version  = HTTP-name "/" DIGIT "." DIGIT
      HTTP-name     = %x48.54.54.50 ; "HTTP", case-sensitive

NEW:

      HTTP-version  = HTTP-name "/" DIGIT "." DIGIT
      HTTP-name     = %x48.54.54.50 ; "HTTP", case sensitive


Section 2.6., paragraph 7:
OLD:

    New header fields can be introduced without changing the protocol
    version if their defined semantics allow them to be safely ignored by
    recipients that do not recognize them.  Header field extensibility is
    discussed in Section 3.2.1.

NEW:

    New header fields can be introduced without changing the protocol
    version if their defined semantics allow them to be safely ignored by
    recipients that do not recognize them.  Header-field extensibility is
    discussed in Section 3.2.1.


Section 2.6., paragraph 14:
OLD:

    When an HTTP message is received with a major version number that the
    recipient implements, but a higher minor version number than what the
    recipient implements, the recipient SHOULD process the message as if
    it were in the highest minor version within that major version to
    which the recipient is conformant.  A recipient can assume that a
    message with a higher minor version, when sent to a recipient that
    has not yet indicated support for that higher version, is
    sufficiently backwards-compatible to be safely processed by any
    implementation of the same major version.

NEW:

    When an HTTP message is received with a major version number that the
    recipient implements, but a higher minor version number than what the
    recipient implements, the recipient SHOULD process the message as if
    it were in the highest minor version within that major version to
    which the recipient is conformant.  A recipient can assume that a
    message with a higher minor version, when sent to a recipient that
    has not yet indicated support for that higher version, is
    sufficiently backwards compatible to be safely processed by any
    implementation of the same major version.


Section 2.7., paragraph 2:
OLD:

    The definitions of "URI-reference", "absolute-URI", "relative-part",
    "scheme", "authority", "port", "host", "path-abempty", "segment",
    "query", and "fragment" are adopted from the URI generic syntax.  An
    "absolute-path" rule is defined for protocol elements that can
    contain a non-empty path component.  (This rule differs slightly from
    RFC 3986's path-abempty rule, which allows for an empty path to be
    used in references, and path-absolute rule, which does not allow
    paths that begin with "//".)  A "partial-URI" rule is defined for
    protocol elements that can contain a relative URI but not a fragment
    component.

NEW:

    The definitions of "URI-reference", "absolute-URI", "relative-part",
    "scheme", "authority", "port", "host", "path-abempty", "segment",
    "query", and "fragment" are adopted from the URI generic syntax.  An
    "absolute-path" rule is defined for protocol elements that can
    contain a non-empty path component.  (This rule differs slightly from
    the path-abempty rule of RFC 3986, which allows for an empty path to
    be used in references, and path-absolute rule, which does not allow
    paths that begin with "//".)  A "partial-URI" rule is defined for
    protocol elements that can contain a relative URI but not a fragment
    component.


Section 2.7.1., paragraph 1:
OLD:

    The "http" URI scheme is hereby defined for the purpose of minting
    identifiers according to their association with the hierarchical
    namespace governed by a potential HTTP origin server listening for
    TCP ([RFC0793]) connections on a given port.

NEW:

    The "http" URI scheme is hereby defined for the purpose of minting
    identifiers according to their association with the hierarchical
    namespace governed by a potential HTTP origin server listening for
    TCP ([RFC793]) connections on a given port.


Section 2.1, paragraph 0:
OLD:

    If the port is equal to the default port for a scheme, the normal
    form is to omit the port subcomponent.  When not being used in
    absolute form as the request target of an OPTIONS request, an empty
    path component is equivalent to an absolute path of "/", so the
    normal form is to provide a path of "/" instead.  The scheme and host
    are case-insensitive and normally provided in lowercase; all other
    components are compared in a case-sensitive manner.  Characters other
    than those in the "reserved" set are equivalent to their percent-
    encoded octets: the normal form is to not encode them (see Sections
    2.1 and 2.2 of [RFC3986]).

NEW:

    If the port is equal to the default port for a scheme, the normal
    form is to omit the port subcomponent.  When not being used in
    absolute form as the request target of an OPTIONS request, an empty
    path component is equivalent to an absolute path of "/", so the
    normal form is to provide a path of "/" instead.  The scheme and host
    are case insensitive and normally provided in lowercase; all other
    components are compared in a case-sensitive manner.  Characters other
    than those in the "reserved" set are equivalent to their percent-
    encoded octets: the normal form is to not encode them (see Sections
    2.1 and 2.2 of [RFC3986]).


Section 3.1., paragraph 2:
OLD:

    In theory, a client could receive requests and a server could receive
    responses, distinguishing them by their different start-line formats,
    but, in practice, servers are implemented to only expect a request (a
    response is interpreted as an unknown or invalid request method) and
    clients are implemented to only expect a response.

NEW:

    In theory, a client could receive requests and a server could receive
    responses, distinguishing them by their different start-line formats,
    but, in practice, servers are implemented only to expect a request (a
    response is interpreted as an unknown or invalid request method) and
    clients are implemented to only expect a response.


Section 3.1.1., paragraph 1:
OLD:

    A request-line begins with a method token, followed by a single space
    (SP), the request-target, another single space (SP), the protocol
    version, and ending with CRLF.

NEW:

    A request-line begins with a method token and is followed by a single
    space (SP), the request-target, another single space (SP), the
    protocol version, and ends with CRLF.


Section 3.1.1., paragraph 3:
OLD:

    The method token indicates the request method to be performed on the
    target resource.  The request method is case-sensitive.

NEW:

    The method token indicates the request method to be performed on the
    target resource.  The request method is case sensitive.


Section 3.1.2., paragraph 1:
OLD:

    The first line of a response message is the status-line, consisting
    of the protocol version, a space (SP), the status code, another
    space, a possibly empty textual phrase describing the status code,
    and ending with CRLF.

NEW:

    The first line of a response message is the status-line, consisting
    of the protocol version, a space (SP), the status code, another space
    (SP), a possibly empty textual phrase describing the status code,
    and, finally, CRLF.


Section 3.2.1., paragraph 4:
OLD:

    All defined header fields ought to be registered with IANA in the
    Message Header Field Registry, as described in Section 8.3 of
    [RFC7231].

NEW:

    All defined header fields ought to be registered with IANA in the
    "Message Headers" field registry, as described in Section 8.3 of
    [RFC7231].


Section 3.2.2., paragraph 4:
OLD:

       Note: In practice, the "Set-Cookie" header field ([RFC6265]) often
       appears multiple times in a response message and does not use the
       list syntax, violating the above requirements on multiple header
       fields with the same name.  Since it cannot be combined into a
       single field-value, recipients ought to handle "Set-Cookie" as a
       special case while processing header fields.  (See Appendix A.2.3
       of [Kri2001] for details.)

NEW:

       Note: In practice, the "Set-Cookie" header field ([RFC6265]) often
       appears multiple times in a response message and does not use the
       list syntax, violating the above requirements on multiple header
       fields with the same name.  Since it cannot be combined into a
       single field-value, recipients ought to handle Set-Cookie as a
       special case while processing header fields.  (See Appendix A.2.3
       of [Kri2001] for details.)


Section 3.2.3., paragraph 2:
OLD:

    The OWS rule is used where zero or more linear whitespace octets
    might appear.  For protocol elements where optional whitespace is
    preferred to improve readability, a sender SHOULD generate the
    optional whitespace as a single SP; otherwise, a sender SHOULD NOT
    generate optional whitespace except as needed to white-out invalid or
    unwanted protocol elements during in-place message filtering.

NEW:

    The OWS rule is used where zero or more linear whitespace octets
    might appear.  For protocol elements where optional whitespace is
    preferred to improve readability, a sender SHOULD generate the
    optional whitespace as a single SP; otherwise, a sender SHOULD NOT
    generate optional whitespace except as needed to white out invalid or
    unwanted protocol elements during in-place message filtering.


Section 3.2.4., paragraph 1:
OLD:

    Messages are parsed using a generic algorithm, independent of the
    individual header field names.  The contents within a given field
    value are not parsed until a later stage of message interpretation
    (usually after the message's entire header section has been
    processed).  Consequently, this specification does not use ABNF rules
    to define each "Field-Name: Field Value" pair, as was done in
    previous editions.  Instead, this specification uses ABNF rules that
    are named according to each registered field name, wherein the rule
    defines the valid grammar for that field's corresponding field values
    (i.e., after the field-value has been extracted from the header
    section by a generic field parser).

NEW:

    Messages are parsed using a generic algorithm, independent of the
    individual header field names.  The contents within a given field
    value are not parsed until a later stage of message interpretation
    (usually after the message's entire header section has been
    processed).  Consequently, this specification does not use ABNF rules
    to define each "field-name: field-value" pair, as was done in
    previous editions.  Instead, this specification uses ABNF rules that
    are named according to each registered field name, wherein the rule
    defines the valid grammar for that field's corresponding field values
    (i.e., after the field-value has been extracted from the header
    section by a generic field parser).


Section 3.2.4., paragraph 8:
OLD:

    Historically, HTTP has allowed field content with text in the ISO-
    8859-1 [ISO-8859-1] charset, supporting other charsets only through
    use of [RFC2047] encoding.  In practice, most HTTP header field
    values use only a subset of the US-ASCII charset [USASCII].  Newly
    defined header fields SHOULD limit their field values to US-ASCII
    octets.  A recipient SHOULD treat other octets in field content (obs-
    text) as opaque data.

NEW:

    Historically, HTTP has allowed field content with text in the
    ISO-8859-1 [ISO-8859-1] charset, supporting other charsets only
    through use of [RFC2047] encoding.  In practice, most HTTP header
    field values use only a subset of the US-ASCII charset [USASCII].
    Newly defined header fields SHOULD limit their field values to
    US-ASCII octets.  A recipient SHOULD treat other octets in field
    content (obs-text) as opaque data.


Section 7., paragraph 1:
OLD:

    Since there is no way to distinguish a successfully completed, close-
    delimited message from a partially-received message interrupted by
    network failure, a server SHOULD generate encoding or length-
    delimited messages whenever possible.  The close-delimiting feature
    exists primarily for backwards compatibility with HTTP/1.0.

NEW:

    Since there is no way to distinguish a successfully completed, close-
    delimited message from a partially received message interrupted by
    network failure, a server SHOULD generate encoding or length-
    delimited messages whenever possible.  The close-delimiting feature
    exists primarily for backwards compatibility with HTTP/1.0.


Section 4., paragraph 5:
OLD:

    All transfer-coding names are case-insensitive and ought to be
    registered within the HTTP Transfer Coding registry, as defined in
    Section 8.4.  They are used in the TE (Section 4.3) and Transfer-
    Encoding (Section 3.3.1) header fields.

NEW:

    All transfer-coding names are case insensitive and ought to be
    registered within the "HTTP Transfer Coding" registry, as defined in
    Section 8.4.  They are used in the TE (Section 4.3) and Transfer-
    Encoding (Section 3.3.1) header fields.


Section 4.2.3., paragraph 1:
OLD:

    The "gzip" coding is an LZ77 coding with a 32 bit CRC that is
    commonly produced by the gzip file compression program [RFC1952].  A
    recipient SHOULD consider "x-gzip" to be equivalent to "gzip".

NEW:

    The "gzip" coding is an LZ77 coding with a 32-bit Cyclic Redundancy
    Check (CRC) that is commonly produced by the gzip file compression
    program [RFC1952].  A recipient SHOULD consider "x-gzip" to be
    equivalent to "gzip".


Section 5.7.2., paragraph 6:
OLD:

    A proxy MUST NOT transform the payload (Section 3.3 of [RFC7231]) of
    a message that contains a no-transform cache-control directive
    (Section 5.2 of [RFC7234]).

NEW:

    A proxy MUST NOT transform the payload (Section 3.3 of [RFC7231]) of
    a message that contains a no-transform Cache-Control directive
    (Section 5.2 of [RFC7234]).


Section 200, paragraph 0:
OLD:

    A proxy MAY transform the payload of a message that does not contain
    a no-transform cache-control directive.  A proxy that transforms a
    payload MUST add a Warning header field with the warn-code of 214
    ("Transformation Applied") if one is not already in the message (see
    Section 5.5 of [RFC7234]).  A proxy that transforms the payload of a
    200 (OK) response can further inform downstream recipients that a
    transformation has been applied by changing the response status code
    to 203 (Non-Authoritative Information) (Section 6.3.4 of [RFC7231]).

NEW:

    A proxy MAY transform the payload of a message that does not contain
    a no-transform Cache-Control directive.  A proxy that transforms a
    payload MUST add a Warning header field with the warn-code of 214
    ("Transformation Applied") if one is not already in the message (see
    Section 5.5 of [RFC7234]).  A proxy that transforms the payload of a
    200 (OK) response can further inform downstream recipients that a
    transformation has been applied by changing the response status code
    to 203 (Non-Authoritative Information) (Section 6.3.4 of [RFC7231]).


Section 6., paragraph 1:
OLD:

    HTTP messaging is independent of the underlying transport or session-
    layer connection protocol(s).  HTTP only presumes a reliable
    transport with in-order delivery of requests and the corresponding
    in-order delivery of responses.  The mapping of HTTP request and
    response structures onto the data units of an underlying transport
    protocol is outside the scope of this specification.

NEW:

    HTTP messaging is independent of the underlying transport- or
    session-layer connection protocol(s).  HTTP only presumes a reliable
    transport with in-order delivery of requests and the corresponding
    in-order delivery of responses.  The mapping of HTTP request and
    response structures onto the data units of an underlying transport
    protocol is outside the scope of this specification.


Section 6.1., paragraph 6:
OLD:

    Connection options are case-insensitive.

NEW:

    Connection options are case insensitive.


Section 6.2., paragraph 1:
OLD:

    It is beyond the scope of this specification to describe how
    connections are established via various transport or session-layer
    protocols.  Each connection applies to only one transport link.

NEW:

    It is beyond the scope of this specification to describe how
    connections are established via various transport- or session-layer
    protocols.  Each connection applies to only one transport link.


Section 6.3., paragraph 1:
OLD:

    HTTP/1.1 defaults to the use of "persistent connections", allowing
    multiple requests and responses to be carried over a single
    connection.  The "close" connection-option is used to signal that a
    connection will not persist after the current request/response.  HTTP
    implementations SHOULD support persistent connections.

NEW:

    HTTP/1.1 defaults to the use of "persistent connections", allowing
    multiple requests and responses to be carried over a single
    connection.  The "close" connection option is used to signal that a
    connection will not persist after the current request/response.  HTTP
    implementations SHOULD support persistent connections.


Section 6.3., paragraph 3:
OLD:

    o  If the close connection option is present, the connection will not
       persist after the current response; else,

NEW:

    o  If the "close" connection option is present, the connection will
       not persist after the current response; else,


Section 6.3., paragraph 7:
OLD:

    A client MAY send additional requests on a persistent connection
    until it sends or receives a close connection option or receives an
    HTTP/1.0 response without a "keep-alive" connection option.

NEW:

    A client MAY send additional requests on a persistent connection
    until it sends or receives a "close" connection option or receives an
    HTTP/1.0 response without a "keep-alive" connection option.


Section 6.5., paragraph 4:
OLD:

    A server SHOULD sustain persistent connections, when possible, and
    allow the underlying transport's flow control mechanisms to resolve
    temporary overloads, rather than terminate connections with the
    expectation that clients will retry.  The latter technique can
    exacerbate network congestion.

NEW:

    A server SHOULD sustain persistent connections, when possible, and
    allow the underlying transport's flow-control mechanisms to resolve
    temporary overloads, rather than terminate connections with the
    expectation that clients will retry.  The latter technique can
    exacerbate network congestion.


Section 6.5., paragraph 6:
OLD:

 6.6.  Tear-down

NEW:

 6.6.  Teardown


Section 6.5., paragraph 8:
OLD:

    A client that sends a close connection option MUST NOT send further
    requests on that connection (after the one containing close) and MUST
    close the connection after reading the final response message
    corresponding to this request.

NEW:

    A client that sends a "close" connection option MUST NOT send further
    requests on that connection (after the one containing close) and MUST
    close the connection after reading the final response message
    corresponding to this request.


Section 6.5., paragraph 9:
OLD:

    A server that receives a close connection option MUST initiate a
    close of the connection (see below) after it sends the final response
    to the request that contained close.  The server SHOULD send a close
    connection option in its final response on that connection.  The
    server MUST NOT process any further requests received on that
    connection.

NEW:

    A server that receives a "close" connection option MUST initiate a
    close of the connection (see below) after it sends the final response
    to the request that contained close.  The server SHOULD send a close
    connection option in its final response on that connection.  The
    server MUST NOT process any further requests received on that
    connection.


Section 6.5., paragraph 10:
OLD:

    A server that sends a close connection option MUST initiate a close
    of the connection (see below) after it sends the response containing
    close.  The server MUST NOT process any further requests received on
    that connection.

NEW:

    A server that sends a "close" connection option MUST initiate a close
    of the connection (see below) after it sends the response containing
    close.  The server MUST NOT process any further requests received on
    that connection.


Section 6.5., paragraph 11:
OLD:

    A client that receives a close connection option MUST cease sending
    requests on that connection and close the connection after reading
    the response message containing the close; if additional pipelined
    requests had been sent on the connection, the client SHOULD NOT
    assume that they will be processed by the server.

NEW:

    A client that receives a "close" connection option MUST cease sending
    requests on that connection and close the connection after reading
    the response message containing the close; if additional pipelined
    requests had been sent on the connection, the client SHOULD NOT
    assume that they will be processed by the server.


Section 6.5., paragraph 12:
OLD:

    If a server performs an immediate close of a TCP connection, there is
    a significant risk that the client will not be able to read the last
    HTTP response.  If the server receives additional data from the
    client on a fully-closed connection, such as another request that was
    sent by the client before receiving the server's response, the
    server's TCP stack will send a reset packet to the client;
    unfortunately, the reset packet might erase the client's
    unacknowledged input buffers before they can be read and interpreted
    by the client's HTTP parser.

NEW:

    If a server performs an immediate close of a TCP connection, there is
    a significant risk that the client will not be able to read the last
    HTTP response.  If the server receives additional data from the
    client on a fully closed connection, such as another request that was
    sent by the client before receiving the server's response, the
    server's TCP stack will send a reset packet to the client;
    unfortunately, the reset packet might erase the client's
    unacknowledged input buffers before they can be read and interpreted
    by the client's HTTP parser.


Section 6.7., paragraph 9:
OLD:

    The capabilities and nature of the application-level communication
    after the protocol change is entirely dependent upon the new
    protocol(s) chosen.  However, immediately after sending the 101
    response, the server is expected to continue responding to the
    original request as if it had received its equivalent within the new
    protocol (i.e., the server still has an outstanding request to
    satisfy after the protocol has been changed, and is expected to do so
    without requiring the request to be repeated).

NEW:

    The capabilities and nature of the application-level communication
    after the protocol change is entirely dependent upon the new
    protocol(s) chosen.  However, immediately after sending the 101
    (Switching Protocols) response, the server is expected to continue
    responding to the original request as if it had received its
    equivalent within the new protocol (i.e., the server still has an
    outstanding request to satisfy after the protocol has been changed,
    and is expected to do so without requiring the request to be
    repeated).


Section 7., paragraph 14:
OLD:

    Then the following are valid values for example-list (not including
    the double quotes, which are present for delimitation only):

NEW:

    Then, the following are valid values for example-list (not including
    the double quotes, which are present for delimitation only):


Section 8.1., paragraph 1:
OLD:

    HTTP header fields are registered within the Message Header Field
    Registry maintained at
    <http://www.iana.org/assignments/message-headers/>.

NEW:

    HTTP header fields are registered within the "Message Header" field
    registry maintained at
    <http://www.iana.org/assignments/message-headers/>.


Section 8.1., paragraph 2:
OLD:

    This document defines the following HTTP header fields, so their
    associated registry entries shall be updated according to the
    permanent registrations below (see [BCP90]):

NEW:

    This document defines the following HTTP header fields, so the
    "Permanent Message Header Field Names" registry has been updated
    accordingly (see [BCP90]).


Section 8.1., paragraph 4:
OLD:

    Furthermore, the header field-name "Close" shall be registered as
    "reserved", since using that name as an HTTP header field might
    conflict with the "close" connection option of the "Connection"
    header field (Section 6.1).

NEW:

    Furthermore, the header field-name "Close" has been registered as
    "reserved", since using that name as an HTTP header field might
    conflict with the "close" connection option of the "Connection"
    header field (Section 6.1).


Section 8.2., paragraph 2:
OLD:

    This document defines the following URI schemes, so their associated
    registry entries shall be updated according to the permanent
    registrations below:

NEW:

    This document defines the following URI schemes, so the "Permanent
    URI Schemes" registry has been updated accordingly.


Section 8.3., paragraph 2:
OLD:

    This document serves as the specification for the Internet media
    types "message/http" and "application/http".  The following is to be
    registered with IANA.

NEW:

    This document serves as the specification for the Internet media
    types "message/http" and "application/http".  The following has been
    registered with IANA.


Section 8.3.1., paragraph 18:
OLD:

    Person and email address to contact for further information:  See
       Authors' Addresses Section.

NEW:

    Person and email address to contact for further information:
       See Authors' Addresses  Section.


Section 8.3.2., paragraph 8:
OLD:

    Encoding considerations:  HTTP messages enclosed by this type are in
       "binary" format; use of an appropriate Content-Transfer-Encoding
       is required when transmitted via E-mail.

NEW:

    Encoding considerations:  HTTP messages enclosed by this type are in
       "binary" format; use of an appropriate Content-Transfer-Encoding
       is required when transmitted via email.


Section 8.3.2., paragraph 19:
OLD:

    Person and email address to contact for further information:  See
       Authors' Addresses Section.

NEW:

    Person and email address to contact for further information:
       See Authors' Addresses Section.


Section 8.4., paragraph 1:
OLD:

    The HTTP Transfer Coding Registry defines the name space for transfer
    coding names.  It is maintained at
    <http://www.iana.org/assignments/http-parameters>.

NEW:

    The "HTTP Transfer Coding" registry defines the namespace for
    transfer coding names.  It is maintained at
    <http://www.iana.org/assignments/http-parameters>.


Section 8.4.1., paragraph 5:
OLD:

    Values to be added to this name space require IETF Review (see
    Section 4.1 of [RFC5226]), and MUST conform to the purpose of
    transfer coding defined in this specification.

NEW:

    Values to be added to this namespace require IETF Review (see Section
    4.1 of [RFC5226]), and MUST conform to the purpose of transfer coding
    defined in this specification.


Section 8.4.2., paragraph 1:
OLD:

    The HTTP Transfer Coding Registry shall be updated with the
    registrations below:

NEW:

    The "HTTP Transfer Coding Registry" has been updated with the
    registrations below:


Section 8.5., paragraph 1:
OLD:

    IANA maintains the registry of HTTP Content Codings at
    <http://www.iana.org/assignments/http-parameters>.

NEW:

    IANA maintains the "HTTP Content Coding Registry" at
    <http://www.iana.org/assignments/http-parameters>.


Section 8.5., paragraph 2:
OLD:

    The HTTP Content Codings Registry shall be updated with the
    registrations below:

NEW:

    The "HTTP Content Codings Registry" has been updated with the
    registrations below:


Section 8.6., paragraph 1:
OLD:

    The HTTP Upgrade Token Registry defines the name space for protocol-
    name tokens used to identify protocols in the Upgrade header field.
    The registry is maintained at
    <http://www.iana.org/assignments/http-upgrade-tokens>.

NEW:

    The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry"
    defines the namespace for protocol-name tokens used to identify
    protocols in the Upgrade header field.  The registry is maintained at
    <http://www.iana.org/assignments/http-upgrade-tokens>.


Section 8.6.2., paragraph 1:
OLD:

    The "HTTP" entry in the HTTP Upgrade Token Registry shall be updated
    with the registration below:

NEW:

    The "HTTP" entry in the "HTTP Upgrade Token" registry shall be
    updated with the registration below:


Section 9.1., paragraph 3:
OLD:

    When a registered name is used in the authority component, the "http"
    URI scheme (Section 2.7.1) relies on the user's local name resolution
    service to determine where it can find authoritative responses.  This
    means that any attack on a user's network host table, cached names,
    or name resolution libraries becomes an avenue for attack on
    establishing authority.  Likewise, the user's choice of server for
    Domain Name Service (DNS), and the hierarchy of servers from which it
    obtains resolution results, could impact the authenticity of address
    mappings; DNSSEC ([RFC4033]) is one way to improve authenticity.

NEW:

    When a registered name is used in the authority component, the "http"
    URI scheme (Section 2.7.1) relies on the user's local name resolution
    service to determine where it can find authoritative responses.  This
    means that any attack on a user's network host table, cached names,
    or name resolution libraries becomes an avenue for attack on
    establishing authority.  Likewise, the user's choice of server for
    Domain Name Service (DNS), and the hierarchy of servers from which it
    obtains resolution results, could impact the authenticity of address
    mappings; DNS Security Extensions (DNSSEC) ([RFC4033]) is one way to
    improve authenticity.


Section 9.2., paragraph 1:
OLD:

    By their very nature, HTTP intermediaries are men-in-the-middle, and
    thus represent an opportunity for man-in-the-middle attacks.
    Compromise of the systems on which the intermediaries run can result
    in serious security and privacy problems.  Intermediaries might have
    access to security-related information, personal information about
    individual users and organizations, and proprietary information
    belonging to users and content providers.  A compromised
    intermediary, or an intermediary implemented or configured without
    regard to security and privacy considerations, might be used in the
    commission of a wide range of potential attacks.

NEW:

    By their very nature, HTTP intermediaries are men in the middle and,
    thus, represent an opportunity for man-in-the-middle attacks.
    Compromise of the systems on which the intermediaries run can result
    in serious security and privacy problems.  Intermediaries might have
    access to security-related information, personal information about
    individual users and organizations, and proprietary information
    belonging to users and content providers.  A compromised
    intermediary, or an intermediary implemented or configured without
    regard to security and privacy considerations, might be used in the
    commission of a wide range of potential attacks.


Section 9.6., paragraph 2:
OLD:

    User agents are encouraged to implement configurable means for
    detecting and reporting failures of message integrity such that those
    means can be enabled within environments for which integrity is
    necessary.  For example, a browser being used to view medical history
    or drug interaction information needs to indicate to the user when
    such information is detected by the protocol to be incomplete,
    expired, or corrupted during transfer.  Such mechanisms might be
    selectively enabled via user agent extensions or the presence of
    message integrity metadata in a response.  At a minimum, user agents
    ought to provide some indication that allows a user to distinguish
    between a complete and incomplete response message (Section 3.4) when
    such verification is desired.

NEW:

    User agents are encouraged to implement configurable means for
    detecting and reporting failures of message integrity such that those
    means can be enabled within environments for which integrity is
    necessary.  For example, a browser being used to view medical history
    or drug interaction information needs to indicate to the user when
    such information is detected by the protocol to be incomplete,
    expired, or corrupted during transfer.  Such mechanisms might be
    selectively enabled via user-agent extensions or the presence of
    message integrity metadata in a response.  At a minimum, user agents
    ought to provide some indication that allows a user to distinguish
    between a complete and incomplete response message (Section 3.4) when
    such verification is desired.


Section 11.1., paragraph 1:
OLD:

    [RFC0793]     Postel, J., "Transmission Control Protocol", STD 7,
                  RFC 793, September 1981.
 
    [RFC1950]     Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
                  Format Specification version 3.3", RFC 1950, May 1996.

NEW:

    [RFC1950]     Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
                  Format Specification version 3.3", RFC 1950, May 1996.


Section 11.1., paragraph 7:
OLD:

    [RFC7231]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
                  Transfer Protocol (HTTP/1.1): Semantics and Content",
                  draft-ietf-httpbis-p2-semantics-latest (work in
                  progress), May 2014.

NEW:

    [RFC7231]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
                  Transfer Protocol (HTTP/1.1): Semantics and Content",
                  RFC 7231, May 2014.


Section 11.1., paragraph 8:
OLD:

    [RFC7232]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
                  Transfer Protocol (HTTP/1.1): Conditional Requests",
                  draft-ietf-httpbis-p4-conditional-latest (work in
                  progress), May 2014.

NEW:

    [RFC7232]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
                  Transfer Protocol (HTTP/1.1): Conditional Requests",
                  RFC 7232, May 2014.


Section 11.1., paragraph 9:
OLD:

    [RFC7233]     Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
                  "Hypertext Transfer Protocol (HTTP/1.1): Range
                  Requests", draft-ietf-httpbis-p5-range-latest (work in
                  progress), May 2014.

NEW:

    [RFC7233]     Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
                  "Hypertext Transfer Protocol (HTTP/1.1): Range
                  Requests", RFC 7233, May 2014.


Section 11.1., paragraph 10:
OLD:

    [RFC7234]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
                  Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
                  draft-ietf-httpbis-p6-cache-latest (work in progress),
                  May 2014.

NEW:

    [RFC7234]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
                  Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
                  RFC 7234, May 2014.


Section 11.1., paragraph 11:
OLD:

    [RFC7235]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
                  Transfer Protocol (HTTP/1.1): Authentication",
                  draft-ietf-httpbis-p7-auth-latest (work in progress),
                  May 2014.

NEW:

    [RFC7235]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
                  Transfer Protocol (HTTP/1.1): Authentication",
                  RFC 7235, May 2014.
 
    [RFC793]      Postel, J., "Transmission Control Protocol", STD 7,
                  RFC 793, September 1981.


Section 11.1., paragraph 13:
OLD:

    [Welch]       Welch, T., "A Technique for High Performance Data
                  Compression", IEEE Computer 17(6), June 1984.

NEW:

    [Welch]       Welch, T., "A Technique for High-Performance Data
                  Compression", IEEE Computer 17(6), June 1984.


Appendix A., paragraph 1:
OLD:

    HTTP has been in use since 1990.  The first version, later referred
    to as HTTP/0.9, was a simple protocol for hypertext data transfer
    across the Internet, using only a single request method (GET) and no
    metadata.  HTTP/1.0, as defined by [RFC1945], added a range of
    request methods and MIME-like messaging, allowing for metadata to be
    transferred and modifiers placed on the request/response semantics.
    However, HTTP/1.0 did not sufficiently take into consideration the
    effects of hierarchical proxies, caching, the need for persistent
    connections, or name-based virtual hosts.  The proliferation of
    incompletely-implemented applications calling themselves "HTTP/1.0"
    further necessitated a protocol version change in order for two
    communicating applications to determine each other's true
    capabilities.

NEW:

    HTTP has been in use since 1990.  The first version, later referred
    to as HTTP/0.9, was a simple protocol for hypertext data transfer
    across the Internet, using only a single request method (GET) and no
    metadata.  HTTP/1.0, as defined by [RFC1945], added a range of
    request methods and MIME-like messaging, allowing for metadata to be
    transferred and modifiers placed on the request/response semantics.
    However, HTTP/1.0 did not sufficiently take into consideration the
    effects of hierarchical proxies, caching, the need for persistent
    connections, or name-based virtual hosts.  The proliferation of
    incompletely implemented applications calling themselves "HTTP/1.0"
    further necessitated a protocol version change in order for two
    communicating applications to determine each other's true
    capabilities.


Appendix A., paragraph 7:
OLD:

 A.1.1.  Multi-homed Web Servers

NEW:

 A.1.1.  Multihomed Web Servers


Section 19.7.1, paragraph 8:
OLD:

    HTTP's approach to error handling has been explained.  (Section 2.5)

NEW:

    HTTP's approach to error handling has been explained (Section 2.5).


Section 19.7.1, paragraph 9:
OLD:

    The HTTP-version ABNF production has been clarified to be case-
    sensitive.  Additionally, version numbers have been restricted to
    single digits, due to the fact that implementations are known to
    handle multi-digit version numbers incorrectly.  (Section 2.6)

NEW:

    The HTTP-version ABNF production has been clarified to be case
    sensitive.  Additionally, version numbers have been restricted to
    single digits, due to the fact that implementations are known to
    handle multi-digit version numbers incorrectly (Section 2.6).


Section 19.7.1, paragraph 10:
OLD:

    Userinfo (i.e., username and password) are now disallowed in HTTP and
    HTTPS URIs, because of security issues related to their transmission
    on the wire.  (Section 2.7.1)

NEW:

    Userinfo (i.e., username and password) are now disallowed in HTTP and
    HTTPS URIs, because of security issues related to their transmission
    on the wire (Section 2.7.1).


Section 19.7.1, paragraph 11:
OLD:

    The HTTPS URI scheme is now defined by this specification;
    previously, it was done in Section 2.4 of [RFC2818].  Furthermore, it
    implies end-to-end security.  (Section 2.7.2)

NEW:

    The HTTPS URI scheme is now defined by this specification;
    previously, it was defined in Section 2.4 of [RFC2818].  Furthermore,
    it implies end-to-end security (Section 2.7.2).


Section 19.7.1, paragraph 12:
OLD:

    HTTP messages can be (and often are) buffered by implementations;
    despite it sometimes being available as a stream, HTTP is
    fundamentally a message-oriented protocol.  Minimum supported sizes
    for various protocol elements have been suggested, to improve
    interoperability.  (Section 3)

NEW:

    HTTP messages can be (and often are) buffered by implementations;
    despite it sometimes being available as a stream, HTTP is
    fundamentally a message-oriented protocol.  Minimum supported sizes
    for various protocol elements have been suggested, to improve
    interoperability (Section 3).


Section 19.7.1, paragraph 13:
OLD:

    Invalid whitespace around field-names is now required to be rejected,
    because accepting it represents a security vulnerability.  The ABNF
    productions defining header fields now only list the field value.
    (Section 3.2)

NEW:

    Invalid whitespace around field-names is now required to be rejected,
    because accepting it represents a security vulnerability.  The ABNF
    productions defining header fields now only list the field value
    (Section 3.2).


Section 19.7.1, paragraph 14:
OLD:

    Rules about implicit linear whitespace between certain grammar
    productions have been removed; now whitespace is only allowed where
    specifically defined in the ABNF.  (Section 3.2.3)

NEW:

    Rules about implicit linear whitespace between certain grammar
    productions have been removed; now whitespace is only allowed where
    specifically defined in the ABNF (Section 3.2.3).


Section 19.7.1, paragraph 15:
OLD:

    Header fields that span multiple lines ("line folding") are
    deprecated.  (Section 3.2.4)
    The NUL octet is no longer allowed in comment and quoted-string text,
    and handling of backslash-escaping in them has been clarified.  The
    quoted-pair rule no longer allows escaping control characters other
    than HTAB.  Non-ASCII content in header fields and the reason phrase
    has been obsoleted and made opaque (the TEXT rule was removed).
    (Section 3.2.6)

NEW:

    Header fields that span multiple lines ("line folding") are
    deprecated (Section 3.2.4).
 
    The NUL octet is no longer allowed in comment and quoted-string text,
    and handling of backslash-escaping in them has been clarified.  The
    quoted-pair rule no longer allows escaping control characters other
    than HTAB.  Non-US-ASCII content in header fields and the reason
    phrase has been obsoleted and made opaque (the TEXT rule was removed)
    (Section 3.2.6).


Section 19.7.1, paragraph 16:
OLD:

    Bogus "Content-Length" header fields are now required to be handled
    as errors by recipients.  (Section 3.3.2)

NEW:

    Bogus "Content-Length" header fields are now required to be handled
    as errors by recipients (Section 3.3.2).


Section 19.7.1, paragraph 17:
OLD:

    The algorithm for determining the message body length has been
    clarified to indicate all of the special cases (e.g., driven by
    methods or status codes) that affect it, and that new protocol
    elements cannot define such special cases.  CONNECT is a new, special
    case in determining message body length. "multipart/byteranges" is no
    longer a way of determining message body length detection.
    (Section 3.3.3)

NEW:

    The algorithm for determining the message body length has been
    clarified to indicate all of the special cases (e.g., driven by
    methods or status codes) that affect it, and that new protocol
    elements cannot define such special cases.  CONNECT is a new, special
    case in determining message body length. "multipart/byteranges" is no
    longer a way of determining message body length detection
    (Section 3.3.3).


Section 19.7.1, paragraph 18:
OLD:

    The "identity" transfer coding token has been removed.  (Sections 3.3
    and 4)

NEW:

    The "identity" transfer coding token has been removed (Sections 3.3
    and 4).


Section 19.7.1, paragraph 19:
OLD:

    Chunk length does not include the count of the octets in the chunk
    header and trailer.  Line folding in chunk extensions is disallowed.
    (Section 4.1)

NEW:

    Chunk length does not include the count of the octets in the chunk
    header and trailer.  Line folding in chunk extensions is disallowed
    (Section 4.1).


Section 19.7.1, paragraph 20:
OLD:

    The meaning of the "deflate" content coding has been clarified.
    (Section 4.2.2)

NEW:

    The meaning of the "deflate" content coding has been clarified
    (Section 4.2.2).


Section 19.7.1, paragraph 21:
OLD:

    The segment + query components of RFC 3986 have been used to define
    the request-target, instead of abs_path from RFC 1808.  The asterisk-
    form of the request-target is only allowed with the OPTIONS method.
    (Section 5.3)

NEW:

    The segment + query components of RFC 3986 have been used to define
    the request-target, instead of abs_path from RFC 1808.  The asterisk-
    form of the request-target is only allowed with the OPTIONS method
    (Section 5.3).


Section 19.7.1, paragraph 22:
OLD:

    The term "Effective Request URI" has been introduced.  (Section 5.5)

NEW:

    The term "Effective Request URI" has been introduced (Section 5.5).


Section 19.7.1, paragraph 23:
OLD:

    Gateways do not need to generate Via header fields anymore.
    (Section 5.7.1)

NEW:

    Gateways do not need to generate Via header fields anymore
    (Section 5.7.1).


Section 19.7.1, paragraph 24:
OLD:

    Exactly when "close" connection options have to be sent has been
    clarified.  Also, "hop-by-hop" header fields are required to appear
    in the Connection header field; just because they're defined as hop-
    by-hop in this specification doesn't exempt them.  (Section 6.1)

NEW:

    Exactly when "close" connection options have to be sent has been
    clarified.  Also, "hop-by-hop" header fields are required to appear
    in the Connection header field; just because they're defined as hop-
    by-hop in this specification doesn't exempt them (Section 6.1).


Section 19.7.1, paragraph 25:
OLD:

    The limit of two connections per server has been removed.  An
    idempotent sequence of requests is no longer required to be retried.
    The requirement to retry requests under certain circumstances when
    the server prematurely closes the connection has been removed.  Also,
    some extraneous requirements about when servers are allowed to close
    connections prematurely have been removed.  (Section 6.3)

NEW:

    The limit of two connections per server has been removed.  An
    idempotent sequence of requests is no longer required to be retried.
    The requirement to retry requests under certain circumstances when
    the server prematurely closes the connection has been removed.  Also,
    some extraneous requirements about when servers are allowed to close
    connections prematurely have been removed (Section 6.3).


Section 19.7.1, paragraph 26:
OLD:

    The semantics of the Upgrade header field is now defined in responses
    other than 101 (this was incorporated from [RFC2817]).  Furthermore,
    the ordering in the field value is now significant.  (Section 6.7)

NEW:

    The semantics of the Upgrade header field is now defined in responses
    other than 101 (this was incorporated from [RFC2817]).  Furthermore,
    the ordering in the field value is now significant (Section 6.7).


Section 19.7.1, paragraph 27:
OLD:

    Empty list elements in list productions (e.g., a list header field
    containing ", ,") have been deprecated.  (Section 7)

NEW:

    Empty list elements in list productions (e.g., a list header field
    containing ", ,") have been deprecated (Section 7).


Section 19.7.1, paragraph 28:
OLD:

    Registration of Transfer Codings now requires IETF Review
    (Section 8.4)

NEW:

    Registration of Transfer Codings now requires IETF Review
    (Section 8.4).


Section 19.7.1, paragraph 29:
OLD:

    This specification now defines the Upgrade Token Registry, previously
    defined in Section 7.2 of [RFC2817].  (Section 8.6)

NEW:

    This specification now defines the "HTTP Upgrade Tokens" registry,
    previously defined in Section 7.2 of [RFC2817] (Section 8.6).


Section 19.7.1, paragraph 30:
OLD:

    The expectation to support HTTP/0.9 requests has been removed.
    (Appendix A)

NEW:

    The expectation to support HTTP/0.9 requests has been removed
    (Appendix A).


Section 19.7.1, paragraph 31:
OLD:

    Issues with the Keep-Alive and Proxy-Connection header fields in
    requests are pointed out, with use of the latter being discouraged
    altogether.  (Appendix A.1.2)

NEW:

    Issues with the Keep-Alive and Proxy-Connection header fields in
    requests are pointed out, with use of the latter being discouraged
    altogether (Appendix A.1.2).


Appendix B., paragraph 7:
OLD:

    URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
    Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] )
    Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment
     ] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS
     comment ] ) ] )

NEW:

    URI-reference = <URI-reference, defined in [RFC3986], Section 4.1>
    Upgrade = *( "," OWS ) protocol *( OWS "," [ OWS protocol ] )
 
    Via = *( "," OWS ) ( received-protocol RWS received-by [ RWS comment
     ] ) *( OWS "," [ OWS ( received-protocol RWS received-by [ RWS
     comment ] ) ] )


Appendix B., paragraph 15:
OLD:

    partial-URI = relative-part [ "?" query ]
    path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
    port = <port, defined in [RFC3986], Section 3.2.3>
    protocol = protocol-name [ "/" protocol-version ]
    protocol-name = token
    protocol-version = token
    pseudonym = token
 
    qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
     / %x5D-7E ; ']'-'~'
     / obs-text
    query = <query, defined in [RFC3986], Section 3.4>
    quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
    quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE

NEW:

    partial-URI = relative-part [ "?" query ]
    path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
    port = <port, defined in [RFC3986], Section 3.2.3>
    protocol = protocol-name [ "/" protocol-version ]
    protocol-name = token
    protocol-version = token
    pseudonym = token
    qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
     / %x5D-7E ; ']'-'~'
     / obs-text
    query = <query, defined in [RFC3986], Section 3.4>
    quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
    quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE


Appendix B., paragraph 24:
OLD:

    D
       deflate (Coding Format)  38
       Delimiters  26
       downstream  9

NEW:

    D
       deflate (Coding Format)  38
       Delimiters  26
       downstream  10


Appendix B., paragraph 26:
OLD:

    G
       gateway  10
       Grammar
          absolute-form  41-42
          absolute-path  16
          absolute-URI  16
          ALPHA  6
          asterisk-form  41-42
          authority  16
          authority-form  41-42
          BWS  24
          chunk  35
          chunk-data  35
          chunk-ext  35-36
          chunk-ext-name  36
          chunk-ext-val  36
          chunk-size  35
          chunked-body  35-36
          comment  27
          Connection  51
          connection-option  51
          Content-Length  30
          CR  6
          CRLF  6
          ctext  27
          CTL  6
          DIGIT  6
          DQUOTE  6
          field-content  22
          field-name  22, 39
          field-value  22
          field-vchar  22
          fragment  16
          header-field  22, 36
          HEXDIG  6
          Host  43
          HTAB  6
          HTTP-message  19
          HTTP-name  13
          http-URI  16
          HTTP-version  13
          https-URI  18
          last-chunk  35
          LF  6
          message-body  27
          method  21
          obs-fold  22
          obs-text  27
          OCTET  6
          origin-form  41
          OWS  24
          partial-URI  16
          port  16
          protocol-name  47
          protocol-version  47
          pseudonym  47
          qdtext  27
          query  16
          quoted-pair  27
          quoted-string  27
          rank  38
          reason-phrase  22
          received-by  47
          received-protocol  47
          request-line  21
          request-target  41
          RWS  24
          scheme  16
          segment  16
          SP  6
          start-line  20
          status-code  22
          status-line  22
          t-codings  38
          t-ranking  38
          tchar  27
          TE  38
          token  27
          Trailer  39
          trailer-part  35-36
          transfer-coding  35
          Transfer-Encoding  28
          transfer-extension  35
          transfer-parameter  35
          Upgrade  56
          uri-host  16
          URI-reference  16
          VCHAR  6
          Via  47
       gzip (Coding Format)  38

NEW:

    G
       gateway  10
       Grammar
          absolute-form  41-42
          absolute-path  16
          absolute-URI  16
          ALPHA  6
          asterisk-form  41-42
          authority  16
          authority-form  41-42
          BWS  24
          chunk  35
          chunk-data  35
          chunk-ext  35-36
          chunk-ext-name  36
          chunk-ext-val  36
          chunk-size  35
          chunked-body  35-36
          comment  27
          Connection  51
          connection-option  51
          Content-Length  30
          CR  6
          CRLF  6
          ctext  27
          CTL  6
          DIGIT  6
          DQUOTE  6
          field-content  22
          field-name  22, 39
          field-value  22
          field-vchar  22
          fragment  16
          header-field  22, 36
          HEXDIG  6
          Host  43
          HTAB  6
          HTTP-message  19
          HTTP-name  14
          http-URI  16
          HTTP-version  14
          https-URI  18
          last-chunk  35
          LF  6
          message-body  27
          method  21
          obs-fold  22
          obs-text  27
          OCTET  6
          origin-form  41
          OWS  24
          partial-URI  16
          port  16
          protocol-name  47
          protocol-version  47
          pseudonym  47
          qdtext  27
          query  16
          quoted-pair  27
          quoted-string  27
          rank  38
          reason-phrase  22
          received-by  47
          received-protocol  47
          request-line  21
          request-target  41
          RWS  24
          scheme  16
          segment  16
          SP  6
          start-line  20
          status-code  22
          status-line  22
          t-codings  38
          t-ranking  38
          tchar  27
          TE  38
          token  27
          Trailer  39
          trailer-part  35-36
          transfer-coding  35
          Transfer-Encoding  28
          transfer-extension  35
          transfer-parameter  35
          Upgrade  56
          uri-host  16
          URI-reference  16
          VCHAR  6
          Via  47
       gzip (Coding Format)  38


Appendix B., paragraph 28:
OLD:

    I
       inbound  9
       interception proxy  11
       intermediary  9

NEW:

    I
       inbound  10
       interception proxy  11
       intermediary  9


Appendix B., paragraph 31:
OLD:

    O
       origin server  7
       origin-form (of request-target)  41
       outbound  9

NEW:

    O
       origin server  7
       origin-form (of request-target)  41
       outbound  10


Appendix B., paragraph 36:
OLD:

    U
       Upgrade header field  56
       upstream  9
       URI scheme
          http  16
          https  18
       user agent  7

NEW:

    U
       Upgrade header field  56
       upstream  10
       URI scheme
          http  16
          https  18
       user agent  7


Section 345, paragraph 1:
OLD:

    EMail: fielding@gbiv.com
    URI:   http://roy.gbiv.com/
 
    Julian F. Reschke (editor)
    greenbytes GmbH
    Hafenweg 16
    Muenster, NW  48155
    Germany

NEW:

    EMail: fielding@gbiv.com
    URI:   http://roy.gbiv.com/
    Julian F. Reschke (editor)
    greenbytes GmbH
    Hafenweg 16
    Muenster, NW  48155
    Germany