
INTRODUCTION, paragraph 1:
OLD:

 HTTPbis Working Group                                   R. Fielding, Ed.
 Internet-Draft                                                     Adobe
 Obsoletes: 2616 (if approved)                            J. Reschke, Ed.
 Updates: 2817 (if approved)                                   greenbytes
 Intended status: Standards Track                            June 6, 2014
 Expires: December 8, 2014

NEW:

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


INTRODUCTION, paragraph 2:
OLD:

      Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
                  draft-ietf-httpbis-p2-semantics-latest

NEW:

      Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content


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/rfc7231.


INTRODUCTION, paragraph 14:
OLD:

    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  6
      1.1.  Conformance and Error Handling . . . . . . . . . . . . . .  6
      1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  6
    2.  Resources  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
    3.  Representations  . . . . . . . . . . . . . . . . . . . . . . .  7
      3.1.  Representation Metadata  . . . . . . . . . . . . . . . . .  8
        3.1.1.  Processing Representation Data . . . . . . . . . . . .  8
        3.1.2.  Encoding for Compression or Integrity  . . . . . . . . 11
        3.1.3.  Audience Language  . . . . . . . . . . . . . . . . . . 13
        3.1.4.  Identification . . . . . . . . . . . . . . . . . . . . 14
      3.2.  Representation Data  . . . . . . . . . . . . . . . . . . . 17
      3.3.  Payload Semantics  . . . . . . . . . . . . . . . . . . . . 17
      3.4.  Content Negotiation  . . . . . . . . . . . . . . . . . . . 18
        3.4.1.  Proactive Negotiation  . . . . . . . . . . . . . . . . 19
        3.4.2.  Reactive Negotiation . . . . . . . . . . . . . . . . . 20

NEW:

    1. Introduction ....................................................6
       1.1. Conformance and Error Handling .............................6
       1.2. Syntax Notation ............................................6
    2. Resources .......................................................7
    3. Representations .................................................7
       3.1. Representation Metadata ....................................8
            3.1.1. Processing Representation Data ......................8
            3.1.2. Encoding for Compression or Integrity ..............11
            3.1.3. Audience Language ..................................13
            3.1.4. Identification .....................................14
       3.2. Representation Data .......................................17
       3.3. Payload Semantics .........................................17
       3.4. Content Negotiation .......................................18
            3.4.1. Proactive Negotiation ..............................19
            3.4.2. Reactive Negotiation ...............................20
    4. Request Methods ................................................21
       4.1. Overview ..................................................21
       4.2. Common Method Properties ..................................22
            4.2.1. Safe Methods .......................................22
            4.2.2. Idempotent Methods .................................23
            4.2.3. Cacheable Methods ..................................24
       4.3. Method Definitions ........................................24
            4.3.1. GET ................................................24
            4.3.2. HEAD ...............................................25
            4.3.3. POST ...............................................25
            4.3.4. PUT ................................................26
            4.3.5. DELETE .............................................29
            4.3.6. CONNECT ............................................30
            4.3.7. OPTIONS ............................................31
            4.3.8. TRACE ..............................................32
    5. Request Header Fields ..........................................33
       5.1. Controls ..................................................33
            5.1.1. Expect .............................................34
            5.1.2. Max-Forwards .......................................36
       5.2. Conditionals ..............................................36
       5.3. Content Negotiation .......................................37
            5.3.1. Quality Values .....................................37
            5.3.2. Accept .............................................38
            5.3.3. Accept-Charset .....................................40
            5.3.4. Accept-Encoding ....................................41
            5.3.5. Accept-Language ....................................42
       5.4. Authentication Credentials ................................44
       5.5. Request Context ...........................................44
            5.5.1. From ...............................................44
            5.5.2. Referer ............................................45
            5.5.3. User-Agent .........................................46


