
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)                           June 6, 2014
 Intended status: Standards Track
 Expires: December 8, 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                                      June 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 December 8, 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.


INTRODUCTION, paragraph 14:
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  . . . . . . . . . . . . . . . . . . . . 24
        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 . . . . . . . . . . . . . . . . . . . . 29
        3.3.3.  Message Body Length  . . . . . . . . . . . . . . . . . 31
      3.4.  Handling Incomplete Messages . . . . . . . . . . . . . . . 33
      3.5.  Message Parsing Robustness . . . . . . . . . . . . . . . . 34
    4.  Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 34
      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  . . . . . . . . . . . . . . . . . . . 37
        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  . . . . . . . . . . . . . . . . . . . . . . . 39
      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  . . . . . . . . . . . . . . . . . . . . 41
        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  . . . . . . . . . . . . . . . . . . . . . . . . . 46
        5.7.2.  Transformations  . . . . . . . . . . . . . . . . . . . 48
    6.  Connection Management  . . . . . . . . . . . . . . . . . . . . 49
      6.1.  Connection . . . . . . . . . . . . . . . . . . . . . . . . 50
      6.2.  Establishment  . . . . . . . . . . . . . . . . . . . . . . 51
      6.3.  Persistence  . . . . . . . . . . . . . . . . . . . . . . . 51
        6.3.1.  Retrying Requests  . . . . . . . . . . . . . . . . . . 52
        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  . . . . . . . . . . . . . . . . . . . . . 59
      8.1.  Header Field Registration  . . . . . . . . . . . . . . . . 59
      8.2.  URI Scheme Registration  . . . . . . . . . . . . . . . . . 60
      8.3.  Internet Media Type Registration . . . . . . . . . . . . . 60
        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 . . . . . . . . . . . . . . . . . . 64
        8.6.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 65
        8.6.2.  Upgrade Token Registration . . . . . . . . . . . . . . 65
    9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 66
      9.1.  Establishing Authority . . . . . . . . . . . . . . . . . . 66
      9.2.  Risks of Intermediaries  . . . . . . . . . . . . . . . . . 67
      9.3.  Attacks via Protocol Element Length  . . . . . . . . . . . 67
      9.4.  Response Splitting . . . . . . . . . . . . . . . . . . . . 68
      9.5.  Request Smuggling  . . . . . . . . . . . . . . . . . . . . 69
      9.6.  Message Integrity  . . . . . . . . . . . . . . . . . . . . 69
      9.7.  Message Confidentiality  . . . . . . . . . . . . . . . . . 69
      9.8.  Privacy of Server Log Information  . . . . . . . . . . . . 70
    10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 70
    11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72
      11.1. Normative References . . . . . . . . . . . . . . . . . . . 72
      11.2. Informative References . . . . . . . . . . . . . . . . . . 73
    Appendix A.  HTTP Version History  . . . . . . . . . . . . . . . . 75
      A.1.  Changes from HTTP/1.0  . . . . . . . . . . . . . . . . . . 76
        A.1.1.  Multihomed Web Servers . . . . . . . . . . . . . . . . 76
        A.1.2.  Keep-Alive Connections . . . . . . . . . . . . . . . . 77
        A.1.3.  Introduction of Transfer-Encoding  . . . . . . . . . . 77
      A.2.  Changes from RFC 2616  . . . . . . . . . . . . . . . . . . 77
    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 ....................................17
            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 .............................27
       3.3. Message Body ..............................................28
            3.3.1. Transfer-Encoding ..................................28
            3.3.2. Content-Length .....................................30
            3.3.3. Message Body Length ................................32
       3.4. Handling Incomplete Messages ..............................34
       3.5. Message Parsing Robustness ................................34
    4. Transfer Codings ...............................................35
       4.1. Chunked Transfer Coding ...................................36
            4.1.1. Chunk Extensions ...................................36
            4.1.2. Chunked Trailer Part ...............................37
            4.1.3. Decoding Chunked ...................................38
       4.2. Compression Codings .......................................38
            4.2.1. Compress Coding ....................................38
            4.2.2. Deflate Coding .....................................38
            4.2.3. Gzip Coding ........................................39
       4.3. TE ........................................................39
       4.4. Trailer ...................................................40
    5. Message Routing ................................................40
       5.1. Identifying a Target Resource .............................40
       5.2. Connecting Inbound ........................................41
       5.3. Request Target ............................................41
            5.3.1. origin-form ........................................42
            5.3.2. absolute-form ......................................42
            5.3.3. authority-form .....................................43
            5.3.4. asterisk-form ......................................43
       5.4. Host ......................................................44
       5.5. Effective Request URI .....................................45
       5.6. Associating a Response to a Request .......................46
       5.7. Message Forwarding ........................................47
            5.7.1. Via ................................................47
            5.7.2. Transformations ....................................49
    6. Connection Management ..........................................50
       6.1. Connection ................................................51
       6.2. Establishment .............................................52
       6.3. Persistence ...............................................52
            6.3.1. Retrying Requests ..................................53
            6.3.2. Pipelining .........................................54
       6.4. Concurrency ...............................................55
       6.5. Failures and Timeouts .....................................55
       6.6. Tear-down .................................................56
       6.7. Upgrade ...................................................57
    7. ABNF List Extension: #rule .....................................59
    8. IANA Considerations ............................................61
       8.1. Header Field Registration .................................61
       8.2. URI Scheme Registration ...................................62
       8.3. Internet Media Type Registration ..........................62
            8.3.1. Internet Media Type message/http ...................62
            8.3.2. Internet Media Type application/http ...............63
       8.4. Transfer Coding Registry ..................................64
            8.4.1. Procedure ..........................................65
            8.4.2. Registration .......................................65
       8.5. Content Coding Registration ...............................66
       8.6. Upgrade Token Registry ....................................66
            8.6.1. Procedure ..........................................66
            8.6.2. Upgrade Token Registration .........................67
    9. Security Considerations ........................................67
       9.1. Establishing Authority ....................................67
       9.2. Risks of Intermediaries ...................................68
       9.3. Attacks via Protocol Element Length .......................69
       9.4. Response Splitting ........................................69
       9.5. Request Smuggling .........................................70
       9.6. Message Integrity .........................................70
       9.7. Message Confidentiality ...................................71
       9.8. Privacy of Server Log Information .........................71
    10. Acknowledgments ...............................................72
    11. References ....................................................74
       11.1. Normative References .....................................74
       11.2. Informative References ...................................75
    Appendix A. HTTP Version History ..................................78
       A.1. Changes from HTTP/1.0  ....................................78
            A.1.1.  Multihomed Web Servers ............................78
            A.1.2.  Keep-Alive Connections ............................79
            A.1.3.  Introduction of Transfer-Encoding .................79
       A.2.  Changes from RFC 2616 ....................................80
    Appendix B. Collected ABNF ........................................82
    Index .............................................................85


