source: draft-ietf-httpbis/latest/auth48/rfc7231.abdiff.txt @ 2654

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                             May 7, 2014
 Expires: November 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                                       May 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 November 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.


Section 11., paragraph 0:
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
 
    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  . . . . . . . . . . . . . . . . . . . . . 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  . . . . . . . . . . . . . . . . . . . . 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:

    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 . . . . . . . . . . . . . . . . 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  . . . . . . . . . . . . . . . . . . . . . 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  . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . 88
      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


Section 2., paragraph 1:
OLD:

    The target of an HTTP request is called a resource.  HTTP does not
    limit the nature of a resource; it merely defines an interface that
    might be used to interact with resources.  Each resource is
    identified by a Uniform Resource Identifier (URI), as described in
    Section 2.7 of [RFC7230].

NEW:

    The target of an HTTP request is called a "resource".  HTTP does not
    limit the nature of a resource; it merely defines an interface that
    might be used to interact with resources.  Each resource is
    identified by a Uniform Resource Identifier (URI), as described in
    Section 2.7 of [RFC7230].


Section 3.1.1.1., paragraph 1:
OLD:

    HTTP uses Internet Media Types [RFC2046] in the Content-Type
    (Section 3.1.1.5) and Accept (Section 5.3.2) header fields in order
    to provide open and extensible data typing and type negotiation.
    Media types define both a data format and various processing models:
    how to process that data in accordance with each context in which it
    is received.

NEW:

    HTTP uses Internet media types [RFC2046] in the Content-Type
    (Section 3.1.1.5) and Accept (Section 5.3.2) header fields in order
    to provide open and extensible data typing and type negotiation.
    Media types define both a data format and various processing models:
    how to process that data in accordance with each context in which it
    is received.


Section 3.1.1.1., paragraph 5:
OLD:

    The type, subtype, and parameter name tokens are case-insensitive.
    Parameter values might or might not be case-sensitive, depending on
    the semantics of the parameter name.  The presence or absence of a
    parameter might be significant to the processing of a media-type,
    depending on its definition within the media type registry.

NEW:

    The type, subtype, and parameter name tokens are case insensitive.
    Parameter values might or might not be case sensitive, depending on
    the semantics of the parameter name.  The presence or absence of a
    parameter might be significant to the processing of a media-type,
    depending on its definition within the media type registry.