INTRODUCTION, paragraph 15:
OLD:

    4.  Request Methods  . . . . . . . . . . . . . . . . . . . . . . . 21
      4.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . 21
      4.2.  Common Method Properties . . . . . . . . . . . . . . . . . 22
        4.2.1.  Safe Methods . . . . . . . . . . . . . . . . . . . . . 22
        4.2.2.  Idempotent Methods . . . . . . . . . . . . . . . . . . 23
        4.2.3.  Cacheable Methods  . . . . . . . . . . . . . . . . . . 24
      4.3.  Method Definitions . . . . . . . . . . . . . . . . . . . . 24
        4.3.1.  GET  . . . . . . . . . . . . . . . . . . . . . . . . . 24
        4.3.2.  HEAD . . . . . . . . . . . . . . . . . . . . . . . . . 25
        4.3.3.  POST . . . . . . . . . . . . . . . . . . . . . . . . . 25
        4.3.4.  PUT  . . . . . . . . . . . . . . . . . . . . . . . . . 26
        4.3.5.  DELETE . . . . . . . . . . . . . . . . . . . . . . . . 29
        4.3.6.  CONNECT  . . . . . . . . . . . . . . . . . . . . . . . 30
        4.3.7.  OPTIONS  . . . . . . . . . . . . . . . . . . . . . . . 31
        4.3.8.  TRACE  . . . . . . . . . . . . . . . . . . . . . . . . 32
    5.  Request Header Fields  . . . . . . . . . . . . . . . . . . . . 33
      5.1.  Controls . . . . . . . . . . . . . . . . . . . . . . . . . 33
        5.1.1.  Expect . . . . . . . . . . . . . . . . . . . . . . . . 34
        5.1.2.  Max-Forwards . . . . . . . . . . . . . . . . . . . . . 36
      5.2.  Conditionals . . . . . . . . . . . . . . . . . . . . . . . 36
      5.3.  Content Negotiation  . . . . . . . . . . . . . . . . . . . 37
        5.3.1.  Quality Values . . . . . . . . . . . . . . . . . . . . 37
        5.3.2.  Accept . . . . . . . . . . . . . . . . . . . . . . . . 38
        5.3.3.  Accept-Charset . . . . . . . . . . . . . . . . . . . . 40
        5.3.4.  Accept-Encoding  . . . . . . . . . . . . . . . . . . . 41
        5.3.5.  Accept-Language  . . . . . . . . . . . . . . . . . . . 42
      5.4.  Authentication Credentials . . . . . . . . . . . . . . . . 43
      5.5.  Request Context  . . . . . . . . . . . . . . . . . . . . . 44
        5.5.1.  From . . . . . . . . . . . . . . . . . . . . . . . . . 44
        5.5.2.  Referer  . . . . . . . . . . . . . . . . . . . . . . . 45
        5.5.3.  User-Agent . . . . . . . . . . . . . . . . . . . . . . 46
    6.  Response Status Codes  . . . . . . . . . . . . . . . . . . . . 47
      6.1.  Overview of Status Codes . . . . . . . . . . . . . . . . . 48
      6.2.  Informational 1xx  . . . . . . . . . . . . . . . . . . . . 50
        6.2.1.  100 Continue . . . . . . . . . . . . . . . . . . . . . 50
        6.2.2.  101 Switching Protocols  . . . . . . . . . . . . . . . 50
      6.3.  Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 51
        6.3.1.  200 OK . . . . . . . . . . . . . . . . . . . . . . . . 51
        6.3.2.  201 Created  . . . . . . . . . . . . . . . . . . . . . 51
        6.3.3.  202 Accepted . . . . . . . . . . . . . . . . . . . . . 52
        6.3.4.  203 Non-Authoritative Information  . . . . . . . . . . 52
        6.3.5.  204 No Content . . . . . . . . . . . . . . . . . . . . 53
        6.3.6.  205 Reset Content  . . . . . . . . . . . . . . . . . . 53
      6.4.  Redirection 3xx  . . . . . . . . . . . . . . . . . . . . . 54
        6.4.1.  300 Multiple Choices . . . . . . . . . . . . . . . . . 55
        6.4.2.  301 Moved Permanently  . . . . . . . . . . . . . . . . 56
        6.4.3.  302 Found  . . . . . . . . . . . . . . . . . . . . . . 56
        6.4.4.  303 See Other  . . . . . . . . . . . . . . . . . . . . 57
        6.4.5.  305 Use Proxy  . . . . . . . . . . . . . . . . . . . . 57
        6.4.6.  306 (Unused) . . . . . . . . . . . . . . . . . . . . . 57
        6.4.7.  307 Temporary Redirect . . . . . . . . . . . . . . . . 58
      6.5.  Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 58
        6.5.1.  400 Bad Request  . . . . . . . . . . . . . . . . . . . 58
        6.5.2.  402 Payment Required . . . . . . . . . . . . . . . . . 58
        6.5.3.  403 Forbidden  . . . . . . . . . . . . . . . . . . . . 58
        6.5.4.  404 Not Found  . . . . . . . . . . . . . . . . . . . . 59
        6.5.5.  405 Method Not Allowed . . . . . . . . . . . . . . . . 59
        6.5.6.  406 Not Acceptable . . . . . . . . . . . . . . . . . . 59
        6.5.7.  408 Request Timeout  . . . . . . . . . . . . . . . . . 60
        6.5.8.  409 Conflict . . . . . . . . . . . . . . . . . . . . . 60
        6.5.9.  410 Gone . . . . . . . . . . . . . . . . . . . . . . . 60
        6.5.10. 411 Length Required  . . . . . . . . . . . . . . . . . 61
        6.5.11. 413 Payload Too Large  . . . . . . . . . . . . . . . . 61
        6.5.12. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 61
        6.5.13. 415 Unsupported Media Type . . . . . . . . . . . . . . 61
        6.5.14. 417 Expectation Failed . . . . . . . . . . . . . . . . 62
        6.5.15. 426 Upgrade Required . . . . . . . . . . . . . . . . . 62
      6.6.  Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 62
        6.6.1.  500 Internal Server Error  . . . . . . . . . . . . . . 62
        6.6.2.  501 Not Implemented  . . . . . . . . . . . . . . . . . 63
        6.6.3.  502 Bad Gateway  . . . . . . . . . . . . . . . . . . . 63
        6.6.4.  503 Service Unavailable  . . . . . . . . . . . . . . . 63
        6.6.5.  504 Gateway Timeout  . . . . . . . . . . . . . . . . . 63
        6.6.6.  505 HTTP Version Not Supported . . . . . . . . . . . . 63
    7.  Response Header Fields . . . . . . . . . . . . . . . . . . . . 64
      7.1.  Control Data . . . . . . . . . . . . . . . . . . . . . . . 64
        7.1.1.  Origination Date . . . . . . . . . . . . . . . . . . . 64
        7.1.2.  Location . . . . . . . . . . . . . . . . . . . . . . . 68
        7.1.3.  Retry-After  . . . . . . . . . . . . . . . . . . . . . 69
        7.1.4.  Vary . . . . . . . . . . . . . . . . . . . . . . . . . 70
      7.2.  Validator Header Fields  . . . . . . . . . . . . . . . . . 71
      7.3.  Authentication Challenges  . . . . . . . . . . . . . . . . 72
      7.4.  Response Context . . . . . . . . . . . . . . . . . . . . . 72
        7.4.1.  Allow  . . . . . . . . . . . . . . . . . . . . . . . . 72
        7.4.2.  Server . . . . . . . . . . . . . . . . . . . . . . . . 73
    8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 73
      8.1.  Method Registry  . . . . . . . . . . . . . . . . . . . . . 74
        8.1.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 74
        8.1.2.  Considerations for New Methods . . . . . . . . . . . . 74
        8.1.3.  Registrations  . . . . . . . . . . . . . . . . . . . . 75
      8.2.  Status Code Registry . . . . . . . . . . . . . . . . . . . 75
        8.2.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 75
        8.2.2.  Considerations for New Status Codes  . . . . . . . . . 76
        8.2.3.  Registrations  . . . . . . . . . . . . . . . . . . . . 76
      8.3.  Header Field Registry  . . . . . . . . . . . . . . . . . . 77
        8.3.1.  Considerations for New Header Fields . . . . . . . . . 78
        8.3.2.  Registrations  . . . . . . . . . . . . . . . . . . . . 80
      8.4.  Content Coding Registry  . . . . . . . . . . . . . . . . . 80
        8.4.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 81
        8.4.2.  Registrations  . . . . . . . . . . . . . . . . . . . . 81
    9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 81
      9.1.  Attacks Based on File and Path Names . . . . . . . . . . . 82
      9.2.  Attacks Based on Command, Code, or Query Injection . . . . 82
      9.3.  Disclosure of Personal Information . . . . . . . . . . . . 83
      9.4.  Disclosure of Sensitive Information in URIs  . . . . . . . 83
      9.5.  Disclosure of Fragment after Redirects . . . . . . . . . . 83
      9.6.  Disclosure of Product Information  . . . . . . . . . . . . 84
      9.7.  Browser Fingerprinting . . . . . . . . . . . . . . . . . . 84
    10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 85
    11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 85
      11.1. Normative References . . . . . . . . . . . . . . . . . . . 85
      11.2. Informative References . . . . . . . . . . . . . . . . . . 86
    Appendix A.  Differences between HTTP and MIME . . . . . . . . . . 88
      A.1.  MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 89
      A.2.  Conversion to Canonical Form . . . . . . . . . . . . . . . 89
      A.3.  Conversion of Date Formats . . . . . . . . . . . . . . . . 89
      A.4.  Conversion of Content-Encoding . . . . . . . . . . . . . . 89
      A.5.  Conversion of Content-Transfer-Encoding  . . . . . . . . . 90
      A.6.  MHTML and Line Length Limitations  . . . . . . . . . . . . 90
    Appendix B.  Changes from RFC 2616 . . . . . . . . . . . . . . . . 90
    Appendix C.  Imported ABNF . . . . . . . . . . . . . . . . . . . . 93
    Appendix D.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 93
    Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