Section 2.1., paragraph 4:
OLD:

    Most HTTP communication consists of a retrieval request (GET) for a
    representation of some resource identified by a URI.  In the simplest
    case, this might be accomplished via a single bidirectional
    connection (===) between the user agent (UA) and the origin server
    (O).

NEW:

    Most HTTP communication consists of a retrieval request (GET) for a
    representation of some resource identified by a URI.  In the simplest
    case, this might be accomplished via a single bidirectional
    connection (===) between the user agent (UA) and the origin
    server (O).


Section 2.5., paragraph 5:
OLD:

    When a received protocol element is parsed, the recipient MUST be
    able to parse any value of reasonable length that is applicable to
    the recipient's role and that matches the grammar defined by the
    corresponding ABNF rules.  Note, however, that some received protocol
    elements might not be parsed.  For example, an intermediary
    forwarding a message might parse a header-field into generic field-
    name and field-value components, but then forward the header field
    without further parsing inside the field-value.

NEW:

    When a received protocol element is parsed, the recipient MUST be
    able to parse any value of reasonable length that is applicable to
    the recipient's role and that matches the grammar defined by the
    corresponding ABNF rules.  Note, however, that some received protocol
    elements might not be parsed.  For example, an intermediary
    forwarding a message might parse a header-field into generic
    field-name and field-value components, but then forward the header
    field without further parsing inside the field-value.