Section 3.1.1.2., paragraph 3:
OLD:

    Charset names ought to be registered in the IANA Character Set
    registry (<http://www.iana.org/assignments/character-sets>) according
    to the procedures defined in [RFC2978].

NEW:

    Charset names ought to be registered in the IANA "Character Sets"
    registry <http://www.iana.org/assignments/character-sets> according
    to the procedures defined in [RFC2978].


Section 3.1.1.3., paragraph 2:
OLD:

    MIME's canonical form requires that media subtypes of the "text" type
    use CRLF as the text line break.  HTTP allows the transfer of text
    media with plain CR or LF alone representing a line break, when such
    line breaks are consistent for an entire representation.  An HTTP
    sender MAY generate, and a recipient MUST be able to parse, line
    breaks in text media that consist of CRLF, bare CR, or bare LF.  In
    addition, text media in HTTP is not limited to charsets that use
    octets 13 and 10 for CR and LF, respectively.  This flexibility
    regarding line breaks applies only to text within a representation
    that has been assigned a "text" media type; it does not apply to
    "multipart" types or HTTP elements outside the payload body (e.g.,
    header fields).

NEW:

    MIME's canonical form requires that media subtypes of the "text" type
    use CRLF as the text line break.  HTTP allows the transfer of text
    media with plain carriage return (CR) or line feed (LF) alone
    representing a line break, when such line breaks are consistent for
    an entire representation.  An HTTP sender MAY generate, and a
    recipient MUST be able to parse, line breaks in text media that
    consist of CRLF, bare CR, or bare LF.  In addition, text media in
    HTTP is not limited to charsets that use octets 13 and 10 for CR and
    LF, respectively.  This flexibility regarding line breaks applies
    only to text within a representation that has been assigned a "text"
    media type; it does not apply to "multipart" types or HTTP elements
    outside the payload body (e.g., header fields).


Section 3.1.2.1., paragraph 3:
OLD:

    All content-coding values are case-insensitive and ought to be
    registered within the HTTP Content Coding registry, as defined in
    Section 8.4.  They are used in the Accept-Encoding (Section 5.3.4)
    and Content-Encoding (Section 3.1.2.2) header fields.

NEW:

    All content-coding values are case insensitive and ought to be
    registered within the "HTTP Content Coding Registry", as defined in
    Section 8.4.  They are used in the Accept-Encoding (Section 5.3.4)
    and Content-Encoding (Section 3.1.2.2) header fields.


Section 3.1.3.2., paragraph 5:
OLD:

    If no Content-Language is specified, the default is that the content
    is intended for all language audiences.  This might mean that the
    sender does not consider it to be specific to any natural language,
    or that the sender does not know for which language it is intended.

NEW:

    If no Content-Language is specified, the default is that the content
    is intended for all language audiences.  This might mean that the
    sender does not consider it to be specific to any natural language,
    or that the sender does not know which language is being used.


Section 3.4.1., paragraph 2:
OLD:

    Proactive negotiation is advantageous when the algorithm for
    selecting from among the available representations is difficult to
    describe to a user agent, or when the server desires to send its
    "best guess" to the user agent along with the first response (hoping
    to avoid the round trip delay of a subsequent request if the "best
    guess" is good enough for the user).  In order to improve the
    server's guess, a user agent MAY send request header fields that
    describe its preferences.

NEW:

    Proactive negotiation is advantageous when the algorithm for
    selecting from among the available representations is difficult to
    describe to a user agent, or when the server desires to send its
    "best guess" to the user agent along with the first response (hoping
    to avoid the round-trip delay of a subsequent request if the "best
    guess" is good enough for the user).  In order to improve the
    server's guess, a user agent MAY send request header fields that
    describe its preferences.


Section 4.1., paragraph 4:
OLD:

    HTTP was originally designed to be usable as an interface to
    distributed object systems.  The request method was envisioned as
    applying semantics to a target resource in much the same way as
    invoking a defined method on an identified object would apply
    semantics.  The method token is case-sensitive because it might be
    used as a gateway to object-based systems with case-sensitive method
    names.

NEW:

    HTTP was originally designed to be usable as an interface to
    distributed object systems.  The request method was envisioned as
    applying semantics to a target resource in much the same way as
    invoking a defined method on an identified object would apply
    semantics.  The method token is case sensitive because it might be
    used as a gateway to object-based systems with case-sensitive method
    names.


Section 4.1., paragraph 5:
OLD:

    Unlike distributed objects, the standardized request methods in HTTP
    are not resource-specific, since uniform interfaces provide for
    better visibility and reuse in network-based systems [REST].  Once
    defined, a standardized method ought to have the same semantics when
    applied to any resource, though each resource determines for itself
    whether those semantics are implemented or allowed.

NEW:

    Unlike distributed objects, the standardized request methods in HTTP
    are not resource specific, since uniform interfaces provide for
    better visibility and reuse in network-based systems [REST].  Once
    defined, a standardized method ought to have the same semantics when
    applied to any resource, though each resource determines for itself
    whether those semantics are implemented or allowed.


Section 4.1., paragraph 9:
OLD:

    Additional methods, outside the scope of this specification, have
    been standardized for use in HTTP.  All such methods ought to be
    registered within the HTTP Method Registry maintained by IANA, as
    defined in Section 8.1.

NEW:

    Additional methods, outside the scope of this specification, have
    been standardized for use in HTTP.  All such methods ought to be
    registered within the "Hypertext Transfer Protocol (HTTP) Method"
    registry maintained by IANA, as defined in Section 8.1.


Section 4.2.1., paragraph 2:
OLD:

    This definition of safe methods does not prevent an implementation
    from including behavior that is potentially harmful, not entirely
    read-only, or which causes side effects while invoking a safe method.
    What is important, however, is that the client did not request that
    additional behavior and cannot be held accountable for it.  For
    example, most servers append request information to access log files
    at the completion of every response, regardless of the method, and
    that is considered safe even though the log storage might become full
    and crash the server.  Likewise, a safe request initiated by
    selecting an advertisement on the Web will often have the side effect
    of charging an advertising account.

NEW:

    This definition of safe method does not prevent an implementation
    from including behavior that is potentially harmful, that is not
    entirely read-only, or that causes side effects while invoking a safe
    method.  What is important, however, is that the client did not
    request that additional behavior and cannot be held accountable for
    it.  For example, most servers append request information to access
    log files at the completion of every response, regardless of the
    method, and that is considered safe even though the log storage might
    become full and crash the server.  Likewise, a safe request initiated
    by selecting an advertisement on the Web will often have the side
    effect of charging an advertising account.


Section 4.3.3., paragraph 6:
OLD:

    An origin server indicates response semantics by choosing an
    appropriate status code depending on the result of processing the
    POST request; almost all of the status codes defined by this
    specification might be received in a response to POST (the exceptions
    being 206, 304, and 416).

NEW:

    An origin server indicates response semantics by choosing an
    appropriate status code depending on the result of processing the
    POST request; almost all of the status codes defined by this
    specification might be received in a response to POST (the exceptions
    being 206 (Partial Content), 304 (Not Modified), and 416 (Range Not
    Satisfiable)).


Section 4.3.6., paragraph 2:
OLD:

    CONNECT is intended only for use in requests to a proxy.  An origin
    server that receives a CONNECT request for itself MAY respond with a
    2xx status code to indicate that a connection is established.
    However, most origin servers do not implement CONNECT.

NEW:

    CONNECT is intended only for use in requests to a proxy.  An origin
    server that receives a CONNECT request for itself MAY respond with a
    2xx (Successful) status code to indicate that a connection is
    established.  However, most origin servers do not implement CONNECT.


Section 4.3.8., paragraph 2:
OLD:

    A client MUST NOT generate header fields in a TRACE request
    containing sensitive data that might be disclosed by the response.
 
    For example, it would be foolish for a user agent to send stored user
    credentials [RFC7235] or cookies [RFC6265] in a TRACE request.  The
    final recipient of the request SHOULD exclude any request header
    fields that are likely to contain sensitive data when that recipient
    generates the response body.

NEW:

    A client MUST NOT generate header fields in a TRACE request
    containing sensitive data that might be disclosed by the response.
    For example, it would be foolish for a user agent to send stored user
    credentials [RFC7235] or cookies [RFC6265] in a TRACE request.  The
    final recipient of the request SHOULD exclude any request header
    fields that are likely to contain sensitive data when that recipient
    generates the response body.


Section 5.1.1., paragraph 3:
OLD:

    The Expect field-value is case-insensitive.

NEW:

    The Expect field-value is case insensitive.


Section 5.1.1., paragraph 21:
OLD:

       Note: The Expect header field was added after the original
       publication of HTTP/1.1 [RFC2068] as both the means to request an
       interim 100 response and the general mechanism for indicating
       must-understand extensions.  However, the extension mechanism has
       not been used by clients and the must-understand requirements have
       not been implemented by many servers, rendering the extension
       mechanism useless.  This specification has removed the extension
       mechanism in order to simplify the definition and processing of
       100-continue.

NEW:

       Note: The Expect header field was added after the original
       publication of HTTP/1.1 [RFC2068] as both the means to request an
       interim 100 (Continue) response and the general mechanism for
       indicating must-understand extensions.  However, the extension
       mechanism has not been used by clients and the must-understand
       requirements have not been implemented by many servers, rendering
       the extension mechanism useless.  This specification has removed
       the extension mechanism in order to simplify the definition and
       processing of 100-continue.


Section 5.5.1., paragraph 1:
OLD:

    The "From" header field contains an Internet email address for a
    human user who controls the requesting user agent.  The address ought
    to be machine-usable, as defined by "mailbox" in Section 3.4 of
    [RFC5322]:

NEW:

    The "From" header field contains an Internet email address for a
    human user who controls the requesting user agent.  The address ought
    to be machine usable, as defined by "mailbox" in Section 3.4 of
    [RFC5322]:


Section 5.5.2., paragraph 6:
OLD:

    If the target URI was obtained from a source that does not have its
    own URI (e.g., input from the user keyboard, or an entry within the
    user's bookmarks/favorites), the user agent MUST either exclude
    Referer or send it with a value of "about:blank".

NEW:

    If the target URI was obtained from a source that does not have its
    own URI (e.g., input from the user keyboard, or an entry within the
    user's bookmarks/favorites), the user agent MUST either exclude the
    Referer or send it with a value of "about:blank".


Section 5.5.3., paragraph 1:
OLD:

    The "User-Agent" header field contains information about the user
    agent originating the request, which is often used by servers to help
    identify the scope of reported interoperability problems, to work
    around or tailor responses to avoid particular user agent
    limitations, and for analytics regarding browser or operating system
    use.  A user agent SHOULD send a User-Agent field in each request
    unless specifically configured not to do so.

NEW:

    The "User-Agent" header field contains information about the user
    agent originating the request, which is often used by servers to help
    identify the scope of reported interoperability problems, to work
    around or tailor responses to avoid particular user-agent
    limitations, and for analytics regarding browser or operating system
    use.  A user agent SHOULD send a User-Agent field in each request
    unless specifically configured not to do so.


Section 5.5.3., paragraph 3:
OLD:

    The User-Agent field-value consists of one or more product
    identifiers, each followed by zero or more comments (Section 3.2 of
    [RFC7230]), which together identify the user agent software and its
    significant subproducts.  By convention, the product identifiers are
    listed in decreasing order of their significance for identifying the
    user agent software.  Each product identifier consists of a name and
    optional version.

NEW:

    The User-Agent field-value consists of one or more product
    identifiers, each followed by zero or more comments (Section 3.2 of
    [RFC7230]), which together identify the user-agent software and its
    significant subproducts.  By convention, the product identifiers are
    listed in decreasing order of their significance for identifying the
    user-agent software.  Each product identifier consists of a name and
    optional version.


Section 5.5.3., paragraph 9:
OLD:

    Likewise, implementations are encouraged not to use the product
    tokens of other implementations in order to declare compatibility
    with them, as this circumvents the purpose of the field.  If a user
    agent masquerades as a different user agent, recipients can assume
    that the user intentionally desires to see responses tailored for
    that identified user agent, even if they might not work as well for
    the actual user agent being used.

NEW:

    Likewise, implementations are encouraged not to use the product
    tokens of other implementations in order to declare compatibility
    with them, as this circumvents the purpose of the field.  If a user
    agent masquerades as a different user agent, recipients can assume
    that the user intentionally desires to see responses tailored for
    that identified user agent, even if they might not work as well for
    the actual user agent being implemented.


Section 6., paragraph 3:
OLD:

    For example, if an unrecognized status code of 471 is received by a
    client, the client can assume that there was something wrong with its
    request and treat the response as if it had received a 400 status
    code.  The response message will usually contain a representation
    that explains the status.

NEW:

    For example, if an unrecognized status code of 471 is received by a
    client, the client can assume that there was something wrong with its
    request and treat the response as if it had received a 400 (Bad
    Request) status code.  The response message will usually contain a
    representation that explains the status.


Section 6.1., paragraph 2:
OLD:

    Responses with status codes that are defined as cacheable by default
    (e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501 in this
    specification) can be reused by a cache with heuristic expiration
    unless otherwise indicated by the method definition or explicit cache
    controls [RFC7234]; all other status codes are not cacheable by
    default.

NEW:

    Responses with status codes that are defined as cacheable by default
    (e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501 in
    this specification) can be reused by a cache with heuristic
    expiration unless otherwise indicated by the method definition or
    explicit cache controls [RFC7234]; all other status codes are not
    cacheable by default.


Section 6.4.1., paragraph 5:
OLD:

       Note: The original proposal for 300 defined the URI header field
       as providing a list of alternative representations, such that it
       would be usable for 200, 300, and 406 responses and be transferred
       in responses to the HEAD method.  However, lack of deployment and
       disagreement over syntax led to both URI and Alternates (a
       subsequent proposal) being dropped from this specification.  It is
       possible to communicate the list using a set of Link header fields
       [RFC5988], each with a relationship of "alternate", though
       deployment is a chicken-and-egg problem.

NEW:

       Note: The original proposal for the 300 response defined the URI
       header field as providing a list of alternative representations,
       such that it would be usable for 200, 300, and 406 responses and
       be transferred in responses to the HEAD method.  However, lack of
       deployment and disagreement over syntax led to both URI and
       Alternates (a subsequent proposal) being dropped from this
       specification.  It is possible to communicate the list using a set
       of Link header fields [RFC5988], each with a relationship of
       "alternate", though deployment is a chicken-and-egg problem.


Section 6.4.7., paragraph 3:
OLD:

       Note: This status code is similar to 302 (Found), except that it
       does not allow changing the request method from POST to GET.  This
       specification defines no equivalent counterpart for 301 (Moved
       Permanently) ([RFC7238], however, defines the status code 308
       (Permanent Redirect) for this purpose).

NEW:

       Note: This status code is similar to 302 (Found), except that it
       does not allow changing the request method from POST to GET.  This
       specification defines no equivalent counterpart for 301 (Moved
       Permanently) ([RFC7238]; however, it defines the status code 308
       (Permanent Redirect) for this purpose).


Section 7.1.1.1., paragraph 11:
OLD:

      day-name     = %x4D.6F.6E ; "Mon", case-sensitive
                   / %x54.75.65 ; "Tue", case-sensitive
                   / %x57.65.64 ; "Wed", case-sensitive
                   / %x54.68.75 ; "Thu", case-sensitive
                   / %x46.72.69 ; "Fri", case-sensitive
                   / %x53.61.74 ; "Sat", case-sensitive
                   / %x53.75.6E ; "Sun", case-sensitive

NEW:

      day-name     = %x4D.6F.6E ; "Mon", case sensitive
                   / %x54.75.65 ; "Tue", case sensitive
                   / %x57.65.64 ; "Wed", case sensitive
                   / %x54.68.75 ; "Thu", case sensitive
                   / %x46.72.69 ; "Fri", case sensitive
                   / %x53.61.74 ; "Sat", case sensitive
                   / %x53.75.6E ; "Sun", case sensitive


Section 7.1.1.1., paragraph 13:
OLD:

      day          = 2DIGIT
      month        = %x4A.61.6E ; "Jan", case-sensitive
                   / %x46.65.62 ; "Feb", case-sensitive
                   / %x4D.61.72 ; "Mar", case-sensitive
                   / %x41.70.72 ; "Apr", case-sensitive
                   / %x4D.61.79 ; "May", case-sensitive
                   / %x4A.75.6E ; "Jun", case-sensitive
                   / %x4A.75.6C ; "Jul", case-sensitive
                   / %x41.75.67 ; "Aug", case-sensitive
                   / %x53.65.70 ; "Sep", case-sensitive
                   / %x4F.63.74 ; "Oct", case-sensitive
                   / %x4E.6F.76 ; "Nov", case-sensitive
                   / %x44.65.63 ; "Dec", case-sensitive
      year         = 4DIGIT

NEW:

      day          = 2DIGIT
      month        = %x4A.61.6E ; "Jan", case sensitive
                   / %x46.65.62 ; "Feb", case sensitive
                   / %x4D.61.72 ; "Mar", case sensitive
                   / %x41.70.72 ; "Apr", case sensitive
                   / %x4D.61.79 ; "May", case sensitive
                   / %x4A.75.6E ; "Jun", case sensitive
                   / %x4A.75.6C ; "Jul", case sensitive
                   / %x41.75.67 ; "Aug", case sensitive
                   / %x53.65.70 ; "Sep", case sensitive
                   / %x4F.63.74 ; "Oct", case sensitive
                   / %x4E.6F.76 ; "Nov", case sensitive
                   / %x44.65.63 ; "Dec", case sensitive
      year         = 4DIGIT


Section 7.1.1.1., paragraph 14:
OLD:

      GMT          = %x47.4D.54 ; "GMT", case-sensitive

NEW:

      GMT          = %x47.4D.54 ; "GMT", case sensitive


Section 7.1.1.1., paragraph 19:
OLD:

      day-name-l   = %x4D.6F.6E.64.61.79    ; "Monday", case-sensitive
             / %x54.75.65.73.64.61.79       ; "Tuesday", case-sensitive
             / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive
             / %x54.68.75.72.73.64.61.79    ; "Thursday", case-sensitive
             / %x46.72.69.64.61.79          ; "Friday", case-sensitive
             / %x53.61.74.75.72.64.61.79    ; "Saturday", case-sensitive
             / %x53.75.6E.64.61.79          ; "Sunday", case-sensitive

NEW:

      day-name-l   = %x4D.6F.6E.64.61.79    ; "Monday", case sensitive
             / %x54.75.65.73.64.61.79       ; "Tuesday", case sensitive
             / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case sensitive
             / %x54.68.75.72.73.64.61.79    ; "Thursday", case sensitive
             / %x46.72.69.64.61.79          ; "Friday", case sensitive
             / %x53.61.74.75.72.64.61.79    ; "Saturday", case sensitive
             / %x53.75.6E.64.61.79          ; "Sunday", case sensitive


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

    2.  To inform user agent recipients that this response is subject to
        content negotiation (Section 5.3) and that a different
        representation might be sent in a subsequent request if
        additional parameters are provided in the listed header fields
        (proactive negotiation).

NEW:

    2.  To inform user-agent recipients that this response is subject to
        content negotiation (Section 5.3) and that a different
        representation might be sent in a subsequent request if
        additional parameters are provided in the listed header fields
        (proactive negotiation).


Section 7.2., paragraph 3:
OLD:

    For example, an ETag header field in a 201 response communicates the
    entity-tag of the newly created resource's representation, so that it
    can be used in later conditional requests to prevent the "lost
    update" problem [RFC7232].

NEW:

    For example, an ETag header field in a 201 (Created) response
    communicates the entity-tag of the newly created resource's
    representation, so that it can be used in later conditional requests
    to prevent the "lost update" problem [RFC7232].


Section 8.1., paragraph 1:
OLD:

    The HTTP Method Registry defines the namespace for the request method
    token (Section 4).  The method registry has been created and is now
    maintained at <http://www.iana.org/assignments/http-methods>.

NEW:

    The "Hypertext Transfer Protocol (HTTP) Method Registry" defines the
    namespace for the request method token (Section 4).  The "HTTP Method
    Registry" has been created and is now maintained at
    <http://www.iana.org/assignments/http-methods>.


Section 8.1.2., paragraph 3:
OLD:

    A new method definition needs to indicate whether it is safe
    (Section 4.2.1), idempotent (Section 4.2.2), cacheable
    (Section 4.2.3), what semantics are to be associated with the payload
    body if any is present in the request, and what refinements the
    method makes to header field or status code semantics.  If the new
    method is cacheable, its definition ought to describe how, and under
    what conditions, a cache can store a response and use it to satisfy a
    subsequent request.  The new method ought to describe whether it can
    be made conditional (Section 5.2) and, if so, how a server responds
    when the condition is false.  Likewise, if the new method might have
    some use for partial response semantics ([RFC7233]), it ought to
    document this, too.

NEW:

    A new method definition needs to indicate whether it is safe
    (Section 4.2.1), idempotent (Section 4.2.2), or cacheable
    (Section 4.2.3).  It needs to indicate what semantics are to be
    associated with the payload body if any is present in the request and
    what refinements the method makes to header field or status code
    semantics.  If the new method is cacheable, its definition ought to
    describe how, and under what conditions, a cache can store a response
    and use it to satisfy a subsequent request.  The new method ought to
    describe whether it can be made conditional (Section 5.2) and, if so,
    how a server responds when the condition is false.  Likewise, if the
    new method might have some use for partial response semantics
    ([RFC7233]), it ought to document this, too.


Section 8.1.3., paragraph 1:
OLD:

    The HTTP Method Registry has been populated with the registrations
    below:

NEW:

    The "Hypertext Transfer Protocol (HTTP) Method Registry" has been
    populated with the registrations below:


Section 8.2., paragraph 1:
OLD:

    The HTTP Status Code Registry defines the namespace for the response
    status-code token (Section 6).  The status code registry is
    maintained at <http://www.iana.org/assignments/http-status-codes>.

NEW:

    The "Hypertext Transfer Protocol (HTTP) Status Code Registry" defines
    the namespace for the response status-code token (Section 6).  The
    "HTTP Status Codes" registry is maintained at
    <http://www.iana.org/assignments/http-status-codes>.


Section 8.2.3., paragraph 1:
OLD:

    The HTTP Status Code Registry has been updated with the registrations
    below:

NEW:

    The "HTTP Status Codes" registry has been updated with the
    registrations below:


Section 8.3., paragraph 1:
OLD:

    HTTP header fields are registered within the Message Header Field
    Registry located at <http://www.iana.org/assignments/message-headers/
    message-header-index.html>, as defined by [BCP90].

NEW:

    HTTP header fields are registered within the "Message Headers"
    registry located at <http://www.iana.org/assignments/message-headers>
    as defined by [BCP90].


Section 8.3.1., paragraph 4:
OLD:

    New header field values typically have their syntax defined using
    ABNF ([RFC5234]), using the extension defined in Section 7 of
    [RFC7230] as necessary, and are usually constrained to the range of
    ASCII characters.  Header fields needing a greater range of
    characters can use an encoding such as the one defined in [RFC5987].

NEW:

    New header field values typically have their syntax defined using
    ABNF ([RFC5234]) (implementing the extension defined in Section 7 of
    [RFC7230] as necessary), and they are usually constrained to the
    range of ASCII characters.  Header fields needing a greater range of
    characters can use an encoding such as the one defined in [RFC5987].


Section 8.3.2., paragraph 1:
OLD:

    The Message Header Field Registry has been updated with the following
    permanent registrations:

NEW:

    The "Message Headers" registry has been updated with the following
    permanent registrations:


Section 8.4., paragraph 1:
OLD:

    The HTTP Content Coding Registry defines the namespace for content
    coding names (Section 4.2 of [RFC7230]).  The content coding registry
    is maintained at <http://www.iana.org/assignments/http-parameters>.

NEW:

    The "HTTP Content Coding Registry" defines the namespace for content
    coding names (Section 4.2 of [RFC7230]).  The "HTTP Content Coding
    Registry" is maintained at
    <http://www.iana.org/assignments/http-parameters>.


Section 8.4.1., paragraph 1:
OLD:

    Content Coding registrations MUST include the following fields:

NEW:

    Content coding registrations MUST include the following fields:


Section 8.4.1., paragraph 6:
OLD:

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

NEW:

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


Section 8.4.2., paragraph 1:
OLD:

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

NEW:

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


Section 9., paragraph 2:
OLD:

    The list of considerations below is not exhaustive.  Most security
    concerns related to HTTP semantics are about securing server-side
    applications (code behind the HTTP interface), securing user agent
    processing of payloads received via HTTP, or secure use of the
    Internet in general, rather than security of the protocol.  Various
    organizations maintain topical information and links to current
    research on Web application security (e.g., [OWASP]).

NEW:

    The list of considerations below is not exhaustive.  Most security
    concerns related to HTTP semantics are about securing server-side
    applications (code behind the HTTP interface) or securing user-agent
    processing of payloads received via HTTP.  Secure use of the Internet
    in general, rather than security of the protocol, might also be
    related.  Various organizations maintain topical information and
    links to current research on Web application security (e.g.,
    [OWASP]).


Section 9.1., paragraph 3:
OLD:

    Attacks based on such special names tend to focus on either denial-
    of-service (e.g., telling the server to read from a COM port) or
    disclosure of configuration and source files that are not meant to be
    served.

NEW:

    Attacks based on such special names tend to focus on either denial of
    service (e.g., telling the server to read from a COM port) or
    disclosure of configuration and source files that are not meant to be
    served.


Section 9.4., paragraph 3:
OLD:

    Since the Referer header field tells a target site about the context
    that resulted in a request, it has the potential to reveal
    information about the user's immediate browsing history and any
    personal information that might be found in the referring resource's
    URI.  Limitations on Referer are described in Section 5.5.2 to
    address some of its security considerations.

NEW:

    Since the Referer header field tells a target site about the context
    that resulted in a request, it has the potential to reveal
    information about the user's immediate browsing history and any
    personal information that might be found in the referring resource's
    URI.  Limitations on the Referer header field are described in
    Section 5.5.2 to address some of its security considerations.


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),
               May 2014.

NEW:

    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
               Protocol (HTTP/1.1): Message Syntax and Routing",
               RFC 7230, May 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), May 2014.

NEW:

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


Section 11.1., paragraph 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),
               May 2014.

NEW:

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


Section 11.1., paragraph 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),
               May 2014.

NEW:

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


Section 11.1., paragraph 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),
               May 2014.