NEW:

    6. Response Status Codes ..........................................47
       6.1. Overview of Status Codes ..................................48
       6.2. Informational 1xx .........................................50
            6.2.1. 100 Continue .......................................50
            6.2.2. 101 Switching Protocols ............................50
       6.3. Successful 2xx ............................................51
            6.3.1. 200 OK .............................................51
            6.3.2. 201 Created ........................................52
            6.3.3. 202 Accepted .......................................52
            6.3.4. 203 Non-Authoritative Information ..................52
            6.3.5. 204 No Content .....................................53
            6.3.6. 205 Reset Content ..................................53
       6.4. Redirection 3xx ...........................................54
            6.4.1. 300 Multiple Choices ...............................55
            6.4.2. 301 Moved Permanently ..............................56
            6.4.3. 302 Found ..........................................56
            6.4.4. 303 See Other ......................................57
            6.4.5. 305 Use Proxy ......................................58
            6.4.6. 306 (Unused) .......................................58
            6.4.7. 307 Temporary Redirect .............................58
       6.5. Client Error 4xx ..........................................58
            6.5.1. 400 Bad Request ....................................58
            6.5.2. 402 Payment Required ...............................59
            6.5.3. 403 Forbidden ......................................59
            6.5.4. 404 Not Found ......................................59
            6.5.5. 405 Method Not Allowed .............................59
            6.5.6. 406 Not Acceptable .................................60
            6.5.7. 408 Request Timeout ................................60
            6.5.8. 409 Conflict .......................................60
            6.5.9. 410 Gone ...........................................60
            6.5.10. 411 Length Required ...............................61
            6.5.11. 413 Payload Too Large .............................61
            6.5.12. 414 URI Too Long ..................................61
            6.5.13. 415 Unsupported Media Type ........................62
            6.5.14. 417 Expectation Failed ............................62
            6.5.15. 426 Upgrade Required ..............................62
       6.6. Server Error 5xx ..........................................62
            6.6.1. 500 Internal Server Error ..........................63
            6.6.2. 501 Not Implemented ................................63
            6.6.3. 502 Bad Gateway ....................................63
            6.6.4. 503 Service Unavailable ............................63
            6.6.5. 504 Gateway Timeout ................................63
            6.6.6. 505 HTTP Version Not Supported .....................64
    7. Response Header Fields .........................................64
       7.1. Control Data ..............................................64
            7.1.1. Origination Date ...................................65
            7.1.2. Location ...........................................68
            7.1.3. Retry-After ........................................69
            7.1.4. Vary ...............................................70
       7.2. Validator Header Fields ...................................71
       7.3. Authentication Challenges .................................72
       7.4. Response Context ..........................................72
            7.4.1. Allow ..............................................72
            7.4.2. Server .............................................73
    8. IANA Considerations ............................................73
       8.1. Method Registry ...........................................73
            8.1.1. Procedure ..........................................74
            8.1.2. Considerations for New Methods .....................74
            8.1.3. Registrations ......................................75
       8.2. Status Code Registry ......................................75
            8.2.1. Procedure ..........................................75
            8.2.2. Considerations for New Status Codes ................76
            8.2.3. Registrations ......................................76
       8.3. Header Field Registry .....................................77
            8.3.1. Considerations for New Header Fields ...............78
            8.3.2. Registrations ......................................80
       8.4. Content Coding Registry ...................................81
            8.4.1. Procedure ..........................................81
            8.4.2. Registrations ......................................81
    9. Security Considerations ........................................81
       9.1. Attacks Based on File and Path Names ......................82
       9.2. Attacks Based on Command, Code, or Query Injection ........82
       9.3. Disclosure of Personal Information ........................83
       9.4. Disclosure of Sensitive Information in URIs ...............83
       9.5. Disclosure of Fragment after Redirects ....................84
       9.6. Disclosure of Product Information .........................84
       9.7. Browser Fingerprinting ....................................84
    10. Acknowledgments ...............................................85
    11. References ....................................................85
       11.1. Normative References .....................................85
       11.2. Informative References ...................................86
    Appendix A. Differences between HTTP and MIME .....................89
       A.1. MIME-Version ..............................................89
       A.2. Conversion to Canonical Form ..............................89
       A.3. Conversion of Date Formats ................................90
       A.4. Conversion of Content-Encoding ..........................90
       A.5. Conversion of Content-Transfer-Encoding .................90
       A.6. MHTML and Line Length Limitations .........................90
    Appendix B. Changes from RFC 2616 .................................91
    Appendix C. Imported ABNF .........................................93
    Appendix D. Collected ABNF ........................................94
    Index .............................................................97


Section 2., paragraph 3:
OLD:

    One design goal of HTTP is to separate resource identification from
    request semantics, which is made possible by vesting the request
    semantics in the request method (Section 4) and a few request-
    modifying header fields (Section 5).  If there is a conflict between
    the method semantics and any semantic implied by the URI itself, as
    described in Section 4.2.1, the method semantics take precedence.

NEW:

    One design goal of HTTP is to separate resource identification from
    request semantics, which is made possible by vesting the request
    semantics in the request method (Section 4) and a few
    request-modifying header fields (Section 5).  If there is a conflict
    between the method semantics and any semantic implied by the URI
    itself, as described in Section 4.2.1, the method semantics take
    precedence.


Section 3.1.3.1., paragraph 2:
OLD:

    HTTP uses language tags within the Accept-Language and Content-
    Language header fields.  Accept-Language uses the broader language-
    range production defined in Section 5.3.5, whereas Content-Language
    uses the language-tag production defined below.

NEW:

    HTTP uses language tags within the Accept-Language and
    Content-Language header fields.  Accept-Language uses the broader
    language-range production defined in Section 5.3.5, whereas
    Content-Language uses the language-tag production defined below.


Section 3.1.4.2., paragraph 6:
OLD:

    o  For a response to a GET or HEAD request, this is an indication
       that the effective request URI refers to a resource that is
       subject to content negotiation and the Content-Location field-
       value is a more specific identifier for the selected
       representation.

NEW:

    o  For a response to a GET or HEAD request, this is an indication
       that the effective request URI refers to a resource that is
       subject to content negotiation and the Content-Location
       field-value is a more specific identifier for the selected
       representation.


Section 4.1., paragraph 6:
OLD:

    This specification defines a number of standardized methods that are
    commonly used in HTTP, as outlined by the following table.  By
    convention, standardized methods are defined in all-uppercase US-
    ASCII letters.

NEW:

    This specification defines a number of standardized methods that are
    commonly used in HTTP, as outlined by the following table.  By
    convention, standardized methods are defined in all-uppercase
    US-ASCII letters.


Section 4.3.3., paragraph 8:
OLD:

    Responses to POST requests are only cacheable when they include
    explicit freshness information (see Section 4.2.1 of [RFC7234]).
    However, POST caching is not widely implemented.  For cases where an
    origin server wishes the client to be able to cache the result of a
    POST in a way that can be reused by a later GET, the origin server
    MAY send a 200 (OK) response containing the result and a Content-
    Location header field that has the same value as the POST's effective
    request URI (Section 3.1.4.2).

NEW:

    Responses to POST requests are only cacheable when they include
    explicit freshness information (see Section 4.2.1 of [RFC7234]).
    However, POST caching is not widely implemented.  For cases where an
    origin server wishes the client to be able to cache the result of a
    POST in a way that can be reused by a later GET, the origin server
    MAY send a 200 (OK) response containing the result and a
    Content-Location header field that has the same value as the POST's
    effective request URI (Section 3.1.4.2).


Section 5.1.1., paragraph 5:
OLD:

    A 100-continue expectation informs recipients that the client is
    about to send a (presumably large) message body in this request and
    wishes to receive a 100 (Continue) interim response if the request-
    line and header fields are not sufficient to cause an immediate
    success, redirect, or error response.  This allows the client to wait
    for an indication that it is worthwhile to send the message body
    before actually doing so, which can improve efficiency when the
    message body is huge or when the client anticipates that an error is
    likely (e.g., when sending a state-changing method, for the first
    time, without previously verified authentication credentials).