Section 2.5., paragraph 8:
OLD:

    A recipient MUST interpret a received protocol element according to
    the semantics defined for it by this specification, including
    extensions to this specification, unless the recipient has determined
    (through experience or configuration) that the sender incorrectly
    implements what is implied by those semantics.  For example, an
    origin server might disregard the contents of a received Accept-
    Encoding header field if inspection of the User-Agent header field
    indicates a specific implementation version that is known to fail on
    receipt of certain content codings.

NEW:

    A recipient MUST interpret a received protocol element according to
    the semantics defined for it by this specification, including
    extensions to this specification, unless the recipient has determined
    (through experience or configuration) that the sender incorrectly
    implements what is implied by those semantics.  For example, an
    origin server might disregard the contents of a received
    Accept-Encoding header field if inspection of the User-Agent header
    field indicates a specific implementation version that is known to
    fail on receipt of certain content codings.


Section 2.6., paragraph 8:
OLD:

    Intermediaries that process HTTP messages (i.e., all intermediaries
    other than those acting as tunnels) MUST send their own HTTP-version
    in forwarded messages.  In other words, they are not allowed to
    blindly forward the first line of an HTTP message without ensuring
    that the protocol version in that message matches a version to which
    that intermediary is conformant for both the receiving and sending of
    messages.  Forwarding an HTTP message without rewriting the HTTP-
    version might result in communication errors when downstream
    recipients use the message sender's version to determine what
    features are safe to use for later communication with that sender.

NEW:

    Intermediaries that process HTTP messages (i.e., all intermediaries
    other than those acting as tunnels) MUST send their own HTTP-version
    in forwarded messages.  In other words, they are not allowed to
    blindly forward the first line of an HTTP message without ensuring
    that the protocol version in that message matches a version to which
    that intermediary is conformant for both the receiving and sending of
    messages.  Forwarding an HTTP message without rewriting the
    HTTP-version might result in communication errors when downstream
    recipients use the message sender's version to determine what
    features are safe to use for later communication with that sender.


Section 2.7., paragraph 5:
OLD:

    Each protocol element in HTTP that allows a URI reference will
    indicate in its ABNF production whether the element allows any form
    of reference (URI-reference), only a URI in absolute form (absolute-
    URI), only the path and optional query components, or some
    combination of the above.  Unless otherwise indicated, URI references
    are parsed relative to the effective request URI (Section 5.5).

NEW:

    Each protocol element in HTTP that allows a URI reference will
    indicate in its ABNF production whether the element allows any form
    of reference (URI-reference), only a URI in absolute form
    (absolute-URI), only the path and optional query components, or some
    combination of the above.  Unless otherwise indicated, URI references
    are parsed relative to the effective request URI (Section 5.5).


Section 2.7.1., paragraph 2:
OLD:

      http-URI = "http:" "//" authority path-abempty [ "?" query ]
 
                 [ "#" fragment ]

NEW:

      http-URI = "http:" "//" authority path-abempty [ "?" query ]
                 [ "#" fragment ]


Section 2.7.3., paragraph 2:
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 400, paragraph 1:
OLD:

    HTTP does not place a predefined limit on the length of a request-
    line, as described in Section 2.5.  A server that receives a method
    longer than any that it implements SHOULD respond with a 501 (Not
    Implemented) status code.  A server that receives a request-target
    longer than any URI it wishes to parse MUST respond with a 414 (URI
    Too Long) status code (see Section 6.5.12 of [RFC7231]).