NEW:

    [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
               Protocol (HTTP/1.1): Authentication", RFC 7235, May 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, May 2014.


Appendix A., paragraph 16:
OLD:

 A.6.  MHTML and Line Length Limitations

NEW:

 A.6.  MHTML and Line-Length Limitations


Appendix A., paragraph 17:
OLD:

    HTTP implementations that share code with MHTML [RFC2557]
    implementations need to be aware of MIME line length limitations.
    Since HTTP does not have this limitation, HTTP does not fold long
    lines.  MHTML messages being transported by HTTP follow all
    conventions of MHTML, including line length limitations and folding,
    canonicalization, etc., since HTTP transfers message-bodies as
    payload and, aside from the "multipart/byteranges" type (Appendix A
    of [RFC7233]), does not interpret the content or any MIME header
    lines that might be contained therein.

NEW:

    HTTP implementations that share code with MHTML [RFC2557]
    implementations need to be aware of MIME line-length limitations.
    Since HTTP does not have this limitation, HTTP does not fold long
    lines.  MHTML messages being transported by HTTP follow all
    conventions of MHTML, including line-length limitations and folding,
    canonicalization, etc., since HTTP transfers message-bodies as
    payload and, aside from the "multipart/byteranges" type (Appendix A
    of [RFC7233]), does not interpret the content or any MIME header
    lines that might be contained therein.


Appendix B., paragraph 2:
OLD:

    A new requirement has been added that semantics embedded in a URI
    should 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 3:
OLD:

    An algorithm has been added for determining if a payload is
    associated with a specific identifier.  (Section 3.1.4.1)

NEW:

    An algorithm has been added for determining if a payload is
    associated with a specific identifier (Section 3.1.4.1).


Appendix B., paragraph 4:
OLD:

    The default charset of ISO-8859-1 for text media types has been
    removed; the default is now whatever the media type definition says.
    Likewise, special treatment of ISO-8859-1 has been removed from the
    Accept-Charset header field.  (Section 3.1.1.3 and Section 5.3.3)

NEW:

    The default charset of ISO-8859-1 for text media types has been
    removed; the default is now whatever the media type definition says.
    Likewise, special treatment of ISO-8859-1 has been removed from the
    Accept-Charset header field.  (Sections 3.1.1.3 and 5.3.3.)


Appendix B., paragraph 5:
OLD:

    The definition of Content-Location has been changed to no longer
    affect the base URI for resolving relative URI references, due to
    poor implementation support and the undesirable effect of potentially
    breaking relative links in content-negotiated resources.
    (Section 3.1.4.2)

NEW:

    The definition of Content-Location has been changed to no longer
    affect the base URI for resolving relative URI references, due to
    poor implementation support and the undesirable effect of potentially
    breaking relative links in content-negotiated resources
    (Section 3.1.4.2).


Appendix B., paragraph 6:
OLD:

    To be consistent with the method-neutral parsing algorithm of
    [RFC7230], the definition of GET has been relaxed so that requests
    can have a body, even though a body has no meaning for GET.
    (Section 4.3.1)

NEW:

    To be consistent with the method-neutral parsing algorithm of
    [RFC7230], the definition of GET has been relaxed so that requests
    can have a body, even though a body has no meaning for GET
    (Section 4.3.1).


Appendix B., paragraph 7:
OLD:

    Servers are no longer required to handle all Content-* header fields
    and use of Content-Range has been explicitly banned in PUT requests.
    (Section 4.3.4)

NEW:

    Servers are no longer required to handle all Content-* header fields
    and use of Content-Range has been explicitly banned in PUT requests
    (Section 4.3.4).


Appendix B., paragraph 8:
OLD:

    Definition of the CONNECT method has been moved from [RFC2817] to
    this specification.  (Section 4.3.6)

NEW:

    Definition of the CONNECT method has been moved from [RFC2817] to
    this specification (Section 4.3.6).


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)