NEW:

    A 100-continue expectation informs recipients that the client is
    about to send a (presumably large) message body in this request and
    wishes to receive a 100 (Continue) interim response if the
    request-line and header fields are not sufficient to cause an
    immediate success, redirect, or error response.  This allows the
    client to wait for an indication that it is worthwhile to send the
    message body before actually doing so, which can improve efficiency
    when the message body is huge or when the client anticipates that an
    error is likely (e.g., when sending a state-changing method, for the
    first time, without previously verified authentication credentials).


Section 5.1.1., paragraph 19:
OLD:

    An origin server MUST, upon receiving an HTTP/1.1 (or later) request-
    line and a complete header section that contains a 100-continue
    expectation and indicates a request message body will follow, either
    send an immediate response with a final status code, if that status
    can be determined by examining just the request-line and header
    fields, or send an immediate 100 (Continue) response to encourage the
    client to send the request's message body.  The origin server MUST
    NOT wait for the message body before sending the 100 (Continue)
    response.

NEW:

    An origin server MUST, upon receiving an HTTP/1.1 (or later)
    request-line and a complete header section that contains a
    100-continue expectation and indicates a request message body will
    follow, either send an immediate response with a final status code,
    if that status can be determined by examining just the request-line
    and header fields, or send an immediate 100 (Continue) response to
    encourage the client to send the request's message body.  The origin
    server MUST NOT wait for the message body before sending the 100
    (Continue) response.


Section 5.3.2., paragraph 1:
OLD:

    The "Accept" header field can be used by user agents to specify
    response media types that are acceptable.  Accept header fields can
    be used to indicate that the request is specifically limited to a
    small set of desired types, as in the case of a request for an in-
    line image.

NEW:

    The "Accept" header field can be used by user agents to specify
    response media types that are acceptable.  Accept header fields can
    be used to indicate that the request is specifically limited to a
    small set of desired types, as in the case of a request for an
    in-line image.


Section 5.3.3., paragraph 5:
OLD:

    The special value "*", if present in the Accept-Charset field,
    matches every charset that is not mentioned elsewhere in the Accept-
    Charset field.  If no "*" is present in an Accept-Charset field, then
    any charsets not explicitly mentioned in the field are considered
    "not acceptable" to the client.

NEW:

    The special value "*", if present in the Accept-Charset field,
    matches every charset that is not mentioned elsewhere in the
    Accept-Charset field.  If no "*" is present in an Accept-Charset
    field, then any charsets not explicitly mentioned in the field are
    considered "not acceptable" to the client.


Section 2., paragraph 0:
OLD:

    2.  If the representation has no content-coding, then it is
        acceptable by default unless specifically excluded by the Accept-
        Encoding field stating either "identity;q=0" or "*;q=0" without a
        more specific entry for "identity".

NEW:

    2.  If the representation has no content-coding, then it is
        acceptable by default unless specifically excluded by the
        Accept-Encoding field stating either "identity;q=0" or "*;q=0"
        without a more specific entry for "identity".


Section 2., paragraph 1:
OLD:

    3.  If the representation's content-coding is one of the content-
        codings listed in the Accept-Encoding field, then it is
        acceptable unless it is accompanied by a qvalue of 0.  (As
        defined in Section 5.3.1, a qvalue of 0 means "not acceptable".)

NEW:

    3.  If the representation's content-coding is one of the
        content-codings listed in the Accept-Encoding field, then it is
        acceptable unless it is accompanied by a qvalue of 0.  (As
        defined in Section 5.3.1, a qvalue of 0 means "not acceptable".)


Section 5.3.5., paragraph 10:
OLD:

    Since intelligibility is highly dependent on the individual user,
    user agents need to allow user control over the linguistic preference
    (either through configuration of the user agent itself or by
    defaulting to a user controllable system setting).  A user agent that
    does not provide such control to the user MUST NOT send an Accept-
    Language header field.

NEW:

    Since intelligibility is highly dependent on the individual user,
    user agents need to allow user control over the linguistic preference
    (either through configuration of the user agent itself or by
    defaulting to a user controllable system setting).  A user agent that
    does not provide such control to the user MUST NOT send an
    Accept-Language header field.


Section 5.5.3., paragraph 5:
OLD:

    A sender SHOULD limit generated product identifiers to what is
    necessary to identify the product; a sender MUST NOT generate
    advertising or other nonessential information within the product
    identifier.  A sender SHOULD NOT generate information in product-
    version that is not a version identifier (i.e., successive versions
    of the same product name ought to differ only in the product-version
    portion of the product identifier).

NEW:

    A sender SHOULD limit generated product identifiers to what is
    necessary to identify the product; a sender MUST NOT generate
    advertising or other nonessential information within the product
    identifier.  A sender SHOULD NOT generate information in
    product-version that is not a version identifier (i.e., successive
    versions of the same product name ought to differ only in the
    product-version portion of the product identifier).


Section 6.1., paragraph 3:
OLD:

    +------+-------------------------------+--------------------------+
    | Code | Reason-Phrase                 | Defined in...            |
    +------+-------------------------------+--------------------------+
    | 100  | Continue                      | Section 6.2.1            |
    | 101  | Switching Protocols           | Section 6.2.2            |
    | 200  | OK                            | Section 6.3.1            |
    | 201  | Created                       | Section 6.3.2            |
    | 202  | Accepted                      | Section 6.3.3            |
    | 203  | Non-Authoritative Information | Section 6.3.4            |
    | 204  | No Content                    | Section 6.3.5            |
    | 205  | Reset Content                 | Section 6.3.6            |
    | 206  | Partial Content               | Section 4.1 of [RFC7233] |
    | 300  | Multiple Choices              | Section 6.4.1            |
    | 301  | Moved Permanently             | Section 6.4.2            |
    | 302  | Found                         | Section 6.4.3            |
    | 303  | See Other                     | Section 6.4.4            |
    | 304  | Not Modified                  | Section 4.1 of [RFC7232] |
    | 305  | Use Proxy                     | Section 6.4.5            |
    | 307  | Temporary Redirect            | Section 6.4.7            |
    | 400  | Bad Request                   | Section 6.5.1            |
    | 401  | Unauthorized                  | Section 3.1 of [RFC7235] |
    | 402  | Payment Required              | Section 6.5.2            |
    | 403  | Forbidden                     | Section 6.5.3            |
    | 404  | Not Found                     | Section 6.5.4            |
    | 405  | Method Not Allowed            | Section 6.5.5            |
    | 406  | Not Acceptable                | Section 6.5.6            |
    | 407  | Proxy Authentication Required | Section 3.2 of [RFC7235] |
    | 408  | Request Timeout               | Section 6.5.7            |
    | 409  | Conflict                      | Section 6.5.8            |
    | 410  | Gone                          | Section 6.5.9            |
    | 411  | Length Required               | Section 6.5.10           |
    | 412  | Precondition Failed           | Section 4.2 of [RFC7232] |
    | 413  | Payload Too Large             | Section 6.5.11           |
    | 414  | URI Too Long                  | Section 6.5.12           |
    | 415  | Unsupported Media Type        | Section 6.5.13           |
    | 416  | Range Not Satisfiable         | Section 4.4 of [RFC7233] |
    | 417  | Expectation Failed            | Section 6.5.14           |
    | 426  | Upgrade Required              | Section 6.5.15           |
    | 500  | Internal Server Error         | Section 6.6.1            |
    | 501  | Not Implemented               | Section 6.6.2            |
    | 502  | Bad Gateway                   | Section 6.6.3            |
    | 503  | Service Unavailable           | Section 6.6.4            |
    | 504  | Gateway Timeout               | Section 6.6.5            |
    | 505  | HTTP Version Not Supported    | Section 6.6.6            |
    +------+-------------------------------+--------------------------+
 
    Note that this list is not exhaustive -- it does not include
    extension status codes defined in other specifications.  The complete
    list of status codes is maintained by IANA.  See Section 8.2 for
    details.