NEW:

    HTTP does not place a predefined limit on the length of a
    request-line, as described in Section 2.5.  A server that receives a
    method longer than any that it implements SHOULD respond with a 501
    (Not Implemented) status code.  A server that receives a
    request-target longer than any URI it wishes to parse MUST respond
    with a 414 (URI Too Long) status code (see Section 6.5.12 of
    [RFC7231]).


Section 3.2.4., paragraph 3:
OLD:

    A field value might be preceded and/or followed by optional
    whitespace (OWS); a single SP preceding the field-value is preferred
    for consistent readability by humans.  The field value does not
    include any leading or trailing whitespace: OWS occurring before the
    first non-whitespace octet of the field value or after the last non-
    whitespace octet of the field value ought to be excluded by parsers
    when extracting the field value from a header field.

NEW:

    A field value might be preceded and/or followed by optional
    whitespace (OWS); a single SP preceding the field-value is preferred
    for consistent readability by humans.  The field value does not
    include any leading or trailing whitespace: OWS occurring before the
    first non-whitespace octet of the field value or after the last
    non-whitespace octet of the field value ought to be excluded by
    parsers when extracting the field value from a header field.


Section 3.2.4., paragraph 7:
OLD:

    A user agent that receives an obs-fold in a response message that is
    not within a message/http container MUST replace each received obs-
    fold with one or more SP octets prior to interpreting the field
    value.

NEW:

    A user agent that receives an obs-fold in a response message that is
    not within a message/http container MUST replace each received
    obs-fold with one or more SP octets prior to interpreting the field
    value.


Section 3.3., paragraph 4:
OLD:

    The presence of a message body in a request is signaled by a Content-
    Length or Transfer-Encoding header field.  Request message framing is
    independent of method semantics, even if the method does not define
    any use for a message body.

NEW:

    The presence of a message body in a request is signaled by a
    Content-Length or Transfer-Encoding header field.  Request message
    framing is independent of method semantics, even if the method does
    not define any use for a message body.


Section 3.3.1., paragraph 8:
OLD:

    Unlike Content-Encoding (Section 3.1.2.1 of [RFC7231]), Transfer-
    Encoding is a property of the message, not of the representation, and
    any recipient along the request/response chain MAY decode the
    received transfer coding(s) or apply additional transfer coding(s) to
    the message body, assuming that corresponding changes are made to the
    Transfer-Encoding field-value.  Additional information about the
    encoding parameters can be provided by other header fields not
    defined by this specification.

NEW:

    Unlike Content-Encoding (Section 3.1.2.1 of [RFC7231]),
    Transfer-Encoding is a property of the message, not of the
    representation, and any recipient along the request/response chain
    MAY decode the received transfer coding(s) or apply additional
    transfer coding(s) to the message body, assuming that corresponding
    changes are made to the Transfer-Encoding field-value.  Additional
    information about the encoding parameters can be provided by other
    header fields not defined by this specification.


Section 3.3.2., paragraph 10:
OLD:

    Aside from the cases defined above, in the absence of Transfer-
    Encoding, an origin server SHOULD send a Content-Length header field
    when the payload body size is known prior to sending the complete
    header section.  This will allow downstream recipients to measure
    transfer progress, know when a received message is complete, and
    potentially reuse the connection for additional requests.

NEW:

    Aside from the cases defined above, in the absence of
    Transfer-Encoding, an origin server SHOULD send a Content-Length
    header field when the payload body size is known prior to sending the
    complete header section.  This will allow downstream recipients to
    measure transfer progress, know when a received message is complete,
    and potentially reuse the connection for additional requests.


Section 3.3.2., paragraph 13:
OLD:

       Note: HTTP's use of Content-Length for message framing differs
       significantly from the same field's use in MIME, where it is an
       optional field used only within the "message/external-body" media-
       type.