NEW:

    The OPTIONS and TRACE request methods have been defined as being safe
    (Section 4.3.7 and Section 4.3.8).


Appendix B., paragraph 10:
OLD:

    The Expect header field's extension mechanism has been removed due to
    widely-deployed broken implementations.  (Section 5.1.1)

NEW:

    The Expect header field's extension mechanism has been removed due to
    widely deployed broken implementations (Section 5.1.1).


Appendix B., paragraph 11:
OLD:

    The Max-Forwards header field has been restricted to the OPTIONS and
    TRACE methods; previously, extension methods could have used it as
    well.  (Section 5.1.2)

NEW:

    The Max-Forwards header field has been restricted to the OPTIONS and
    TRACE methods; previously, extension methods could have used it as
    well (Section 5.1.2).


Appendix B., paragraph 12:
OLD:

    The "about:blank" URI has been suggested as a value for the Referer
    header field when no referring URI is applicable, which distinguishes
    that case from others where the Referer field is not sent or has been
    removed.  (Section 5.5.2)

NEW:

    The "about:blank" URI has been suggested as a value for the Referer
    header field when no referring URI is applicable, which distinguishes
    that case from others where the Referer field is not sent or has been
    removed (Section 5.5.2).


Appendix B., paragraph 13:
OLD:

    The following status codes are now cacheable (that is, they can be
    stored and reused by a cache without explicit freshness information
    present): 204, 404, 405, 414, 501.  (Section 6)