NEW:

    +------+-------------------------------+--------------------------+
    | Code | Reason-Phrase                 | Defined in...            |
    +------+-------------------------------+--------------------------+
    | 100  | Continue                      | Section 6.2.1            |
    | 101  | Switching Protocols           | Section 6.2.2            |
    | 200  | OK                            | Section 6.3.1            |
    | 201  | Created                       | Section 6.3.2            |
    | 202  | Accepted                      | Section 6.3.3            |
    | 203  | Non-Authoritative Information | Section 6.3.4            |
    | 204  | No Content                    | Section 6.3.5            |
    | 205  | Reset Content                 | Section 6.3.6            |
    | 206  | Partial Content               | Section 4.1 of [RFC7233] |
    | 300  | Multiple Choices              | Section 6.4.1            |
    | 301  | Moved Permanently             | Section 6.4.2            |
    | 302  | Found                         | Section 6.4.3            |
    | 303  | See Other                     | Section 6.4.4            |
    | 304  | Not Modified                  | Section 4.1 of [RFC7232] |
    | 305  | Use Proxy                     | Section 6.4.5            |
    | 307  | Temporary Redirect            | Section 6.4.7            |
    | 400  | Bad Request                   | Section 6.5.1            |
    | 401  | Unauthorized                  | Section 3.1 of [RFC7235] |
    | 402  | Payment Required              | Section 6.5.2            |
    | 403  | Forbidden                     | Section 6.5.3            |
    | 404  | Not Found                     | Section 6.5.4            |
    | 405  | Method Not Allowed            | Section 6.5.5            |
    | 406  | Not Acceptable                | Section 6.5.6            |
    | 407  | Proxy Authentication Required | Section 3.2 of [RFC7235] |
    | 408  | Request Timeout               | Section 6.5.7            |
    | 409  | Conflict                      | Section 6.5.8            |
    | 410  | Gone                          | Section 6.5.9            |
    | 411  | Length Required               | Section 6.5.10           |
    | 412  | Precondition Failed           | Section 4.2 of [RFC7232] |
    | 413  | Payload Too Large             | Section 6.5.11           |
    | 414  | URI Too Long                  | Section 6.5.12           |
    | 415  | Unsupported Media Type        | Section 6.5.13           |
    | 416  | Range Not Satisfiable         | Section 4.4 of [RFC7233] |
    | 417  | Expectation Failed            | Section 6.5.14           |
    | 426  | Upgrade Required              | Section 6.5.15           |
    | 500  | Internal Server Error         | Section 6.6.1            |
    | 501  | Not Implemented               | Section 6.6.2            |
    | 502  | Bad Gateway                   | Section 6.6.3            |
    | 503  | Service Unavailable           | Section 6.6.4            |
    | 504  | Gateway Timeout               | Section 6.6.5            |
    | 505  | HTTP Version Not Supported    | Section 6.6.6            |
    +------+-------------------------------+--------------------------+
    Note that this list is not exhaustive -- it does not include
    extension status codes defined in other specifications.  The complete
    list of status codes is maintained by IANA.  See Section 8.2 for
    details.


Section 6.2.1., paragraph 2:
OLD:

    When the request contains an Expect header field that includes a 100-
    continue expectation, the 100 response indicates that the server
    wishes to receive the request payload body, as described in
    Section 5.1.1.  The client ought to continue sending the request and
    discard the 100 response.

NEW:

    When the request contains an Expect header field that includes a
    100-continue expectation, the 100 response indicates that the server
    wishes to receive the request payload body, as described in
    Section 5.1.1.  The client ought to continue sending the request and
    discard the 100 response.


Section 6.3.2., paragraph 2:
OLD:

    The 201 response payload typically describes and links to the
    resource(s) created.  See Section 7.2 for a discussion of the meaning
    and purpose of validator header fields, such as ETag and Last-
    Modified, in a 201 response.

NEW:

    The 201 response payload typically describes and links to the
    resource(s) created.  See Section 7.2 for a discussion of the meaning
    and purpose of validator header fields, such as ETag and
    Last-Modified, in a 201 response.


Section 6.5.11., paragraph 2:
OLD:

    If the condition is temporary, the server SHOULD generate a Retry-
    After header field to indicate that it is temporary and after what
    time the client MAY try again.

NEW:

    If the condition is temporary, the server SHOULD generate a
    Retry-After header field to indicate that it is temporary and after
    what time the client MAY try again.


Section 6.5.13., paragraph 1:
OLD:

    The 415 (Unsupported Media Type) status code indicates that the
    origin server is refusing to service the request because the payload
    is in a format not supported by this method on the target resource.
    The format problem might be due to the request's indicated Content-
    Type or Content-Encoding, or as a result of inspecting the data
    directly.

NEW:

    The 415 (Unsupported Media Type) status code indicates that the
    origin server is refusing to service the request because the payload
    is in a format not supported by this method on the target resource.
    The format problem might be due to the request's indicated
    Content-Type or Content-Encoding, or as a result of inspecting the
    data directly.


Section 7., paragraph 1:
OLD:

    The response header fields allow the server to pass additional
    information about the response beyond what is placed in the status-
    line.  These header fields give information about the server, about
    further access to the target resource, or about related resources.

NEW:

    The response header fields allow the server to pass additional
    information about the response beyond what is placed in the
    status-line.  These header fields give information about the server,
    about further access to the target resource, or about related
    resources.


Section 7.1.1.1., paragraph 7:
OLD:

    A recipient that parses a timestamp value in an HTTP header field
    MUST accept all three HTTP-date formats.  When a sender generates a
    header field that contains one or more timestamps defined as HTTP-
    date, the sender MUST generate those timestamps in the IMF-fixdate
    format.

NEW:

    A recipient that parses a timestamp value in an HTTP header field
    MUST accept all three HTTP-date formats.  When a sender generates a
    header field that contains one or more timestamps defined as
    HTTP-date, the sender MUST generate those timestamps in the
    IMF-fixdate format.


Section 7.1.1.1., paragraph 18:
OLD:

      obs-date     = rfc850-date / asctime-date
      rfc850-date  = day-name-l "," SP date2 SP time-of-day SP GMT
      date2        = day "-" month "-" 2DIGIT
                   ; e.g., 02-Jun-82

NEW:

      obs-date     = rfc850-date / asctime-date
 
      rfc850-date  = day-name-l "," SP date2 SP time-of-day SP GMT
      date2        = day "-" month "-" 2DIGIT
                   ; e.g., 02-Jun-82