NEW:

       Note: HTTP's use of Content-Length for message framing differs
       significantly from the same field's use in MIME, where it is an
       optional field used only within the "message/external-body"
       media-type.


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.1.1., paragraph 1:
OLD:

    The chunked encoding allows each chunk to include zero or more chunk
    extensions, immediately following the chunk-size, for the sake of
    supplying per-chunk metadata (such as a signature or hash), mid-
    message control information, or randomization of message body size.

NEW:

    The chunked encoding allows each chunk to include zero or more chunk
    extensions, immediately following the chunk-size, for the sake of
    supplying per-chunk metadata (such as a signature or hash),
    mid-message control information, or randomization of message body
    size.


Section 5.1., paragraph 1:
OLD:

    HTTP is used in a wide variety of applications, ranging from general-
    purpose computers to home appliances.  In some cases, communication
    options are hard-coded in a client's configuration.  However, most
    HTTP clients rely on the same resource identification mechanism and
    configuration techniques as general-purpose Web browsers.

NEW:

    HTTP is used in a wide variety of applications, ranging from
    general-purpose computers to home appliances.  In some cases,
    communication options are hard-coded in a client's configuration.
    However, most HTTP clients rely on the same resource identification
    mechanism and configuration techniques as general-purpose Web
    browsers.


Section 5.4., paragraph 8:
OLD:

    When a proxy receives a request with an absolute-form of request-
    target, the proxy MUST ignore the received Host header field (if any)
    and instead replace it with the host information of the request-
    target.  A proxy that forwards such a request MUST generate a new
    Host field-value based on the received request-target rather than
    forward the received Host field-value.

NEW:

    When a proxy receives a request with an absolute-form of
    request-target, the proxy MUST ignore the received Host header field
    (if any) and instead replace it with the host information of the
    request-target.  A proxy that forwards such a request MUST generate a
    new Host field-value based on the received request-target rather than
    forward the received Host field-value.


Section 5.6., paragraph 2:
OLD:

    A client that has more than one outstanding request on a connection
    MUST maintain a list of outstanding requests in the order sent and
    MUST associate each received response message on that connection to
    the highest ordered request that has not yet received a final (non-
    1xx) response.

NEW:

    A client that has more than one outstanding request on a connection
    MUST maintain a list of outstanding requests in the order sent and
    MUST associate each received response message on that connection to
    the highest ordered request that has not yet received a final
    (non-1xx) response.


Section 6.3.1., paragraph 2:
OLD:

    When an inbound connection is closed prematurely, a client MAY open a
    new connection and automatically retransmit an aborted sequence of
    requests if all of those requests have idempotent methods (Section
    4.2.2 of [RFC7231]).  A proxy MUST NOT automatically retry non-
    idempotent requests.

NEW:

    When an inbound connection is closed prematurely, a client MAY open a
    new connection and automatically retransmit an aborted sequence of
    requests if all of those requests have idempotent methods (Section
    4.2.2 of [RFC7231]).  A proxy MUST NOT automatically retry
    non-idempotent requests.


Section 6.4., paragraph 3:
OLD:

    Multiple connections are typically used to avoid the "head-of-line
    blocking" problem, wherein a request that takes significant server-
    side processing and/or has a large payload blocks subsequent requests
    on the same connection.  However, each connection consumes server
    resources.  Furthermore, using multiple connections can cause
    undesirable side effects in congested networks.

NEW:

    Multiple connections are typically used to avoid the "head-of-line
    blocking" problem, wherein a request that takes significant
    server-side processing and/or has a large payload blocks subsequent
    requests on the same connection.  However, each connection consumes
    server resources.  Furthermore, using multiple connections can cause
    undesirable side effects in congested networks.


Section 7., paragraph 2:
OLD:

    A construct "#" is defined, similar to "*", for defining comma-
    delimited lists of elements.  The full form is "<n>#<m>element"
    indicating at least <n> and at most <m> elements, each separated by a
    single comma (",") and optional whitespace (OWS).