NEW:

    The following status codes are now cacheable (that is, they can be
    stored and reused by a cache without explicit freshness information
    present): 204, 404, 405, 414, 501 (Section 6).


Appendix B., paragraph 14:
OLD:

    The 201 (Created) status description has been changed to allow for
    the possibility that more than one resource has been created.
    (Section 6.3.2)

NEW:

    The 201 (Created) status description has been changed to allow for
    the possibility that more than one resource has been created
    (Section 6.3.2).


Appendix B., paragraph 15:
OLD:

    The definition of 203 (Non-Authoritative Information) has been
    broadened to include cases of payload transformations as well.
    (Section 6.3.4)

NEW:

    The definition of 203 (Non-Authoritative Information) has been
    broadened to include cases of payload transformations as well
    (Section 6.3.4).


Appendix B., paragraph 16:
OLD:

    The set of request methods that are safe to automatically redirect is
    no longer closed; user agents are able to make that determination
    based upon the request method semantics.  The redirect status codes
    301, 302, and 307 no longer have normative requirements on response
    payloads and user interaction.  (Section 6.4)

NEW:

    The set of request methods that are safe to automatically redirect is
    no longer closed; user agents are able to make that determination
    based upon the request method semantics.  The redirect status codes
    301, 302, and 307 no longer have normative requirements on response
    payloads and user interaction (Section 6.4).