Section 7.1.1.1., paragraph 21:
OLD:

    HTTP-date is case sensitive.  A sender MUST NOT generate additional
    whitespace in an HTTP-date beyond that specifically included as SP in
    the grammar.  The semantics of day-name, day, month, year, and time-
    of-day are the same as those defined for the Internet Message Format
    constructs with the corresponding name ([RFC5322], Section 3.3).

NEW:

    HTTP-date is case sensitive.  A sender MUST NOT generate additional
    whitespace in an HTTP-date beyond that specifically included as SP in
    the grammar.  The semantics of day-name, day, month, year, and
    time-of-day are the same as those defined for the Internet Message
    Format constructs with the corresponding name ([RFC5322], Section
    3.3).


Section 7.1.1.1., paragraph 23:
OLD:

    Recipients of timestamp values are encouraged to be robust in parsing
    timestamps unless otherwise restricted by the field definition.  For
    example, messages are occasionally forwarded over HTTP from a non-
    HTTP source that might generate any of the date and time
    specifications defined by the Internet Message Format.

NEW:

    Recipients of timestamp values are encouraged to be robust in parsing
    timestamps unless otherwise restricted by the field definition.  For
    example, messages are occasionally forwarded over HTTP from a
    non-HTTP source that might generate any of the date and time
    specifications defined by the Internet Message Format.


Section 7.1.2., paragraph 8:
OLD:

    which suggests that the user agent redirect to
    "http://www.example.org/People.html#tim"
 
    Likewise, a GET request generated for the URI reference
    "http://www.example.org/index.html#larry" might result in a 301
    (Moved Permanently) response containing the header field:

NEW:

    which suggests that the user agent redirect to
    "http://www.example.org/People.html#tim"
    Likewise, a GET request generated for the URI reference
    "http://www.example.org/index.html#larry" might result in a 301
    (Moved Permanently) response containing the header field:


Section 7.1.4., paragraph 1:
OLD:

    The "Vary" header field in a response describes what parts of a
    request message, aside from the method, Host header field, and
    request target, might influence the origin server's process for
    selecting and representing this response.  The value consists of
    either a single asterisk ("*") or a list of header field names (case-
    insensitive).

NEW:

    The "Vary" header field in a response describes what parts of a
    request message, aside from the method, Host header field, and
    request target, might influence the origin server's process for
    selecting and representing this response.  The value consists of
    either a single asterisk ("*") or a list of header field names
    (case-insensitive).


Section 8.1., paragraph 0:
OLD:

 8.  IANA Considerations
 8.1.  Method Registry

NEW:

 8.  IANA Considerations
 
 8.1.  Method Registry


Section 8.3.1., paragraph 6:
OLD:

    Because commas (",") are used as a generic delimiter between field-
    values, they need to be treated with care if they are allowed in the
    field-value.  Typically, components that might contain a comma are
    protected with double-quotes using the quoted-string ABNF production.

NEW:

    Because commas (",") are used as a generic delimiter between
    field-values, they need to be treated with care if they are allowed
    in the field-value.  Typically, components that might contain a comma
    are protected with double-quotes using the quoted-string ABNF
    production.


Section 8.3.1., paragraph 9:
OLD:

    Note that double-quote delimiters almost always are used with the
    quoted-string production; using a different syntax inside double-
    quotes will likely cause unnecessary confusion.

NEW:

    Note that double-quote delimiters almost always are used with the
    quoted-string production; using a different syntax inside
    double-quotes will likely cause unnecessary confusion.


Section 8.3.1., paragraph 10:
OLD:

    Many header fields use a format including (case-insensitively) named
    parameters (for instance, Content-Type, defined in Section 3.1.1.5).
 
    Allowing both unquoted (token) and quoted (quoted-string) syntax for
    the parameter value enables recipients to use existing parser
    components.  When allowing both forms, the meaning of a parameter
    value ought to be independent of the syntax used for it (for an
    example, see the notes on parameter handling for media types in
    Section 3.1.1.1).

NEW:

    Many header fields use a format including (case-insensitively) named
    parameters (for instance, Content-Type, defined in Section 3.1.1.5).
    Allowing both unquoted (token) and quoted (quoted-string) syntax for
    the parameter value enables recipients to use existing parser
    components.  When allowing both forms, the meaning of a parameter
    value ought to be independent of the syntax used for it (for an
    example, see the notes on parameter handling for media types in
    Section 3.1.1.1).


Section 9.4., paragraph 2:
OLD:

    Authors of services ought to avoid GET-based forms for the submission
    of sensitive data because that data will be placed in the request-
    target.  Many existing servers, proxies, and user agents log or
    display the request-target in places where it might be visible to
    third parties.  Such services ought to use POST-based form submission
    instead.

NEW:

    Authors of services ought to avoid GET-based forms for the submission
    of sensitive data because that data will be placed in the
    request-target.  Many existing servers, proxies, and user agents log
    or display the request-target in places where it might be visible to
    third parties.  Such services ought to use POST-based form submission
    instead.


Section 9.7., paragraph 4:
OLD:

    In addition to the fingerprinting concern, detailed use of the
    Accept-Language header field can reveal information the user might
    consider to be of a private nature.  For example, understanding a
    given language set might be strongly correlated to membership in a
    particular ethnic group.  An approach that limits such loss of
    privacy would be for a user agent to omit the sending of Accept-
    Language except for sites that have been whitelisted, perhaps via
    interaction after detecting a Vary header field that indicates
    language negotiation might be useful.

NEW:

    In addition to the fingerprinting concern, detailed use of the
    Accept-Language header field can reveal information the user might
    consider to be of a private nature.  For example, understanding a
    given language set might be strongly correlated to membership in a
    particular ethnic group.  An approach that limits such loss of
    privacy would be for a user agent to omit the sending of
    Accept-Language except for sites that have been whitelisted, perhaps
    via interaction after detecting a Vary header field that indicates
    language negotiation might be useful.


Section 11.1., paragraph 9:
OLD:

    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
               Protocol (HTTP/1.1): Message Syntax and Routing",
               draft-ietf-httpbis-p1-messaging-latest (work in progress),
               June 2014.

NEW:

    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
               Protocol (HTTP/1.1): Message Syntax and Routing",
               RFC 7230, June 2014.


Section 11.1., paragraph 10:
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 11:
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 12:
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 13:
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 11.2., paragraph 25:
OLD:

    [RFC7238]  Reschke, J., "The Hypertext Transfer Protocol (HTTP)
               Status Code 308 (Permanent Redirect)",
               draft-reschke-http-status-308-07 (work in progress),
               March 2012.

NEW:

    [RFC7238]  Reschke, J., "The Hypertext Transfer Protocol (HTTP)
               Status Code 308 (Permanent Redirect)", RFC 7238,
               June 2014.


Appendix A., paragraph 4:
OLD:

    HTTP is not a MIME-compliant protocol.  However, messages can include
    a single MIME-Version header field to indicate what version of the
    MIME protocol was used to construct the message.  Use of the MIME-
    Version header field indicates that the message is in full
    conformance with the MIME protocol (as defined in [RFC2045]).
    Senders are responsible for ensuring full conformance (where
    possible) when exporting HTTP messages to strict MIME environments.