NEW:

    A construct "#" is defined, similar to "*", for defining
    comma-delimited lists of elements.  The full form is "<n>#<m>element"
    indicating at least <n> and at most <m> elements, each separated by a
    single comma (",") and optional whitespace (OWS).


Section 8.3.1., paragraph 17:
OLD:

       File extension(s):  N/A
       Macintosh file type code(s):  N/A

NEW:

       File extension(s):  N/A
 
       Macintosh file type code(s):  N/A


Section 8.3.2., paragraph 12:
OLD:

    Applications that use this media type:  N/A
    Fragment identifier considerations:  N/A

NEW:

    Applications that use this media type:  N/A
 
    Fragment identifier considerations:  N/A


Section 9.1., paragraph 1:
OLD:

    HTTP relies on the notion of an authoritative response: a response
    that has been determined by (or at the direction of) the authority
    identified within the target URI to be the most appropriate response
    for that request given the state of the target resource at the time
    of response message origination.  Providing a response from a non-
    authoritative source, such as a shared cache, is often useful to
    improve performance and availability, but only to the extent that the
    source can be trusted or the distrusted response can be safely used.

NEW:

    HTTP relies on the notion of an authoritative response: a response
    that has been determined by (or at the direction of) the authority
    identified within the target URI to be the most appropriate response
    for that request given the state of the target resource at the time
    of response message origination.  Providing a response from a
    non-authoritative source, such as a shared cache, is often useful to
    improve performance and availability, but only to the extent that the
    source can be trusted or the distrusted response can be safely used.


Section 9.6., paragraph 1:
OLD:

    HTTP does not define a specific mechanism for ensuring message
    integrity, instead relying on the error-detection ability of
    underlying transport protocols and the use of length or chunk-
    delimited framing to detect completeness.  Additional integrity
    mechanisms, such as hash functions or digital signatures applied to
    the content, can be selectively added to messages via extensible
    metadata header fields.  Historically, the lack of a single integrity
    mechanism has been justified by the informal nature of most HTTP
    communication.  However, the prevalence of HTTP as an information
    access mechanism has resulted in its increasing use within
    environments where verification of message integrity is crucial.

NEW:

    HTTP does not define a specific mechanism for ensuring message
    integrity, instead relying on the error-detection ability of
    underlying transport protocols and the use of length or
    chunk-delimited framing to detect completeness.  Additional integrity
    mechanisms, such as hash functions or digital signatures applied to
    the content, can be selectively added to messages via extensible
    metadata header fields.  Historically, the lack of a single integrity
    mechanism has been justified by the informal nature of most HTTP
    communication.  However, the prevalence of HTTP as an information
    access mechanism has resulted in its increasing use within
    environments where verification of message integrity is crucial.


Section 9.8., paragraph 3:
OLD:

    To minimize the risk of theft or accidental publication, log
    information ought to be purged of personally identifiable
    information, including user identifiers, IP addresses, and user-
    provided query parameters, as soon as that information is no longer
    necessary to support operational needs for security, auditing, or
    fraud control.

NEW:

    To minimize the risk of theft or accidental publication, log
    information ought to be purged of personally identifiable
    information, including user identifiers, IP addresses, and
    user-provided query parameters, as soon as that information is no
    longer necessary to support operational needs for security, auditing,
    or fraud control.


Section 11.1., paragraph 8:
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), June 2014.

NEW:

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


Section 11.1., paragraph 9:
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), June 2014.

NEW:

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


Section 11.1., paragraph 10:
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), June 2014.

NEW:

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


Section 11.1., paragraph 11:
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),
                  June 2014.

NEW:

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


Section 11.1., paragraph 12:
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),
                  June 2014.

NEW:

    [RFC7235]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
                  Transfer Protocol (HTTP/1.1): Authentication",
                  RFC 7235, June 2014.