Appendix B., paragraph 17:
OLD:

    The status codes 301 and 302 have been changed to allow user agents
    to rewrite the method from POST to GET.  (Sections 6.4.2 and 6.4.3)

NEW:

    The status codes 301 and 302 have been changed to allow user agents
    to rewrite the method from POST to GET.  (Sections 6.4.2 and 6.4.3.)


Appendix B., paragraph 18:
OLD:

    The description of 303 (See Other) status code has been changed to
    allow it to be cached if explicit freshness information is given, and
    a specific definition has been added for a 303 response to GET.
    (Section 6.4.4)

NEW:

    The description of the 303 (See Other) status code has been changed
    to allow it to be cached if explicit freshness information is given,
    and a specific definition has been added for a 303 response to GET
    (Section 6.4.4).


Appendix B., paragraph 19:
OLD:

    The 305 (Use Proxy) status code has been deprecated due to security
    concerns regarding in-band configuration of a proxy.  (Section 6.4.5)

NEW:

    The 305 (Use Proxy) status code has been deprecated due to security
    concerns regarding in-band configuration of a proxy (Section 6.4.5).


Appendix B., paragraph 20:
OLD:

    The 400 (Bad Request) status code has been relaxed so that it isn't
    limited to syntax errors.  (Section 6.5.1)