NEW:

    HTTP is not a MIME-compliant protocol.  However, messages can include
    a single MIME-Version header field to indicate what version of the
    MIME protocol was used to construct the message.  Use of the
    MIME-Version header field indicates that the message is in full
    conformance with the MIME protocol (as defined in [RFC2045]).
    Senders are responsible for ensuring full conformance (where
    possible) when exporting HTTP messages to strict MIME environments.


Appendix A., paragraph 12:
OLD:

    MIME does not include any concept equivalent to HTTP/1.1's Content-
    Encoding header field.  Since this acts as a modifier on the media
    type, proxies and gateways from HTTP to MIME-compliant protocols
    ought to either change the value of the Content-Type header field or
    decode the representation before forwarding the message.  (Some
    experimental applications of Content-Type for Internet mail have used
    a media-type parameter of ";conversions=<content-coding>" to perform
    a function equivalent to Content-Encoding.  However, this parameter
    is not part of the MIME standards).

NEW:

    MIME does not include any concept equivalent to HTTP/1.1's
    Content-Encoding header field.  Since this acts as a modifier on the
    media type, proxies and gateways from HTTP to MIME-compliant
    protocols ought to either change the value of the Content-Type header
    field or decode the representation before forwarding the message.
    (Some experimental applications of Content-Type for Internet mail
    have used a media-type parameter of ";conversions=<content-coding>"
    to perform a function equivalent to Content-Encoding.  However, this
    parameter is not part of the MIME standards).


Appendix B., paragraph 2:
OLD:

    A new requirement has been added that semantics embedded in a URI be
    disabled when those semantics are inconsistent with the request
    method, since this is a common cause of interoperability failure.
 
    (Section 2)

NEW:

    A new requirement has been added that semantics embedded in a URI be
    disabled when those semantics are inconsistent with the request
    method, since this is a common cause of interoperability failure.
    (Section 2)


Appendix B., paragraph 9:
OLD:

    The OPTIONS and TRACE request methods have been defined as being
    safe.  (Section 4.3.7 and Section 4.3.8)
 
    The Expect header field's extension mechanism has been removed due to
    widely-deployed broken implementations.  (Section 5.1.1)

NEW:

    The OPTIONS and TRACE request methods have been defined as being
    safe.  (Section 4.3.7 and Section 4.3.8)
    The Expect header field's extension mechanism has been removed due to
    widely-deployed broken implementations.  (Section 5.1.1)


Appendix B., paragraph 20:
OLD:

    The 426 (Upgrade Required) status code has been incorporated from
    [RFC2817].  (Section 6.5.15)
 
    The target of requirements on HTTP-date and the Date header field
    have been reduced to those systems generating the date, rather than
    all systems sending a date.  (Section 7.1.1)

NEW:

    The 426 (Upgrade Required) status code has been incorporated from
    [RFC2817].  (Section 6.5.15)
    The target of requirements on HTTP-date and the Date header field
    have been reduced to those systems generating the date, rather than
    all systems sending a date.  (Section 7.1.1)


Appendix B., paragraph 24:
OLD:

    The Status Code Registry has been redefined by this specification;
    previously, it was defined in Section 7.1 of [RFC2817].
 
    (Section 8.2)

NEW:

    The Status Code Registry has been redefined by this specification;
    previously, it was defined in Section 7.1 of [RFC2817].
    (Section 8.2)


Section 1.2, paragraph 1:
OLD:

    Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
     OWS ( media-range [ accept-params ] ) ] ) ]
    Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS
     "," [ OWS ( ( charset / "*" ) [ weight ] ) ] )
    Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS
     ( codings [ weight ] ) ] ) ]
    Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS
     "," [ OWS ( language-range [ weight ] ) ] )
    Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ]
    BWS = <BWS, see [RFC7230], Section 3.2.3>

NEW:

    Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
     OWS ( media-range [ accept-params ] ) ] ) ]
    Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS
     "," [ OWS ( ( charset / "*" ) [ weight ] ) ] )
    Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS
     ( codings [ weight ] ) ] ) ]
    Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS
     "," [ OWS ( language-range [ weight ] ) ] )
    Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ]
 
    BWS = <BWS, see [RFC7230], Section 3.2.3>


Section 1.2, paragraph 12:
OLD:

    RWS = <RWS, see [RFC7230], Section 3.2.3>
    Referer = absolute-URI / partial-URI
    Retry-After = HTTP-date / delay-seconds
 
    Server = product *( RWS ( product / comment ) )

NEW:

    RWS = <RWS, see [RFC7230], Section 3.2.3>
    Referer = absolute-URI / partial-URI
    Retry-After = HTTP-date / delay-seconds
    Server = product *( RWS ( product / comment ) )


Section 1.2, paragraph 16:
OLD:

    charset = token
    codings = content-coding / "identity" / "*"
    comment = <comment, see [RFC7230], Section 3.2.6>
    content-coding = token
    date1 = day SP month SP year
    date2 = day "-" month "-" 2DIGIT
    date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
    day = 2DIGIT
    day-name = %x4D.6F.6E ; Mon
     / %x54.75.65 ; Tue
     / %x57.65.64 ; Wed
     / %x54.68.75 ; Thu
     / %x46.72.69 ; Fri
     / %x53.61.74 ; Sat
     / %x53.75.6E ; Sun
    day-name-l = %x4D.6F.6E.64.61.79 ; Monday
     / %x54.75.65.73.64.61.79 ; Tuesday
     / %x57.65.64.6E.65.73.64.61.79 ; Wednesday
     / %x54.68.75.72.73.64.61.79 ; Thursday
     / %x46.72.69.64.61.79 ; Friday
     / %x53.61.74.75.72.64.61.79 ; Saturday
     / %x53.75.6E.64.61.79 ; Sunday
    delay-seconds = 1*DIGIT

NEW:

    charset = token
    codings = content-coding / "identity" / "*"
    comment = <comment, see [RFC7230], Section 3.2.6>
    content-coding = token
 
    date1 = day SP month SP year
    date2 = day "-" month "-" 2DIGIT
    date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
    day = 2DIGIT
    day-name = %x4D.6F.6E ; Mon
     / %x54.75.65 ; Tue
     / %x57.65.64 ; Wed
     / %x54.68.75 ; Thu
     / %x46.72.69 ; Fri
     / %x53.61.74 ; Sat
     / %x53.75.6E ; Sun
    day-name-l = %x4D.6F.6E.64.61.79 ; Monday
     / %x54.75.65.73.64.61.79 ; Tuesday
     / %x57.65.64.6E.65.73.64.61.79 ; Wednesday
     / %x54.68.75.72.73.64.61.79 ; Thursday
     / %x46.72.69.64.61.79 ; Friday
     / %x53.61.74.75.72.64.61.79 ; Saturday
     / %x53.75.6E.64.61.79 ; Sunday
    delay-seconds = 1*DIGIT


Section 1.2, paragraph 20:
OLD:

    mailbox = <mailbox, see [RFC5322], Section 3.4>
    media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS
     ";" OWS parameter )
    media-type = type "/" subtype *( OWS ";" OWS parameter )
    method = token
    minute = 2DIGIT
    month = %x4A.61.6E ; Jan
     / %x46.65.62 ; Feb
     / %x4D.61.72 ; Mar
     / %x41.70.72 ; Apr
     / %x4D.61.79 ; May
     / %x4A.75.6E ; Jun
     / %x4A.75.6C ; Jul
     / %x41.75.67 ; Aug
     / %x53.65.70 ; Sep
     / %x4F.63.74 ; Oct
     / %x4E.6F.76 ; Nov
     / %x44.65.63 ; Dec