Section 19.7.1, paragraph 4:
OLD:

    Clients are also encouraged to consider the use of Connection: keep-
    alive in requests carefully; while they can enable persistent
    connections with HTTP/1.0 servers, clients using them will need to
    monitor the connection for "hung" requests (which indicate that the
    client ought stop sending the header field), and this mechanism ought
    not be used by clients at all when a proxy is being used.

NEW:

    Clients are also encouraged to consider the use of Connection:
    keep-alive in requests carefully; while they can enable persistent
    connections with HTTP/1.0 servers, clients using them will need to
    monitor the connection for "hung" requests (which indicate that the
    client ought stop sending the header field), and this mechanism ought
    not be used by clients at all when a proxy is being used.


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)
    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:

    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)
 
    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 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 28:
OLD:

    Registration of Transfer Codings now requires IETF Review
    (Section 8.4)
 
    This specification now defines the Upgrade Token Registry, previously
    defined in Section 7.2 of [RFC2817].  (Section 8.6)

NEW:

    Registration of Transfer Codings now requires IETF Review
    (Section 8.4)
    This specification now defines the Upgrade Token Registry, previously
    defined in Section 7.2 of [RFC2817].  (Section 8.6)


Appendix B., paragraph 2:
OLD:

    Connection = *( "," OWS ) connection-option *( OWS "," [ OWS
     connection-option ] )
    Content-Length = 1*DIGIT

NEW:

    Connection = *( "," OWS ) connection-option *( OWS "," [ OWS
     connection-option ] )
 
    Content-Length = 1*DIGIT


Appendix B., paragraph 9:
OLD:

    absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>
    absolute-form = absolute-URI
    absolute-path = 1*( "/" segment )
    asterisk-form = "*"
    authority = <authority, see [RFC3986], Section 3.2>
    authority-form = authority
 
    chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF
    chunk-data = 1*OCTET
    chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
    chunk-ext-name = token
    chunk-ext-val = token / quoted-string
    chunk-size = 1*HEXDIG
    chunked-body = *chunk last-chunk trailer-part CRLF
    comment = "(" *( ctext / quoted-pair / comment ) ")"
    connection-option = token
    ctext = HTAB / SP / %x21-27 ; '!'-'''
     / %x2A-5B ; '*'-'['
     / %x5D-7E ; ']'-'~'
     / obs-text

NEW:

    absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>
    absolute-form = absolute-URI
    absolute-path = 1*( "/" segment )
    asterisk-form = "*"
    authority = <authority, see [RFC3986], Section 3.2>
    authority-form = authority
    chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF
    chunk-data = 1*OCTET
    chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
    chunk-ext-name = token
    chunk-ext-val = token / quoted-string
    chunk-size = 1*HEXDIG
    chunked-body = *chunk last-chunk trailer-part CRLF
    comment = "(" *( ctext / quoted-pair / comment ) ")"
    connection-option = token
    ctext = HTAB / SP / %x21-27 ; '!'-'''
     / %x2A-5B ; '*'-'['
     / %x5D-7E ; ']'-'~'
     / obs-text


Appendix B., paragraph 22:
OLD:

    A
       absolute-form (of request-target)  41
       accelerator  10
       application/http Media Type  62
       asterisk-form (of request-target)  42
       authoritative response  66
       authority-form (of request-target)  42

NEW:

    A
       absolute-form (of request-target)  42
       accelerator  10
       application/http Media Type  63
       asterisk-form (of request-target)  43
       authoritative response  67
       authority-form (of request-target)  42-43


Appendix B., paragraph 24:
OLD:

    C
       cache  11
       cacheable  11
       captive portal  11
       chunked (Coding Format)  28, 31, 35
       client  7
       close  50, 55
       compress (Coding Format)  38
       connection  7
       Connection header field  50, 55
       Content-Length header field  29

NEW:

    C
       cache  11
       cacheable  12
       captive portal  11
       chunked (Coding Format)  28, 32, 36
       client  7
       close  51, 56
       compress (Coding Format)  38
       connection  7
       Connection header field  51, 56
       Content-Length header field  30