NEW:

    The 400 (Bad Request) status code has been relaxed so that it isn't
    limited to syntax errors (Section 6.5.1).


Appendix B., paragraph 21:
OLD:

    The 426 (Upgrade Required) status code has been incorporated from
    [RFC2817].  (Section 6.5.15)

NEW:

    The 426 (Upgrade Required) status code has been incorporated from
    [RFC2817] (Section 6.5.15).


Appendix B., paragraph 22:
OLD:

    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 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 23:
OLD:

    The syntax of the Location header field has been changed to allow all
    URI references, including relative references and fragments, along
    with some clarifications as to when use of fragments would not be
    appropriate.  (Section 7.1.2)

NEW:

    The syntax of the Location header field has been changed to allow all
    URI references, including relative references and fragments, along
    with some clarifications as to when use of fragments would not be
    appropriate (Section 7.1.2).


Appendix B., paragraph 24:
OLD:

    Allow has been reclassified as a response header field, removing the
    option to specify it in a PUT request.  Requirements relating to the
    content of Allow have been relaxed; correspondingly, clients are not
    required to always trust its value.  (Section 7.4.1)

NEW:

    Allow has been reclassified as a response header field, removing the
    option to specify it in a PUT request.  Requirements relating to the
    content of Allow have been relaxed; correspondingly, clients are not
    required to always trust its value (Section 7.4.1).