NEW:

    mailbox = <mailbox, see [RFC5322], Section 3.4>
    media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS
     ";" OWS parameter )
 
    media-type = type "/" subtype *( OWS ";" OWS parameter )
    method = token
    minute = 2DIGIT
    month = %x4A.61.6E ; Jan
     / %x46.65.62 ; Feb
     / %x4D.61.72 ; Mar
     / %x41.70.72 ; Apr
     / %x4D.61.79 ; May
     / %x4A.75.6E ; Jun
     / %x4A.75.6C ; Jul
     / %x41.75.67 ; Aug
     / %x53.65.70 ; Sep
     / %x4F.63.74 ; Oct
     / %x4E.6F.76 ; Nov
     / %x44.65.63 ; Dec


Section 1.2, paragraph 21:
OLD:

    obs-date = rfc850-date / asctime-date
    parameter = token "=" ( token / quoted-string )
    partial-URI = <partial-URI, see [RFC7230], Section 2.7>
    product = token [ "/" product-version ]
    product-version = token
 
    quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
    qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )

NEW:

    obs-date = rfc850-date / asctime-date
 
    parameter = token "=" ( token / quoted-string )
    partial-URI = <partial-URI, see [RFC7230], Section 2.7>
    product = token [ "/" product-version ]
    product-version = token
    quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
    qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )


Section 1.2, paragraph 34:
OLD:

    2
       200 OK (status code)  51
       201 Created (status code)  51
       202 Accepted (status code)  52
       203 Non-Authoritative Information (status code)  52
       204 No Content (status code)  53
       205 Reset Content (status code)  53

NEW:

    2
       200 OK (status code)  51
       201 Created (status code)  52
       202 Accepted (status code)  52
       203 Non-Authoritative Information (status code)  52
       204 No Content (status code)  53
       205 Reset Content (status code)  53


Section 1.2, paragraph 35:
OLD:

    3
       300 Multiple Choices (status code)  55
       301 Moved Permanently (status code)  56
       302 Found (status code)  56
       303 See Other (status code)  57
       305 Use Proxy (status code)  57
       306 (Unused) (status code)  57
       307 Temporary Redirect (status code)  58

NEW:

    3
       300 Multiple Choices (status code)  55
       301 Moved Permanently (status code)  56
       302 Found (status code)  56
       303 See Other (status code)  57
       305 Use Proxy (status code)  58
       306 (Unused) (status code)  58
       307 Temporary Redirect (status code)  58


Section 1.2, paragraph 36:
OLD:

    4
       400 Bad Request (status code)  58
       402 Payment Required (status code)  58
       403 Forbidden (status code)  58
       404 Not Found (status code)  59
       405 Method Not Allowed (status code)  59
       406 Not Acceptable (status code)  59
       408 Request Timeout (status code)  60
       409 Conflict (status code)  60
       410 Gone (status code)  60
       411 Length Required (status code)  61
       413 Payload Too Large (status code)  61
       414 URI Too Long (status code)  61
       415 Unsupported Media Type (status code)  61
       417 Expectation Failed (status code)  62
       426 Upgrade Required (status code)  62

NEW:

    4
       400 Bad Request (status code)  58
       402 Payment Required (status code)  59
       403 Forbidden (status code)  59
       404 Not Found (status code)  59
       405 Method Not Allowed (status code)  59
       406 Not Acceptable (status code)  59
       408 Request Timeout (status code)  60
       409 Conflict (status code)  60
       410 Gone (status code)  60
       411 Length Required (status code)  61
       413 Payload Too Large (status code)  61
       414 URI Too Long (status code)  61
       415 Unsupported Media Type (status code)  62
       417 Expectation Failed (status code)  62
       426 Upgrade Required (status code)  62


Section 1.2, paragraph 37:
OLD:

    5
       500 Internal Server Error (status code)  62
       501 Not Implemented (status code)  63
       502 Bad Gateway (status code)  63
       503 Service Unavailable (status code)  63
       504 Gateway Timeout (status code)  63
       505 HTTP Version Not Supported (status code)  63

NEW:

    5
       500 Internal Server Error (status code)  63
       501 Not Implemented (status code)  63
       502 Bad Gateway (status code)  63
       503 Service Unavailable (status code)  63
       504 Gateway Timeout (status code)  63
       505 HTTP Version Not Supported (status code)  64


Section 1.2, paragraph 39:
OLD:

    C
       cacheable  24
       compress (content coding)  11
       conditional request  36
       CONNECT method  30
       content coding  11
       content negotiation  6
       Content-Encoding header field  12
       Content-Language header field  13
       Content-Location header field  15
       Content-Transfer-Encoding header field  90
       Content-Type header field  10

NEW:

    C
       cacheable  24
       compress (content coding)  11
       conditional request  36
       CONNECT method  30
       content coding  11
       content negotiation  6
       Content-Encoding header field  12
       Content-Language header field  13
       Content-Location header field  15
       Content-Transfer-Encoding header field  89
       Content-Type header field  10


Section 1.2, paragraph 43:
OLD:

    G
       GET method  24
       Grammar
          Accept  38
          Accept-Charset  40
          Accept-Encoding  41
          accept-ext  38
          Accept-Language  42
          accept-params  38
          Allow  72
          asctime-date  67
          charset  9
          codings  41
          content-coding  11
          Content-Encoding  12
          Content-Language  13
          Content-Location  15
          Content-Type  10
          Date  67
          date1  66
          day  66
          day-name  66
          day-name-l  66
          delay-seconds  70
          Expect  34
          From  44
          GMT  66
          hour  66
          HTTP-date  64
          IMF-fixdate  66
          language-range  42
          language-tag  13
          Location  68
          Max-Forwards  36
          media-range  38
          media-type  8
          method  21
          minute  66
          month  66
          obs-date  66
          parameter  8
          product  46
          product-version  46
          qvalue  38
          Referer  45
          Retry-After  70
          rfc850-date  67
          second  66
          Server  73
          subtype  8
          time-of-day  66
          type  8
          User-Agent  46
          Vary  70
          weight  38
          year  66
       gzip (content coding)  11

NEW:

    G
       GET method  24
       Grammar
          Accept  38
          Accept-Charset  40
          Accept-Encoding  41
          accept-ext  38
          Accept-Language  42
          accept-params  38
          Allow  72
          asctime-date  66
          charset  9
          codings  41
          content-coding  11
          Content-Encoding  12
          Content-Language  13
          Content-Location  15
          Content-Type  10
          Date  67
          date1  65
          day  65
          day-name  65
          day-name-l  65
          delay-seconds  69
          Expect  34
          From  44
          GMT  65
          hour  65
          HTTP-date  65
          IMF-fixdate  65
          language-range  42
          language-tag  13
          Location  68
          Max-Forwards  36
          media-range  38
          media-type  8
          method  21
          minute  65
          month  65
          obs-date  66
          parameter  8
          product  46
          product-version  46
          qvalue  38
          Referer  45
          Retry-After  69
          rfc850-date  66
          second  65
          Server  73
          subtype  8
          time-of-day  65
          type  8
          User-Agent  46
          Vary  70
          weight  38
          year  65
       gzip (content coding)  11


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