Appendix B., paragraph 25:
OLD:

    D
       deflate (Coding Format)  38
       Delimiters  26
       downstream  9

NEW:

    D
       deflate (Coding Format)  38
       Delimiters  27
       downstream  10


Appendix B., paragraph 26:
OLD:

    E
       effective request URI  44

NEW:

    E
       effective request URI  45


Appendix B., paragraph 27:
OLD:

    G
       gateway  10
       Grammar
          absolute-form  41
          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  50
          connection-option  50
          Content-Length  29
          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  26
          TE  38
          token  26
          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  42
          absolute-path  16
          absolute-URI  16
          ALPHA  6
          asterisk-form  41, 43
          authority  16
          authority-form  42-43
          BWS  25
          chunk  36
          chunk-data  36
          chunk-ext  36
          chunk-ext-name  36
          chunk-ext-val  36
          chunk-size  36
          chunked-body  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  23
          field-name  23, 40
          field-value  23
          field-vchar  23
          fragment  16
          header-field  23, 37
          HEXDIG  6
          Host  44
          HTAB  6
          HTTP-message  19
          HTTP-name  14
          http-URI  17
          HTTP-version  14
          https-URI  18
          last-chunk  36
          LF  6
          message-body  28
          method  21
          obs-fold  23
          obs-text  27
          OCTET  6
          origin-form  42
          OWS  25
          partial-URI  16
          port  16
          protocol-name  47
          protocol-version  47
          pseudonym  47
          qdtext  27
          query  16
          quoted-pair  27
          quoted-string  27
          rank  39
          reason-phrase  22
          received-by  47
          received-protocol  47
          request-line  21
          request-target  41
          RWS  25
          scheme  16
          segment  16
          SP  6
          start-line  21
          status-code  22
          status-line  22
          t-codings  39
          t-ranking  39
          tchar  27
          TE  39
          token  27
          Trailer  40
          trailer-part  37
          transfer-coding  35
          Transfer-Encoding  28
          transfer-extension  35
          transfer-parameter  35
          Upgrade  57
          uri-host  16
          URI-reference  16
          VCHAR  6
          Via  47
       gzip (Coding Format)  39


Appendix B., paragraph 28:
OLD:

    H
       header field  19
       header section  19
       headers  19
       Host header field  43
       http URI scheme  16
       https URI scheme  18
 
    I
       inbound  9
       interception proxy  11
       intermediary  9

NEW:

    H
       header field  19
       header section  19
       headers  19
       Host header field  44
       http URI scheme  17
       https URI scheme  17
    I
       inbound  9
       interception proxy  11
       intermediary  9


Appendix B., paragraph 29:
OLD:

    M
       Media Type
          application/http  62
          message/http  61
       message  7
       message/http Media Type  61
       method  21

NEW:

    M
       Media Type
          application/http  63
          message/http  62
       message  7
       message/http Media Type  62
       method  21


Appendix B., paragraph 30:
OLD:

    N
       non-transforming proxy  48

NEW:

    N
       non-transforming proxy  49


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)  42
       outbound  10


Appendix B., paragraph 32:
OLD:

    P
       phishing  66
       proxy  10

NEW:

    P
       phishing  67
       proxy  10


Appendix B., paragraph 35:
OLD:

    T
       target resource  40
       target URI  40
       TE header field  38
       Trailer header field  39
       Transfer-Encoding header field  28
       transforming proxy  48
       transparent proxy  11
       tunnel  10

NEW:

    T
       target resource  40
       target URI  40
       TE header field  39
       Trailer header field  40
       Transfer-Encoding header field  28
       transforming proxy  49
       transparent proxy  11
       tunnel  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  57
       upstream  9
       URI scheme
          http  17
          https  17
       user agent  7


Appendix B., paragraph 37:
OLD:

    V
       Via header field  46

NEW:

    V
       Via header field  47