Appendix B., paragraph 25:
OLD:

    A Method Registry has been defined.  (Section 8.1)

NEW:

    A Method Registry has been defined (Section 8.1).


Appendix B., paragraph 26:
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).


Appendix B., paragraph 27:
OLD:

    Registration of Content Codings has been changed to require IETF
    Review.  (Section 8.4)

NEW:

    Registration of content codings has been changed to require IETF
    Review (Section 8.4).


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, defined in [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, defined in [RFC7230], Section 3.2.3>


Section 1.2, paragraph 2:
OLD:

    Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS
     content-coding ] )
    Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS
     language-tag ] )
    Content-Location = absolute-URI / partial-URI
    Content-Type = media-type
 
    Date = HTTP-date

NEW:

    Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS
     content-coding ] )
    Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS
     language-tag ] )
    Content-Location = absolute-URI / partial-URI
    Content-Type = media-type
    Date = HTTP-date


Section 1.2, paragraph 16:
OLD:

    charset = token
    codings = content-coding / "identity" / "*"
    comment = <comment, defined in [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, defined in [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 21:
OLD:

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


Section 1.2, paragraph 47:
OLD:

    M
       Max-Forwards header field  36
       MIME-Version header field  89

NEW:

    M
       Max-Forwards header field  36
       MIME-Version header field  88


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