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

Last change on this file since 2631 was 2631, checked in by julian.reschke@…, 6 years ago

add subproject for auth48 checks (#553)

File size: 124.5 KB
Line 
1
2INTRODUCTION, paragraph 1:
3OLD:
4
5 HTTPbis Working Group                                   R. Fielding, Ed.
6 Internet-Draft                                                     Adobe
7 Obsoletes: 2616 (if approved)                            J. Reschke, Ed.
8 Updates: 2817 (if approved)                                   greenbytes
9 Intended status: Standards Track                             May 6, 2014
10 Expires: November 7, 2014
11
12NEW:
13
14 Internet Engineering Task Force (IETF)                  R. Fielding, Ed.
15 Request for Comments: 7231                                         Adobe
16 Obsoletes: 2616                                          J. Reschke, Ed.
17 Updates: 2817                                                 greenbytes
18 Category: Standards Track                                       May 2014
19 ISSN: 2070-1721
20
21
22INTRODUCTION, paragraph 2:
23OLD:
24
25      Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
26                  draft-ietf-httpbis-p2-semantics-latest
27
28NEW:
29
30      Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
31
32
33INTRODUCTION, paragraph 5:
34OLD:
35
36 Editorial Note (To be removed by RFC Editor)
37 
38    Discussion of this draft takes place on the HTTPBIS working group
39    mailing list (ietf-http-wg@w3.org), which is archived at
40    <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
41 
42    The current issues list is at
43    <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
44    documents (including fancy diffs) can be found at
45    <http://tools.ietf.org/wg/httpbis/>.
46 
47    The changes in this draft are summarized in Appendix E.4.
48 
49 Status of This Memo
50
51NEW:
52
53 Status of This Memo
54
55
56INTRODUCTION, paragraph 6:
57OLD:
58
59    This Internet-Draft is submitted in full conformance with the
60    provisions of BCP 78 and BCP 79.
61
62NEW:
63
64    This is an Internet Standards Track document.
65
66
67INTRODUCTION, paragraph 7:
68OLD:
69
70    Internet-Drafts are working documents of the Internet Engineering
71    Task Force (IETF).  Note that other groups may also distribute
72    working documents as Internet-Drafts.  The list of current Internet-
73    Drafts is at http://datatracker.ietf.org/drafts/current/.
74
75NEW:
76
77    This document is a product of the Internet Engineering Task Force
78    (IETF).  It represents the consensus of the IETF community.  It has
79    received public review and has been approved for publication by the
80    Internet Engineering Steering Group (IESG).  Further information on
81    Internet Standards is available in Section 2 of RFC 5741.
82
83
84INTRODUCTION, paragraph 8:
85OLD:
86
87    Internet-Drafts are draft documents valid for a maximum of six months
88    and may be updated, replaced, or obsoleted by other documents at any
89    time.  It is inappropriate to use Internet-Drafts as reference
90    material or to cite them other than as "work in progress."
91    This Internet-Draft will expire on November 7, 2014.
92
93NEW:
94
95    Information about the current status of this document, any errata,
96    and how to provide feedback on it may be obtained at
97    http://www.rfc-editor.org/info/rfc7231.
98
99
100Section 11., paragraph 0:
101OLD:
102
103    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  6
104      1.1.  Conformance and Error Handling . . . . . . . . . . . . . .  6
105      1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  6
106    2.  Resources  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
107    3.  Representations  . . . . . . . . . . . . . . . . . . . . . . .  7
108      3.1.  Representation Metadata  . . . . . . . . . . . . . . . . .  8
109        3.1.1.  Processing Representation Data . . . . . . . . . . . .  8
110        3.1.2.  Encoding for Compression or Integrity  . . . . . . . . 11
111        3.1.3.  Audience Language  . . . . . . . . . . . . . . . . . . 13
112        3.1.4.  Identification . . . . . . . . . . . . . . . . . . . . 14
113      3.2.  Representation Data  . . . . . . . . . . . . . . . . . . . 17
114      3.3.  Payload Semantics  . . . . . . . . . . . . . . . . . . . . 17
115      3.4.  Content Negotiation  . . . . . . . . . . . . . . . . . . . 18
116        3.4.1.  Proactive Negotiation  . . . . . . . . . . . . . . . . 19
117        3.4.2.  Reactive Negotiation . . . . . . . . . . . . . . . . . 20
118    4.  Request Methods  . . . . . . . . . . . . . . . . . . . . . . . 21
119      4.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . 21
120      4.2.  Common Method Properties . . . . . . . . . . . . . . . . . 22
121        4.2.1.  Safe Methods . . . . . . . . . . . . . . . . . . . . . 22
122        4.2.2.  Idempotent Methods . . . . . . . . . . . . . . . . . . 23
123        4.2.3.  Cacheable Methods  . . . . . . . . . . . . . . . . . . 24
124      4.3.  Method Definitions . . . . . . . . . . . . . . . . . . . . 24
125        4.3.1.  GET  . . . . . . . . . . . . . . . . . . . . . . . . . 24
126        4.3.2.  HEAD . . . . . . . . . . . . . . . . . . . . . . . . . 25
127        4.3.3.  POST . . . . . . . . . . . . . . . . . . . . . . . . . 25
128        4.3.4.  PUT  . . . . . . . . . . . . . . . . . . . . . . . . . 26
129        4.3.5.  DELETE . . . . . . . . . . . . . . . . . . . . . . . . 29
130        4.3.6.  CONNECT  . . . . . . . . . . . . . . . . . . . . . . . 30
131        4.3.7.  OPTIONS  . . . . . . . . . . . . . . . . . . . . . . . 31
132        4.3.8.  TRACE  . . . . . . . . . . . . . . . . . . . . . . . . 32
133    5.  Request Header Fields  . . . . . . . . . . . . . . . . . . . . 33
134      5.1.  Controls . . . . . . . . . . . . . . . . . . . . . . . . . 33
135        5.1.1.  Expect . . . . . . . . . . . . . . . . . . . . . . . . 34
136        5.1.2.  Max-Forwards . . . . . . . . . . . . . . . . . . . . . 36
137      5.2.  Conditionals . . . . . . . . . . . . . . . . . . . . . . . 36
138      5.3.  Content Negotiation  . . . . . . . . . . . . . . . . . . . 37
139        5.3.1.  Quality Values . . . . . . . . . . . . . . . . . . . . 37
140        5.3.2.  Accept . . . . . . . . . . . . . . . . . . . . . . . . 38
141        5.3.3.  Accept-Charset . . . . . . . . . . . . . . . . . . . . 40
142        5.3.4.  Accept-Encoding  . . . . . . . . . . . . . . . . . . . 41
143        5.3.5.  Accept-Language  . . . . . . . . . . . . . . . . . . . 42
144      5.4.  Authentication Credentials . . . . . . . . . . . . . . . . 43
145      5.5.  Request Context  . . . . . . . . . . . . . . . . . . . . . 44
146        5.5.1.  From . . . . . . . . . . . . . . . . . . . . . . . . . 44
147        5.5.2.  Referer  . . . . . . . . . . . . . . . . . . . . . . . 45
148        5.5.3.  User-Agent . . . . . . . . . . . . . . . . . . . . . . 46
149    6.  Response Status Codes  . . . . . . . . . . . . . . . . . . . . 47
150      6.1.  Overview of Status Codes . . . . . . . . . . . . . . . . . 48
151      6.2.  Informational 1xx  . . . . . . . . . . . . . . . . . . . . 50
152        6.2.1.  100 Continue . . . . . . . . . . . . . . . . . . . . . 50
153        6.2.2.  101 Switching Protocols  . . . . . . . . . . . . . . . 50
154      6.3.  Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 51
155        6.3.1.  200 OK . . . . . . . . . . . . . . . . . . . . . . . . 51
156        6.3.2.  201 Created  . . . . . . . . . . . . . . . . . . . . . 52
157        6.3.3.  202 Accepted . . . . . . . . . . . . . . . . . . . . . 52
158        6.3.4.  203 Non-Authoritative Information  . . . . . . . . . . 52
159        6.3.5.  204 No Content . . . . . . . . . . . . . . . . . . . . 53
160        6.3.6.  205 Reset Content  . . . . . . . . . . . . . . . . . . 53
161      6.4.  Redirection 3xx  . . . . . . . . . . . . . . . . . . . . . 54
162        6.4.1.  300 Multiple Choices . . . . . . . . . . . . . . . . . 55
163        6.4.2.  301 Moved Permanently  . . . . . . . . . . . . . . . . 56
164        6.4.3.  302 Found  . . . . . . . . . . . . . . . . . . . . . . 56
165        6.4.4.  303 See Other  . . . . . . . . . . . . . . . . . . . . 57
166        6.4.5.  305 Use Proxy  . . . . . . . . . . . . . . . . . . . . 57
167        6.4.6.  306 (Unused) . . . . . . . . . . . . . . . . . . . . . 57
168        6.4.7.  307 Temporary Redirect . . . . . . . . . . . . . . . . 58
169      6.5.  Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 58
170        6.5.1.  400 Bad Request  . . . . . . . . . . . . . . . . . . . 58
171        6.5.2.  402 Payment Required . . . . . . . . . . . . . . . . . 58
172        6.5.3.  403 Forbidden  . . . . . . . . . . . . . . . . . . . . 58
173        6.5.4.  404 Not Found  . . . . . . . . . . . . . . . . . . . . 59
174        6.5.5.  405 Method Not Allowed . . . . . . . . . . . . . . . . 59
175        6.5.6.  406 Not Acceptable . . . . . . . . . . . . . . . . . . 59
176        6.5.7.  408 Request Timeout  . . . . . . . . . . . . . . . . . 60
177        6.5.8.  409 Conflict . . . . . . . . . . . . . . . . . . . . . 60
178        6.5.9.  410 Gone . . . . . . . . . . . . . . . . . . . . . . . 60
179        6.5.10. 411 Length Required  . . . . . . . . . . . . . . . . . 61
180        6.5.11. 413 Payload Too Large  . . . . . . . . . . . . . . . . 61
181        6.5.12. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 61
182        6.5.13. 415 Unsupported Media Type . . . . . . . . . . . . . . 61
183        6.5.14. 417 Expectation Failed . . . . . . . . . . . . . . . . 62
184        6.5.15. 426 Upgrade Required . . . . . . . . . . . . . . . . . 62
185      6.6.  Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 62
186        6.6.1.  500 Internal Server Error  . . . . . . . . . . . . . . 62
187        6.6.2.  501 Not Implemented  . . . . . . . . . . . . . . . . . 63
188        6.6.3.  502 Bad Gateway  . . . . . . . . . . . . . . . . . . . 63
189        6.6.4.  503 Service Unavailable  . . . . . . . . . . . . . . . 63
190        6.6.5.  504 Gateway Timeout  . . . . . . . . . . . . . . . . . 63
191        6.6.6.  505 HTTP Version Not Supported . . . . . . . . . . . . 63
192    7.  Response Header Fields . . . . . . . . . . . . . . . . . . . . 64
193      7.1.  Control Data . . . . . . . . . . . . . . . . . . . . . . . 64
194        7.1.1.  Origination Date . . . . . . . . . . . . . . . . . . . 64
195        7.1.2.  Location . . . . . . . . . . . . . . . . . . . . . . . 68
196        7.1.3.  Retry-After  . . . . . . . . . . . . . . . . . . . . . 69
197        7.1.4.  Vary . . . . . . . . . . . . . . . . . . . . . . . . . 70
198      7.2.  Validator Header Fields  . . . . . . . . . . . . . . . . . 71
199      7.3.  Authentication Challenges  . . . . . . . . . . . . . . . . 72
200      7.4.  Response Context . . . . . . . . . . . . . . . . . . . . . 72
201        7.4.1.  Allow  . . . . . . . . . . . . . . . . . . . . . . . . 72
202        7.4.2.  Server . . . . . . . . . . . . . . . . . . . . . . . . 73
203    8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 73
204      8.1.  Method Registry  . . . . . . . . . . . . . . . . . . . . . 74
205        8.1.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 74
206        8.1.2.  Considerations for New Methods . . . . . . . . . . . . 74
207        8.1.3.  Registrations  . . . . . . . . . . . . . . . . . . . . 75
208      8.2.  Status Code Registry . . . . . . . . . . . . . . . . . . . 75
209        8.2.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 75
210        8.2.2.  Considerations for New Status Codes  . . . . . . . . . 76
211        8.2.3.  Registrations  . . . . . . . . . . . . . . . . . . . . 76
212      8.3.  Header Field Registry  . . . . . . . . . . . . . . . . . . 77
213        8.3.1.  Considerations for New Header Fields . . . . . . . . . 78
214        8.3.2.  Registrations  . . . . . . . . . . . . . . . . . . . . 80
215      8.4.  Content Coding Registry  . . . . . . . . . . . . . . . . . 80
216        8.4.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 81
217        8.4.2.  Registrations  . . . . . . . . . . . . . . . . . . . . 81
218    9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 81
219      9.1.  Attacks Based On File and Path Names . . . . . . . . . . . 82
220      9.2.  Attacks Based On Command, Code, or Query Injection . . . . 82
221      9.3.  Disclosure of Personal Information . . . . . . . . . . . . 83
222      9.4.  Disclosure of Sensitive Information in URIs  . . . . . . . 83
223      9.5.  Disclosure of Fragment after Redirects . . . . . . . . . . 83
224      9.6.  Disclosure of Product Information  . . . . . . . . . . . . 84
225      9.7.  Browser Fingerprinting . . . . . . . . . . . . . . . . . . 84
226    10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 85
227    11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 85
228      11.1. Normative References . . . . . . . . . . . . . . . . . . . 85
229      11.2. Informative References . . . . . . . . . . . . . . . . . . 86
230    Appendix A.  Differences between HTTP and MIME . . . . . . . . . . 88
231      A.1.  MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 89
232      A.2.  Conversion to Canonical Form . . . . . . . . . . . . . . . 89
233      A.3.  Conversion of Date Formats . . . . . . . . . . . . . . . . 89
234      A.4.  Conversion of Content-Encoding . . . . . . . . . . . . . . 90
235      A.5.  Conversion of Content-Transfer-Encoding  . . . . . . . . . 90
236      A.6.  MHTML and Line Length Limitations  . . . . . . . . . . . . 90
237    Appendix B.  Changes from RFC 2616 . . . . . . . . . . . . . . . . 90
238    Appendix C.  Imported ABNF . . . . . . . . . . . . . . . . . . . . 93
239    Appendix D.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 93
240    Appendix E.  Change Log (to be removed by RFC Editor before
241                 publication)  . . . . . . . . . . . . . . . . . . . . 96
242      E.1.  Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 96
243      E.2.  Since draft-ietf-httpbis-p2-semantics-24 . . . . . . . . . 96
244      E.3.  Since draft-ietf-httpbis-p2-semantics-25 . . . . . . . . . 97
245      E.4.  Since draft-ietf-httpbis-p2-semantics-26 . . . . . . . . . 97
246    Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
247
248NEW:
249
250    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  6
251      1.1.  Conformance and Error Handling . . . . . . . . . . . . . .  6
252      1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  6
253    2.  Resources  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
254    3.  Representations  . . . . . . . . . . . . . . . . . . . . . . .  7
255      3.1.  Representation Metadata  . . . . . . . . . . . . . . . . .  8
256        3.1.1.  Processing Representation Data . . . . . . . . . . . .  8
257        3.1.2.  Encoding for Compression or Integrity  . . . . . . . . 11
258        3.1.3.  Audience Language  . . . . . . . . . . . . . . . . . . 13
259        3.1.4.  Identification . . . . . . . . . . . . . . . . . . . . 14
260      3.2.  Representation Data  . . . . . . . . . . . . . . . . . . . 17
261      3.3.  Payload Semantics  . . . . . . . . . . . . . . . . . . . . 17
262      3.4.  Content Negotiation  . . . . . . . . . . . . . . . . . . . 18
263        3.4.1.  Proactive Negotiation  . . . . . . . . . . . . . . . . 19
264        3.4.2.  Reactive Negotiation . . . . . . . . . . . . . . . . . 20
265    4.  Request Methods  . . . . . . . . . . . . . . . . . . . . . . . 21
266      4.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . 21
267      4.2.  Common Method Properties . . . . . . . . . . . . . . . . . 22
268        4.2.1.  Safe Methods . . . . . . . . . . . . . . . . . . . . . 22
269        4.2.2.  Idempotent Methods . . . . . . . . . . . . . . . . . . 23
270        4.2.3.  Cacheable Methods  . . . . . . . . . . . . . . . . . . 24
271      4.3.  Method Definitions . . . . . . . . . . . . . . . . . . . . 24
272        4.3.1.  GET  . . . . . . . . . . . . . . . . . . . . . . . . . 24
273        4.3.2.  HEAD . . . . . . . . . . . . . . . . . . . . . . . . . 25
274        4.3.3.  POST . . . . . . . . . . . . . . . . . . . . . . . . . 25
275        4.3.4.  PUT  . . . . . . . . . . . . . . . . . . . . . . . . . 26
276        4.3.5.  DELETE . . . . . . . . . . . . . . . . . . . . . . . . 29
277        4.3.6.  CONNECT  . . . . . . . . . . . . . . . . . . . . . . . 30
278        4.3.7.  OPTIONS  . . . . . . . . . . . . . . . . . . . . . . . 31
279        4.3.8.  TRACE  . . . . . . . . . . . . . . . . . . . . . . . . 32
280    5.  Request Header Fields  . . . . . . . . . . . . . . . . . . . . 33
281      5.1.  Controls . . . . . . . . . . . . . . . . . . . . . . . . . 33
282        5.1.1.  Expect . . . . . . . . . . . . . . . . . . . . . . . . 34
283        5.1.2.  Max-Forwards . . . . . . . . . . . . . . . . . . . . . 36
284 
285      5.2.  Conditionals . . . . . . . . . . . . . . . . . . . . . . . 36
286      5.3.  Content Negotiation  . . . . . . . . . . . . . . . . . . . 37
287        5.3.1.  Quality Values . . . . . . . . . . . . . . . . . . . . 37
288        5.3.2.  Accept . . . . . . . . . . . . . . . . . . . . . . . . 38
289        5.3.3.  Accept-Charset . . . . . . . . . . . . . . . . . . . . 40
290        5.3.4.  Accept-Encoding  . . . . . . . . . . . . . . . . . . . 41
291        5.3.5.  Accept-Language  . . . . . . . . . . . . . . . . . . . 42
292      5.4.  Authentication Credentials . . . . . . . . . . . . . . . . 43
293      5.5.  Request Context  . . . . . . . . . . . . . . . . . . . . . 44
294        5.5.1.  From . . . . . . . . . . . . . . . . . . . . . . . . . 44
295        5.5.2.  Referer  . . . . . . . . . . . . . . . . . . . . . . . 45
296        5.5.3.  User-Agent . . . . . . . . . . . . . . . . . . . . . . 46
297    6.  Response Status Codes  . . . . . . . . . . . . . . . . . . . . 47
298      6.1.  Overview of Status Codes . . . . . . . . . . . . . . . . . 48
299      6.2.  Informational 1xx  . . . . . . . . . . . . . . . . . . . . 50
300        6.2.1.  100 Continue . . . . . . . . . . . . . . . . . . . . . 50
301        6.2.2.  101 Switching Protocols  . . . . . . . . . . . . . . . 50
302      6.3.  Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 51
303        6.3.1.  200 OK . . . . . . . . . . . . . . . . . . . . . . . . 51
304        6.3.2.  201 Created  . . . . . . . . . . . . . . . . . . . . . 52
305        6.3.3.  202 Accepted . . . . . . . . . . . . . . . . . . . . . 52
306        6.3.4.  203 Non-Authoritative Information  . . . . . . . . . . 52
307        6.3.5.  204 No Content . . . . . . . . . . . . . . . . . . . . 53
308        6.3.6.  205 Reset Content  . . . . . . . . . . . . . . . . . . 53
309      6.4.  Redirection 3xx  . . . . . . . . . . . . . . . . . . . . . 54
310        6.4.1.  300 Multiple Choices . . . . . . . . . . . . . . . . . 55
311        6.4.2.  301 Moved Permanently  . . . . . . . . . . . . . . . . 56
312        6.4.3.  302 Found  . . . . . . . . . . . . . . . . . . . . . . 56
313        6.4.4.  303 See Other  . . . . . . . . . . . . . . . . . . . . 57
314        6.4.5.  305 Use Proxy  . . . . . . . . . . . . . . . . . . . . 57
315        6.4.6.  306 (Unused) . . . . . . . . . . . . . . . . . . . . . 57
316        6.4.7.  307 Temporary Redirect . . . . . . . . . . . . . . . . 58
317      6.5.  Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 58
318        6.5.1.  400 Bad Request  . . . . . . . . . . . . . . . . . . . 58
319        6.5.2.  402 Payment Required . . . . . . . . . . . . . . . . . 58
320        6.5.3.  403 Forbidden  . . . . . . . . . . . . . . . . . . . . 58
321        6.5.4.  404 Not Found  . . . . . . . . . . . . . . . . . . . . 59
322        6.5.5.  405 Method Not Allowed . . . . . . . . . . . . . . . . 59
323        6.5.6.  406 Not Acceptable . . . . . . . . . . . . . . . . . . 59
324        6.5.7.  408 Request Timeout  . . . . . . . . . . . . . . . . . 60
325        6.5.8.  409 Conflict . . . . . . . . . . . . . . . . . . . . . 60
326        6.5.9.  410 Gone . . . . . . . . . . . . . . . . . . . . . . . 60
327        6.5.10. 411 Length Required  . . . . . . . . . . . . . . . . . 61
328        6.5.11. 413 Payload Too Large  . . . . . . . . . . . . . . . . 61
329        6.5.12. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 61
330        6.5.13. 415 Unsupported Media Type . . . . . . . . . . . . . . 61
331        6.5.14. 417 Expectation Failed . . . . . . . . . . . . . . . . 62
332        6.5.15. 426 Upgrade Required . . . . . . . . . . . . . . . . . 62
333 
334      6.6.  Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 62
335        6.6.1.  500 Internal Server Error  . . . . . . . . . . . . . . 62
336        6.6.2.  501 Not Implemented  . . . . . . . . . . . . . . . . . 63
337        6.6.3.  502 Bad Gateway  . . . . . . . . . . . . . . . . . . . 63
338        6.6.4.  503 Service Unavailable  . . . . . . . . . . . . . . . 63
339        6.6.5.  504 Gateway Timeout  . . . . . . . . . . . . . . . . . 63
340        6.6.6.  505 HTTP Version Not Supported . . . . . . . . . . . . 63
341    7.  Response Header Fields . . . . . . . . . . . . . . . . . . . . 64
342      7.1.  Control Data . . . . . . . . . . . . . . . . . . . . . . . 64
343        7.1.1.  Origination Date . . . . . . . . . . . . . . . . . . . 64
344        7.1.2.  Location . . . . . . . . . . . . . . . . . . . . . . . 68
345        7.1.3.  Retry-After  . . . . . . . . . . . . . . . . . . . . . 69
346        7.1.4.  Vary . . . . . . . . . . . . . . . . . . . . . . . . . 70
347      7.2.  Validator Header Fields  . . . . . . . . . . . . . . . . . 71
348      7.3.  Authentication Challenges  . . . . . . . . . . . . . . . . 72
349      7.4.  Response Context . . . . . . . . . . . . . . . . . . . . . 72
350        7.4.1.  Allow  . . . . . . . . . . . . . . . . . . . . . . . . 72
351        7.4.2.  Server . . . . . . . . . . . . . . . . . . . . . . . . 73
352    8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 73
353      8.1.  Method Registry  . . . . . . . . . . . . . . . . . . . . . 74
354        8.1.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 74
355        8.1.2.  Considerations for New Methods . . . . . . . . . . . . 74
356        8.1.3.  Registrations  . . . . . . . . . . . . . . . . . . . . 75
357      8.2.  Status Code Registry . . . . . . . . . . . . . . . . . . . 75
358        8.2.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 75
359        8.2.2.  Considerations for New Status Codes  . . . . . . . . . 76
360        8.2.3.  Registrations  . . . . . . . . . . . . . . . . . . . . 76
361      8.3.  Header Field Registry  . . . . . . . . . . . . . . . . . . 77
362        8.3.1.  Considerations for New Header Fields . . . . . . . . . 78
363        8.3.2.  Registrations  . . . . . . . . . . . . . . . . . . . . 80
364      8.4.  Content Coding Registry  . . . . . . . . . . . . . . . . . 80
365        8.4.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 81
366        8.4.2.  Registrations  . . . . . . . . . . . . . . . . . . . . 81
367    9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 81
368      9.1.  Attacks Based on File and Path Names . . . . . . . . . . . 82
369      9.2.  Attacks Based on Command, Code, or Query Injection . . . . 82
370      9.3.  Disclosure of Personal Information . . . . . . . . . . . . 83
371      9.4.  Disclosure of Sensitive Information in URIs  . . . . . . . 83
372      9.5.  Disclosure of Fragment after Redirects . . . . . . . . . . 83
373      9.6.  Disclosure of Product Information  . . . . . . . . . . . . 84
374      9.7.  Browser Fingerprinting . . . . . . . . . . . . . . . . . . 84
375    10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 85
376    11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 85
377      11.1. Normative References . . . . . . . . . . . . . . . . . . . 85
378      11.2. Informative References . . . . . . . . . . . . . . . . . . 86
379    Appendix A.  Differences between HTTP and MIME . . . . . . . . . . 88
380      A.1.  MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 88
381      A.2.  Conversion to Canonical Form . . . . . . . . . . . . . . . 89
382      A.3.  Conversion of Date Formats . . . . . . . . . . . . . . . . 89
383      A.4.  Conversion of Content-Encoding . . . . . . . . . . . . . . 89
384      A.5.  Conversion of Content-Transfer-Encoding  . . . . . . . . . 90
385      A.6.  MHTML and Line-Length Limitations  . . . . . . . . . . . . 90
386    Appendix B.  Changes from RFC 2616 . . . . . . . . . . . . . . . . 90
387    Appendix C.  Imported ABNF . . . . . . . . . . . . . . . . . . . . 93
388    Appendix D.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 93
389    Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
390
391
392Section 1., paragraph 1:
393OLD:
394
395    Each Hypertext Transfer Protocol (HTTP) message is either a request
396    or a response.  A server listens on a connection for a request,
397    parses each message received, interprets the message semantics in
398    relation to the identified request target, and responds to that
399    request with one or more response messages.  A client constructs
400    request messages to communicate specific intentions, and examines
401    received responses to see if the intentions were carried out and
402    determine how to interpret the results.  This document defines
403    HTTP/1.1 request and response semantics in terms of the architecture
404    defined in [RFC7230].
405
406NEW:
407
408    Each Hypertext Transfer Protocol (HTTP) message is either a request
409    or a response.  A server listens on a connection for a request,
410    parses each message received, interprets the message semantics in
411    relation to the identified request target, and responds to that
412    request with one or more response messages.  A client constructs
413    request messages to communicate specific intentions, examines
414    received responses to see if the intentions were carried out, and
415    determines how to interpret the results.  This document defines
416    HTTP/1.1 request and response semantics in terms of the architecture
417    defined in [RFC7230].
418
419
420Section 2., paragraph 1:
421OLD:
422
423    The target of an HTTP request is called a resource.  HTTP does not
424    limit the nature of a resource; it merely defines an interface that
425    might be used to interact with resources.  Each resource is
426    identified by a Uniform Resource Identifier (URI), as described in
427    Section 2.7 of [RFC7230].
428
429NEW:
430
431    The target of an HTTP request is called a "resource".  HTTP does not
432    limit the nature of a resource; it merely defines an interface that
433    might be used to interact with resources.  Each resource is
434    identified by a Uniform Resource Identifier (URI), as described in
435    Section 2.7 of [RFC7230].
436
437
438Section 3., paragraph 3:
439OLD:
440
441    An origin server might be provided with, or capable of generating,
442    multiple representations that are each intended to reflect the
443    current state of a target resource.  In such cases, some algorithm is
444    used by the origin server to select one of those representations as
445    most applicable to a given request, usually based on content
446    negotiation.  This "selected representation" is used to provide the
447    data and metadata for evaluating conditional requests [RFC7232] and
448    constructing the payload for 200 (OK) and 304 (Not Modified)
449    responses to GET (Section 4.3.1).
450
451NEW:
452
453    An origin server might be provided with, or be capable of generating,
454    multiple representations that are each intended to reflect the
455    current state of a target resource.  In such cases, some algorithm is
456    used by the origin server to select one of those representations as
457    most applicable to a given request, usually based on content
458    negotiation.  This "selected representation" is used to provide the
459    data and metadata for evaluating conditional requests [RFC7232] and
460    constructing the payload for 200 (OK) and 304 (Not Modified)
461    responses to GET (Section 4.3.1).
462
463
464Section 3.1.1.1., paragraph 1:
465OLD:
466
467    HTTP uses Internet Media Types [RFC2046] in the Content-Type
468    (Section 3.1.1.5) and Accept (Section 5.3.2) header fields in order
469    to provide open and extensible data typing and type negotiation.
470    Media types define both a data format and various processing models:
471    how to process that data in accordance with each context in which it
472    is received.
473
474NEW:
475
476    HTTP uses Internet media types [RFC2046] in the Content-Type
477    (Section 3.1.1.5) and Accept (Section 5.3.2) header fields in order
478    to provide open and extensible data typing and type negotiation.
479    Media types define both a data format and various processing models:
480    how to process that data in accordance with each context in which it
481    is received.
482
483
484Section 3.1.1.1., paragraph 5:
485OLD:
486
487    The type, subtype, and parameter name tokens are case-insensitive.
488    Parameter values might or might not be case-sensitive, depending on
489    the semantics of the parameter name.  The presence or absence of a
490    parameter might be significant to the processing of a media-type,
491    depending on its definition within the media type registry.
492
493NEW:
494
495    The type, subtype, and parameter name tokens are case insensitive.
496    Parameter values might or might not be case sensitive, depending on
497    the semantics of the parameter name.  The presence or absence of a
498    parameter might be significant to the processing of a media-type,
499    depending on its definition within the media type registry.
500
501
502Section 3.1.1.1., paragraph 6:
503OLD:
504
505    A parameter value that matches the token production can be
506    transmitted as either a token or within a quoted-string.  The quoted
507    and unquoted values are equivalent.  For example, the following
508    examples are all equivalent, but the first is preferred for
509    consistency:
510
511NEW:
512
513    A parameter value that matches the token production can be
514    transmitted either as a token or within a quoted-string.  The quoted
515    and unquoted values are equivalent.  For example, the following
516    examples are all equivalent, but the first is preferred for
517    consistency:
518
519
520Section 3.1.1.2., paragraph 3:
521OLD:
522
523    Charset names ought to be registered in IANA Character Set registry
524    (<http://www.iana.org/assignments/character-sets>) according to the
525    procedures defined in [RFC2978].
526
527NEW:
528
529    Charset names ought to be registered in the IANA "Character Sets"
530    registry <http://www.iana.org/assignments/character-sets> according
531    to the procedures defined in [RFC2978].
532
533
534Section 3.1.1.3., paragraph 2:
535OLD:
536
537    MIME's canonical form requires that media subtypes of the "text" type
538    use CRLF as the text line break.  HTTP allows the transfer of text
539    media with plain CR or LF alone representing a line break, when such
540    line breaks are consistent for an entire representation.  An HTTP
541    sender MAY generate, and a recipient MUST be able to parse, line
542    breaks in text media that consist of CRLF, bare CR, or bare LF.  In
543    addition, text media in HTTP is not limited to charsets that use
544    octets 13 and 10 for CR and LF, respectively.  This flexibility
545    regarding line breaks applies only to text within a representation
546    that has been assigned a "text" media type; it does not apply to
547    "multipart" types or HTTP elements outside the payload body (e.g.,
548    header fields).
549
550NEW:
551
552    MIME's canonical form requires that media subtypes of the "text" type
553    use CRLF as the text line break.  HTTP allows the transfer of text
554    media with plain carriage return (CR) or line feed (LF) alone
555    representing a line break, when such line breaks are consistent for
556    an entire representation.  An HTTP sender MAY generate, and a
557    recipient MUST be able to parse, line breaks in text media that
558    consist of CRLF, bare CR, or bare LF.  In addition, text media in
559    HTTP is not limited to charsets that use octets 13 and 10 for CR and
560    LF, respectively.  This flexibility regarding line breaks applies
561    only to text within a representation that has been assigned a "text"
562    media type; it does not apply to "multipart" types or HTTP elements
563    outside the payload body (e.g., header fields).
564
565
566Section 3.1.2.1., paragraph 3:
567OLD:
568
569    All content-coding values are case-insensitive and ought to be
570    registered within the HTTP Content Coding registry, as defined in
571    Section 8.4.  They are used in the Accept-Encoding (Section 5.3.4)
572    and Content-Encoding (Section 3.1.2.2) header fields.
573
574NEW:
575
576    All content-coding values are case insensitive and ought to be
577    registered within the "HTTP Content Coding Registry", as defined in
578    Section 8.4.  They are used in the Accept-Encoding (Section 5.3.4)
579    and Content-Encoding (Section 3.1.2.2) header fields.
580
581
582Section 3.1.3.1., paragraph 4:
583OLD:
584
585    A language tag is a sequence of one or more case-insensitive subtags,
586    each separated by a hyphen character ("-", %x2D).  In most cases, a
587    language tag consists of a primary language subtag that identifies a
588    broad family of related languages (e.g., "en" = English) which is
589    optionally followed by a series of subtags that refine or narrow that
590    language's range (e.g., "en-CA" = the variety of English as
591    communicated in Canada).  Whitespace is not allowed within a language
592    tag.  Example tags include:
593
594NEW:
595
596    A language tag is a sequence of one or more case-insensitive subtags,
597    each separated by a hyphen character ("-", %x2D).  In most cases, a
598    language tag consists of a primary language subtag that identifies a
599    broad family of related languages (e.g., "en" = English), which is
600    optionally followed by a series of subtags that refine or narrow that
601    language's range (e.g., "en-CA" = the variety of English as
602    communicated in Canada).  Whitespace is not allowed within a language
603    tag.  Example tags include:
604
605
606Section 3.1.3.2., paragraph 5:
607OLD:
608
609    If no Content-Language is specified, the default is that the content
610    is intended for all language audiences.  This might mean that the
611    sender does not consider it to be specific to any natural language,
612    or that the sender does not know for which language it is intended.
613
614NEW:
615
616    If no Content-Language is specified, the default is that the content
617    is intended for all language audiences.  This might mean that the
618    sender does not consider it to be specific to any natural language,
619    or that the sender does not know which language is being used.
620
621
622Section 406, paragraph 1:
623OLD:
624
625    Reactive negotiation is advantageous when the response would vary
626    over commonly-used dimensions (such as type, language, or encoding),
627    when the origin server is unable to determine a user agent's
628    capabilities from examining the request, and generally when public
629    caches are used to distribute server load and reduce network usage.
630
631NEW:
632
633    Reactive negotiation is advantageous when the response would vary
634    over commonly used dimensions (such as type, language, or encoding),
635    when the origin server is unable to determine a user agent's
636    capabilities from examining the request, and generally when public
637    caches are used to distribute server load and reduce network usage.
638
639
640Section 4.1., paragraph 4:
641OLD:
642
643    HTTP was originally designed to be usable as an interface to
644    distributed object systems.  The request method was envisioned as
645    applying semantics to a target resource in much the same way as
646    invoking a defined method on an identified object would apply
647    semantics.  The method token is case-sensitive because it might be
648    used as a gateway to object-based systems with case-sensitive method
649    names.
650
651NEW:
652
653    HTTP was originally designed to be usable as an interface to
654    distributed object systems.  The request method was envisioned as
655    applying semantics to a target resource in much the same way as
656    invoking a defined method on an identified object would apply
657    semantics.  The method token is case sensitive because it might be
658    used as a gateway to object-based systems with case-sensitive method
659    names.
660
661
662Section 4.1., paragraph 5:
663OLD:
664
665    Unlike distributed objects, the standardized request methods in HTTP
666    are not resource-specific, since uniform interfaces provide for
667    better visibility and reuse in network-based systems [REST].  Once
668    defined, a standardized method ought to have the same semantics when
669    applied to any resource, though each resource determines for itself
670    whether those semantics are implemented or allowed.
671
672NEW:
673
674    Unlike distributed objects, the standardized request methods in HTTP
675    are not resource specific, since uniform interfaces provide for
676    better visibility and reuse in network-based systems [REST].  Once
677    defined, a standardized method ought to have the same semantics when
678    applied to any resource, though each resource determines for itself
679    whether those semantics are implemented or allowed.
680
681
682Section 4.1., paragraph 9:
683OLD:
684
685    Additional methods, outside the scope of this specification, have
686    been standardized for use in HTTP.  All such methods ought to be
687    registered within the HTTP Method Registry maintained by IANA, as
688    defined in Section 8.1.
689
690NEW:
691
692    Additional methods, outside the scope of this specification, have
693    been standardized for use in HTTP.  All such methods ought to be
694    registered within the "Hypertext Transfer Protocol (HTTP) Method"
695    registry maintained by IANA, as defined in Section 8.1.
696
697
698Section 4.2.1., paragraph 2:
699OLD:
700
701    This definition of safe methods does not prevent an implementation
702    from including behavior that is potentially harmful, not entirely
703    read-only, or which causes side-effects while invoking a safe method.
704    What is important, however, is that the client did not request that
705    additional behavior and cannot be held accountable for it.  For
706    example, most servers append request information to access log files
707    at the completion of every response, regardless of the method, and
708    that is considered safe even though the log storage might become full
709    and crash the server.  Likewise, a safe request initiated by
710    selecting an advertisement on the Web will often have the side-effect
711    of charging an advertising account.
712
713NEW:
714
715    This definition of safe method does not prevent an implementation
716    from including behavior that is potentially harmful, that is not
717    entirely read-only, or that causes side effects while invoking a safe
718    method.  What is important, however, is that the client did not
719    request that additional behavior and cannot be held accountable for
720    it.  For example, most servers append request information to access
721    log files at the completion of every response, regardless of the
722    method, and that is considered safe even though the log storage might
723    become full and crash the server.  Likewise, a safe request initiated
724    by selecting an advertisement on the Web will often have the side
725    effect of charging an advertising account.
726
727
728Section 4.2.1., paragraph 6:
729OLD:
730
731    When a resource is constructed such that parameters within the
732    effective request URI have the effect of selecting an action, it is
733    the resource owner's responsibility to ensure that the action is
734    consistent with the request method semantics.  For example, it is
735    common for Web-based content editing software to use actions within
736    query parameters, such as "page?do=delete".  If the purpose of such a
737    resource is to perform an unsafe action, then the resource owner MUST
738    disable or disallow that action when it is accessed using a safe
739    request method.  Failure to do so will result in unfortunate side-
740    effects when automated processes perform a GET on every URI reference
741    for the sake of link maintenance, pre-fetching, building a search
742    index, etc.
743
744NEW:
745
746    When a resource is constructed such that parameters within the
747    effective request URI have the effect of selecting an action, it is
748    the resource owner's responsibility to ensure that the action is
749    consistent with the request method semantics.  For example, it is
750    common for Web-based content editing software to use actions within
751    query parameters, such as "page?do=delete".  If the purpose of such a
752    resource is to perform an unsafe action, then the resource owner MUST
753    disable or disallow that action when it is accessed using a safe
754    request method.  Failure to do so will result in unfortunate side
755    effects when automated processes perform a GET on every URI reference
756    for the sake of link maintenance, pre-fetching, building a search
757    index, etc.
758
759
760Section 4.2.2., paragraph 2:
761OLD:
762
763    Like the definition of safe, the idempotent property only applies to
764    what has been requested by the user; a server is free to log each
765    request separately, retain a revision control history, or implement
766    other non-idempotent side-effects for each idempotent request.
767
768NEW:
769
770    Like the definition of safe, the idempotent property only applies to
771    what has been requested by the user; a server is free to log each
772    request separately, retain a revision control history, or implement
773    other non-idempotent side effects for each idempotent request.
774
775
776Section 4.2.3., paragraph 1:
777OLD:
778
779    Request methods can be defined as "cacheable" to indicate that
780    responses to them are allowed to be stored for future reuse; for
781    specific requirements see [RFC7234].  In general, safe methods that
782    do not depend on a current or authoritative response are defined as
783    cacheable; this specification defines GET, HEAD and POST as
784    cacheable, although the overwhelming majority of cache
785    implementations only support GET and HEAD.
786
787NEW:
788
789    Request methods can be defined as "cacheable" to indicate that
790    responses to them are allowed to be stored for future reuse; for
791    specific requirements see [RFC7234].  In general, safe methods that
792    do not depend on a current or authoritative response are defined as
793    cacheable; this specification defines GET, HEAD, and POST as
794    cacheable, although the overwhelming majority of cache
795    implementations only support GET and HEAD.
796
797
798Section 4.3.1., paragraph 2:
799OLD:
800
801    It is tempting to think of resource identifiers as remote file system
802    pathnames, and of representations as being a copy of the contents of
803    such files.  In fact, that is how many resources are implemented (see
804    Section 9.1 for related security considerations).  However, there are
805    no such limitations in practice.  The HTTP interface for a resource
806    is just as likely to be implemented as a tree of content objects, a
807    programmatic view on various database records, or a gateway to other
808    information systems.  Even when the URI mapping mechanism is tied to
809    a file system, an origin server might be configured to execute the
810    files with the request as input and send the output as the
811    representation, rather than transfer the files directly.  Regardless,
812    only the origin server needs to know how each of its resource
813    identifiers corresponds to an implementation, and how each
814    implementation manages to select and send a current representation of
815    the target resource in a response to GET.
816
817NEW:
818
819    It is tempting to think of resource identifiers as remote file system
820    pathnames and of representations as being a copy of the contents of
821    such files.  In fact, that is how many resources are implemented (see
822    Section 9.1 for related security considerations).  However, there are
823    no such limitations in practice.  The HTTP interface for a resource
824    is just as likely to be implemented as a tree of content objects, a
825    programmatic view on various database records, or a gateway to other
826    information systems.  Even when the URI mapping mechanism is tied to
827    a file system, an origin server might be configured to execute the
828    files with the request as input and send the output as the
829    representation rather than transfer the files directly.  Regardless,
830    only the origin server needs to know how each of its resource
831    identifiers corresponds to an implementation and how each
832    implementation manages to select and send a current representation of
833    the target resource in a response to GET.
834
835
836Section 4.3.3., paragraph 6:
837OLD:
838
839    An origin server indicates response semantics by choosing an
840    appropriate status code depending on the result of processing the
841    POST request; almost all of the status codes defined by this
842    specification might be received in a response to POST (the exceptions
843    being 206, 304, and 416).
844
845NEW:
846
847    An origin server indicates response semantics by choosing an
848    appropriate status code depending on the result of processing the
849    POST request; almost all of the status codes defined by this
850    specification might be received in a response to POST (the exceptions
851    being 206 (Partial Content), 304 (Not Modified), and 416 (Range Not
852    Satisfiable)).
853
854
855Section 4.3.4., paragraph 10:
856OLD:
857
858    An origin server MUST NOT send a validator header field
859    (Section 7.2), such as an ETag or Last-Modified field, in a
860    successful response to PUT unless the request's representation data
861    was saved without any transformation applied to the body (i.e., the
862    resource's new representation data is identical to the representation
863    data received in the PUT request) and the validator field value
864    reflects the new representation.  This requirement allows a user
865    agent to know when the representation body it has in memory remains
866    current as a result of the PUT, thus not in need of retrieving again
867    from the origin server, and that the new validator(s) received in the
868    response can be used for future conditional requests in order to
869    prevent accidental overwrites (Section 5.2).
870
871NEW:
872
873    An origin server MUST NOT send a validator header field
874    (Section 7.2), such as an ETag or Last-Modified field, in a
875    successful response to PUT unless the request's representation data
876    was saved without any transformation applied to the body (i.e., the
877    resource's new representation data is identical to the representation
878    data received in the PUT request) and the validator field value
879    reflects the new representation.  This requirement allows a user
880    agent to know when the representation body it has in memory remains
881    current as a result of the PUT, thus not in need of being retrieved
882    again from the origin server, and that the new validator(s) received
883    in the response can be used for future conditional requests in order
884    to prevent accidental overwrites (Section 5.2).
885
886
887Section 4.3.4., paragraph 13:
888OLD:
889
890    A PUT request applied to the target resource can have side-effects on
891    other resources.  For example, an article might have a URI for
892    identifying "the current version" (a resource) that is separate from
893    the URIs identifying each particular version (different resources
894    that at one point shared the same state as the current version
895    resource).  A successful PUT request on "the current version" URI
896    might therefore create a new version resource in addition to changing
897    the state of the target resource, and might also cause links to be
898    added between the related resources.
899
900NEW:
901
902    A PUT request applied to the target resource can have side effects on
903    other resources.  For example, an article might have a URI for
904    identifying "the current version" (a resource) that is separate from
905    the URIs identifying each particular version (different resources
906    that at one point shared the same state as the current version
907    resource).  A successful PUT request on "the current version" URI
908    might therefore create a new version resource in addition to changing
909    the state of the target resource, and might also cause links to be
910    added between the related resources.
911
912
913Section 4.3.5., paragraph 1:
914OLD:
915
916    The DELETE method requests that the origin server remove the
917    association between the target resource and its current
918    functionality.  In effect, this method is similar to the rm command
919    in UNIX: it expresses a deletion operation on the URI mapping of the
920    origin server, rather than an expectation that the previously
921    associated information be deleted.
922
923NEW:
924
925    The DELETE method requests that the origin server remove the
926    association between the target resource and its current
927    functionality.  In effect, this method is similar to the rm command
928    in UNIX: it expresses a deletion operation on the URI mapping of the
929    origin server rather than an expectation that the previously
930    associated information be deleted.
931
932
933Section 4.3.6., paragraph 2:
934OLD:
935
936    CONNECT is intended only for use in requests to a proxy.  An origin
937    server that receives a CONNECT request for itself MAY respond with a
938    2xx status code to indicate that a connection is established.
939    However, most origin servers do not implement CONNECT.
940
941NEW:
942
943    CONNECT is intended only for use in requests to a proxy.  An origin
944    server that receives a CONNECT request for itself MAY respond with a
945    2xx (Successful) status code to indicate that a connection is
946    established.  However, most origin servers do not implement CONNECT.
947
948
949Section 4.3.7., paragraph 1:
950OLD:
951
952    The OPTIONS method requests information about the communication
953    options available for the target resource, either at the origin
954    server or an intervening intermediary.  This method allows a client
955    to determine the options and/or requirements associated with a
956    resource, or the capabilities of a server, without implying a
957    resource action.
958
959NEW:
960
961    The OPTIONS method requests information about the communication
962    options available for the target resource, at either the origin
963    server or an intervening intermediary.  This method allows a client
964    to determine the options and/or requirements associated with a
965    resource, or the capabilities of a server, without implying a
966    resource action.
967
968
969Section 4.3.8., paragraph 2:
970OLD:
971
972    A client MUST NOT generate header fields in a TRACE request
973    containing sensitive data that might be disclosed by the response.
974 
975    For example, it would be foolish for a user agent to send stored user
976    credentials [RFC7235] or cookies [RFC6265] in a TRACE request.  The
977    final recipient of the request SHOULD exclude any request header
978    fields that are likely to contain sensitive data when that recipient
979    generates the response body.
980
981NEW:
982
983    A client MUST NOT generate header fields in a TRACE request
984    containing sensitive data that might be disclosed by the response.
985    For example, it would be foolish for a user agent to send stored user
986    credentials [RFC7235] or cookies [RFC6265] in a TRACE request.  The
987    final recipient of the request SHOULD exclude any request header
988    fields that are likely to contain sensitive data when that recipient
989    generates the response body.
990
991
992Section 5.1.1., paragraph 3:
993OLD:
994
995    The Expect field-value is case-insensitive.
996
997NEW:
998
999    The Expect field-value is case insensitive.
1000
1001
1002Section 5.1.1., paragraph 21:
1003OLD:
1004
1005       Note: The Expect header field was added after the original
1006       publication of HTTP/1.1 [RFC2068] as both the means to request an
1007       interim 100 response and the general mechanism for indicating
1008       must-understand extensions.  However, the extension mechanism has
1009       not been used by clients and the must-understand requirements have
1010       not been implemented by many servers, rendering the extension
1011       mechanism useless.  This specification has removed the extension
1012       mechanism in order to simplify the definition and processing of
1013       100-continue.
1014
1015NEW:
1016
1017       Note: The Expect header field was added after the original
1018       publication of HTTP/1.1 [RFC2068] as both the means to request an
1019       interim 100 (Continue) response and the general mechanism for
1020       indicating must-understand extensions.  However, the extension
1021       mechanism has not been used by clients and the must-understand
1022       requirements have not been implemented by many servers, rendering
1023       the extension mechanism useless.  This specification has removed
1024       the extension mechanism in order to simplify the definition and
1025       processing of 100-continue.
1026
1027
1028Section 5.1.2., paragraph 4:
1029OLD:
1030
1031    Each intermediary that receives a TRACE or OPTIONS request containing
1032    a Max-Forwards header field MUST check and update its value prior to
1033    forwarding the request.  If the received value is zero (0), the
1034    intermediary MUST NOT forward the request; instead, the intermediary
1035    MUST respond as the final recipient.  If the received Max-Forwards
1036    value is greater than zero, the intermediary MUST generate an updated
1037    Max-Forwards field in the forwarded message with a field-value that
1038    is the lesser of: a) the received value decremented by one (1), or b)
1039    the recipient's maximum supported value for Max-Forwards.
1040
1041NEW:
1042
1043    Each intermediary that receives a TRACE or OPTIONS request containing
1044    a Max-Forwards header field MUST check and update its value prior to
1045    forwarding the request.  If the received value is zero (0), the
1046    intermediary MUST NOT forward the request; instead, the intermediary
1047    MUST respond as the final recipient.  If the received Max-Forwards
1048    value is greater than zero, the intermediary MUST generate an updated
1049    Max-Forwards field in the forwarded message with a field-value that
1050    is the lesser of a) the received value decremented by one (1) or b)
1051    the recipient's maximum supported value for Max-Forwards.
1052
1053
1054Section 5.3.2., paragraph 9:
1055OLD:
1056
1057    is interpreted as "I prefer audio/basic, but send me any audio type
1058    if it is the best available after an 80% mark-down in quality".
1059
1060NEW:
1061
1062    is interpreted as "I prefer audio/basic, but send me any audio type
1063    if it is the best available after an 80% markdown in quality".
1064
1065
1066Section 5.3.5., paragraph 6:
1067OLD:
1068
1069    A request without any Accept-Language header field implies that the
1070    user agent will accept any language in response.  If the header field
1071    is present in a request and none of the available representations for
1072    the response have a matching language tag, the origin server can
1073    either disregard the header field by treating the response as if it
1074    is not subject to content negotiation, or honor the header field by
1075    sending a 406 (Not Acceptable) response.  However, the latter is not
1076    encouraged, as doing so can prevent users from accessing content that
1077    they might be able to use (with translation software, for example).
1078
1079NEW:
1080
1081    A request without any Accept-Language header field implies that the
1082    user agent will accept any language in response.  If the header field
1083    is present in a request and none of the available representations for
1084    the response have a matching language tag, the origin server can
1085    either disregard the header field by treating the response as if it
1086    is not subject to content negotiation or honor the header field by
1087    sending a 406 (Not Acceptable) response.  However, the latter is not
1088    encouraged, as doing so can prevent users from accessing content that
1089    they might be able to use (with translation software, for example).
1090
1091
1092Section 5.3.5., paragraph 10:
1093OLD:
1094
1095    Since intelligibility is highly dependent on the individual user,
1096    user agents need to allow user control over the linguistic preference
1097    (either through configuration of the user agent itself, or by
1098    defaulting to a user controllable system setting).  A user agent that
1099    does not provide such control to the user MUST NOT send an Accept-
1100    Language header field.
1101
1102NEW:
1103
1104    Since intelligibility is highly dependent on the individual user,
1105    user agents need to allow user control over the linguistic preference
1106    (either through configuration of the user agent itself or by
1107    defaulting to a user controllable system setting).  A user agent that
1108    does not provide such control to the user MUST NOT send an Accept-
1109    Language header field.
1110
1111
1112Section 5.5.1., paragraph 1:
1113OLD:
1114
1115    The "From" header field contains an Internet email address for a
1116    human user who controls the requesting user agent.  The address ought
1117    to be machine-usable, as defined by "mailbox" in Section 3.4 of
1118    [RFC5322]:
1119
1120NEW:
1121
1122    The "From" header field contains an Internet email address for a
1123    human user who controls the requesting user agent.  The address ought
1124    to be machine usable, as defined by "mailbox" in Section 3.4 of
1125    [RFC5322]:
1126
1127
1128Section 5.5.2., paragraph 6:
1129OLD:
1130
1131    If the target URI was obtained from a source that does not have its
1132    own URI (e.g., input from the user keyboard, or an entry within the
1133    user's bookmarks/favorites), the user agent MUST either exclude
1134    Referer or send it with a value of "about:blank".
1135
1136NEW:
1137
1138    If the target URI was obtained from a source that does not have its
1139    own URI (e.g., input from the user keyboard, or an entry within the
1140    user's bookmarks/favorites), the user agent MUST either exclude the
1141    Referer or send it with a value of "about:blank".
1142
1143
1144Section 5.5.2., paragraph 8:
1145OLD:
1146
1147    Some intermediaries have been known to indiscriminately remove
1148    Referer header fields from outgoing requests.  This has the
1149    unfortunate side-effect of interfering with protection against CSRF
1150    attacks, which can be far more harmful to their users.
1151    Intermediaries and user agent extensions that wish to limit
1152    information disclosure in Referer ought to restrict their changes to
1153    specific edits, such as replacing internal domain names with
1154    pseudonyms or truncating the query and/or path components.  An
1155    intermediary SHOULD NOT modify or delete the Referer header field
1156    when the field value shares the same scheme and host as the request
1157    target.
1158
1159NEW:
1160
1161    Some intermediaries have been known to indiscriminately remove
1162    Referer header fields from outgoing requests.  This has the
1163    unfortunate side effect of interfering with protection against CSRF
1164    attacks, which can be far more harmful to their users.
1165    Intermediaries and user agent extensions that wish to limit
1166    information disclosure in Referer ought to restrict their changes to
1167    specific edits, such as replacing internal domain names with
1168    pseudonyms or truncating the query and/or path components.  An
1169    intermediary SHOULD NOT modify or delete the Referer header field
1170    when the field value shares the same scheme and host as the request
1171    target.
1172
1173
1174Section 5.5.3., paragraph 1:
1175OLD:
1176
1177    The "User-Agent" header field contains information about the user
1178    agent originating the request, which is often used by servers to help
1179    identify the scope of reported interoperability problems, to work
1180    around or tailor responses to avoid particular user agent
1181    limitations, and for analytics regarding browser or operating system
1182    use.  A user agent SHOULD send a User-Agent field in each request
1183    unless specifically configured not to do so.
1184
1185NEW:
1186
1187    The "User-Agent" header field contains information about the user
1188    agent originating the request, which is often used by servers to help
1189    identify the scope of reported interoperability problems, to work
1190    around or tailor responses to avoid particular user-agent
1191    limitations, and for analytics regarding browser or operating system
1192    use.  A user agent SHOULD send a User-Agent field in each request
1193    unless specifically configured not to do so.
1194
1195
1196Section 5.5.3., paragraph 3:
1197OLD:
1198
1199    The User-Agent field-value consists of one or more product
1200    identifiers, each followed by zero or more comments (Section 3.2 of
1201    [RFC7230]), which together identify the user agent software and its
1202    significant subproducts.  By convention, the product identifiers are
1203    listed in decreasing order of their significance for identifying the
1204    user agent software.  Each product identifier consists of a name and
1205    optional version.
1206
1207NEW:
1208
1209    The User-Agent field-value consists of one or more product
1210    identifiers, each followed by zero or more comments (Section 3.2 of
1211    [RFC7230]), which together identify the user-agent software and its
1212    significant subproducts.  By convention, the product identifiers are
1213    listed in decreasing order of their significance for identifying the
1214    user-agent software.  Each product identifier consists of a name and
1215    optional version.
1216
1217
1218Section 5.5.3., paragraph 5:
1219OLD:
1220
1221    A sender SHOULD limit generated product identifiers to what is
1222    necessary to identify the product; a sender MUST NOT generate
1223    advertising or other non-essential information within the product
1224    identifier.  A sender SHOULD NOT generate information in product-
1225    version that is not a version identifier (i.e., successive versions
1226    of the same product name ought to only differ in the product-version
1227    portion of the product identifier).
1228
1229NEW:
1230
1231    A sender SHOULD limit generated product identifiers to what is
1232    necessary to identify the product; a sender MUST NOT generate
1233    advertising or other nonessential information within the product
1234    identifier.  A sender SHOULD NOT generate information in product-
1235    version that is not a version identifier (i.e., successive versions
1236    of the same product name ought only to differ in the product-version
1237    portion of the product identifier).
1238
1239
1240Section 5.5.3., paragraph 9:
1241OLD:
1242
1243    Likewise, implementations are encouraged not to use the product
1244    tokens of other implementations in order to declare compatibility
1245    with them, as this circumvents the purpose of the field.  If a user
1246    agent masquerades as a different user agent, recipients can assume
1247    that the user intentionally desires to see responses tailored for
1248    that identified user agent, even if they might not work as well for
1249    the actual user agent being used.
1250
1251NEW:
1252
1253    Likewise, implementations are encouraged not to use the product
1254    tokens of other implementations in order to declare compatibility
1255    with them, as this circumvents the purpose of the field.  If a user
1256    agent masquerades as a different user agent, recipients can assume
1257    that the user intentionally desires to see responses tailored for
1258    that identified user agent, even if they might not work as well for
1259    the actual user agent being implemented.
1260
1261
1262Section 6., paragraph 1:
1263OLD:
1264
1265    The status-code element is a 3-digit integer code giving the result
1266    of the attempt to understand and satisfy the request.
1267
1268NEW:
1269
1270    The status-code element is a three-digit integer code giving the
1271    result of the attempt to understand and satisfy the request.
1272
1273
1274Section 6., paragraph 3:
1275OLD:
1276
1277    For example, if an unrecognized status code of 471 is received by a
1278    client, the client can assume that there was something wrong with its
1279    request and treat the response as if it had received a 400 status
1280    code.  The response message will usually contain a representation
1281    that explains the status.
1282
1283NEW:
1284
1285    For example, if an unrecognized status code of 471 is received by a
1286    client, the client can assume that there was something wrong with its
1287    request and treat the response as if it had received a 400 (Bad
1288    Request) status code.  The response message will usually contain a
1289    representation that explains the status.
1290
1291
1292Section 6., paragraph 4:
1293OLD:
1294
1295    The first digit of the status-code defines the class of response.
1296    The last two digits do not have any categorization role.  There are 5
1297    values for the first digit:
1298
1299NEW:
1300
1301    The first digit of the status-code defines the class of response.
1302    The last two digits do not have any categorization role.  There are
1303    five values for the first digit:
1304
1305
1306Section 6.1., paragraph 2:
1307OLD:
1308
1309    Responses with status codes that are defined as cacheable by default
1310    (e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501 in this
1311    specification) can be reused by a cache with heuristic expiration
1312    unless otherwise indicated by the method definition or explicit cache
1313    controls [RFC7234]; all other status codes are not cacheable by
1314    default.
1315
1316NEW:
1317
1318    Responses with status codes that are defined as cacheable by default
1319    (e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501 in
1320    this specification) can be reused by a cache with heuristic
1321    expiration unless otherwise indicated by the method definition or
1322    explicit cache controls [RFC7234]; all other status codes are not
1323    cacheable by default.
1324
1325
1326Section 6.1., paragraph 3:
1327OLD:
1328
1329    +------+-------------------------------+--------------------------+
1330    | code | reason-phrase                 | Defined in...            |
1331    +------+-------------------------------+--------------------------+
1332    | 100  | Continue                      | Section 6.2.1            |
1333    | 101  | Switching Protocols           | Section 6.2.2            |
1334    | 200  | OK                            | Section 6.3.1            |
1335    | 201  | Created                       | Section 6.3.2            |
1336    | 202  | Accepted                      | Section 6.3.3            |
1337    | 203  | Non-Authoritative Information | Section 6.3.4            |
1338    | 204  | No Content                    | Section 6.3.5            |
1339    | 205  | Reset Content                 | Section 6.3.6            |
1340    | 206  | Partial Content               | Section 4.1 of [RFC7233] |
1341    | 300  | Multiple Choices              | Section 6.4.1            |
1342    | 301  | Moved Permanently             | Section 6.4.2            |
1343    | 302  | Found                         | Section 6.4.3            |
1344    | 303  | See Other                     | Section 6.4.4            |
1345    | 304  | Not Modified                  | Section 4.1 of [RFC7232] |
1346    | 305  | Use Proxy                     | Section 6.4.5            |
1347    | 307  | Temporary Redirect            | Section 6.4.7            |
1348    | 400  | Bad Request                   | Section 6.5.1            |
1349    | 401  | Unauthorized                  | Section 3.1 of [RFC7235] |
1350    | 402  | Payment Required              | Section 6.5.2            |
1351    | 403  | Forbidden                     | Section 6.5.3            |
1352    | 404  | Not Found                     | Section 6.5.4            |
1353    | 405  | Method Not Allowed            | Section 6.5.5            |
1354    | 406  | Not Acceptable                | Section 6.5.6            |
1355    | 407  | Proxy Authentication Required | Section 3.2 of [RFC7235] |
1356    | 408  | Request Time-out              | Section 6.5.7            |
1357    | 409  | Conflict                      | Section 6.5.8            |
1358    | 410  | Gone                          | Section 6.5.9            |
1359    | 411  | Length Required               | Section 6.5.10           |
1360    | 412  | Precondition Failed           | Section 4.2 of [RFC7232] |
1361    | 413  | Payload Too Large             | Section 6.5.11           |
1362    | 414  | URI Too Long                  | Section 6.5.12           |
1363    | 415  | Unsupported Media Type        | Section 6.5.13           |
1364    | 416  | Range Not Satisfiable         | Section 4.4 of [RFC7233] |
1365    | 417  | Expectation Failed            | Section 6.5.14           |
1366    | 426  | Upgrade Required              | Section 6.5.15           |
1367    | 500  | Internal Server Error         | Section 6.6.1            |
1368    | 501  | Not Implemented               | Section 6.6.2            |
1369    | 502  | Bad Gateway                   | Section 6.6.3            |
1370    | 503  | Service Unavailable           | Section 6.6.4            |
1371    | 504  | Gateway Time-out              | Section 6.6.5            |
1372    | 505  | HTTP Version Not Supported    | Section 6.6.6            |
1373    +------+-------------------------------+--------------------------+
1374
1375NEW:
1376
1377    +------+-------------------------------+--------------------------+
1378    | Code | Reason-Phrase                 | Defined in...            |
1379    +------+-------------------------------+--------------------------+
1380    | 100  | Continue                      | Section 6.2.1            |
1381    | 101  | Switching Protocols           | Section 6.2.2            |
1382    | 200  | OK                            | Section 6.3.1            |
1383    | 201  | Created                       | Section 6.3.2            |
1384    | 202  | Accepted                      | Section 6.3.3            |
1385    | 203  | Non-Authoritative Information | Section 6.3.4            |
1386    | 204  | No Content                    | Section 6.3.5            |
1387    | 205  | Reset Content                 | Section 6.3.6            |
1388    | 206  | Partial Content               | Section 4.1 of [RFC7233] |
1389    | 300  | Multiple Choices              | Section 6.4.1            |
1390    | 301  | Moved Permanently             | Section 6.4.2            |
1391    | 302  | Found                         | Section 6.4.3            |
1392    | 303  | See Other                     | Section 6.4.4            |
1393    | 304  | Not Modified                  | Section 4.1 of [RFC7232] |
1394    | 305  | Use Proxy                     | Section 6.4.5            |
1395    | 307  | Temporary Redirect            | Section 6.4.7            |
1396    | 400  | Bad Request                   | Section 6.5.1            |
1397    | 401  | Unauthorized                  | Section 3.1 of [RFC7235] |
1398    | 402  | Payment Required              | Section 6.5.2            |
1399    | 403  | Forbidden                     | Section 6.5.3            |
1400    | 404  | Not Found                     | Section 6.5.4            |
1401    | 405  | Method Not Allowed            | Section 6.5.5            |
1402    | 406  | Not Acceptable                | Section 6.5.6            |
1403    | 407  | Proxy Authentication Required | Section 3.2 of [RFC7235] |
1404    | 408  | Request Time-out              | Section 6.5.7            |
1405    | 409  | Conflict                      | Section 6.5.8            |
1406    | 410  | Gone                          | Section 6.5.9            |
1407    | 411  | Length Required               | Section 6.5.10           |
1408    | 412  | Precondition Failed           | Section 4.2 of [RFC7232] |
1409    | 413  | Payload Too Large             | Section 6.5.11           |
1410    | 414  | URI Too Long                  | Section 6.5.12           |
1411    | 415  | Unsupported Media Type        | Section 6.5.13           |
1412    | 416  | Range Not Satisfiable         | Section 4.4 of [RFC7233] |
1413    | 417  | Expectation Failed            | Section 6.5.14           |
1414    | 426  | Upgrade Required              | Section 6.5.15           |
1415    | 500  | Internal Server Error         | Section 6.6.1            |
1416    | 501  | Not Implemented               | Section 6.6.2            |
1417    | 502  | Bad Gateway                   | Section 6.6.3            |
1418    | 503  | Service Unavailable           | Section 6.6.4            |
1419    | 504  | Gateway Time-out              | Section 6.6.5            |
1420    | 505  | HTTP Version Not Supported    | Section 6.6.6            |
1421    +------+-------------------------------+--------------------------+
1422
1423
1424Section 6.2., paragraph 1:
1425OLD:
1426
1427    The 1xx (Informational) class of status code indicates an interim
1428    response for communicating connection status or request progress
1429    prior to completing the requested action and sending a final
1430    response.  All 1xx responses consist of only the status-line and
1431    optional header fields, and thus are terminated by the empty line at
1432    the end of the header section.  Since HTTP/1.0 did not define any 1xx
1433    status codes, a server MUST NOT send a 1xx response to an HTTP/1.0
1434    client.
1435
1436NEW:
1437
1438    The 1xx (Informational) class of status code indicates an interim
1439    response for communicating connection status or request progress
1440    prior to completing the requested action and sending a final
1441    response.  All 1xx responses consist of only the status-line and
1442    optional header fields and, thus, are terminated by the empty line at
1443    the end of the header section.  Since HTTP/1.0 did not define any 1xx
1444    status codes, a server MUST NOT send a 1xx response to an HTTP/1.0
1445    client.
1446
1447
1448Section 6.3.3., paragraph 2:
1449OLD:
1450
1451    The 202 response is intentionally non-committal.  Its purpose is to
1452    allow a server to accept a request for some other process (perhaps a
1453    batch-oriented process that is only run once per day) without
1454    requiring that the user agent's connection to the server persist
1455    until the process is completed.  The representation sent with this
1456    response ought to describe the request's current status and point to
1457    (or embed) a status monitor that can provide the user with an
1458    estimate of when the request will be fulfilled.
1459
1460NEW:
1461
1462    The 202 response is intentionally noncommittal.  Its purpose is to
1463    allow a server to accept a request for some other process (perhaps a
1464    batch-oriented process that is only run once per day) without
1465    requiring that the user agent's connection to the server persist
1466    until the process is completed.  The representation sent with this
1467    response ought to describe the request's current status and point to
1468    (or embed) a status monitor that can provide the user with an
1469    estimate of when the request will be fulfilled.
1470
1471
1472Section 6.4.1., paragraph 5:
1473OLD:
1474
1475       Note: The original proposal for 300 defined the URI header field
1476       as providing a list of alternative representations, such that it
1477       would be usable for 200, 300, and 406 responses and be transferred
1478       in responses to the HEAD method.  However, lack of deployment and
1479       disagreement over syntax led to both URI and Alternates (a
1480       subsequent proposal) being dropped from this specification.  It is
1481       possible to communicate the list using a set of Link header fields
1482       [RFC5988], each with a relationship of "alternate", though
1483       deployment is a chicken-and-egg problem.
1484
1485NEW:
1486
1487       Note: The original proposal for the 300 response defined the URI
1488       header field as providing a list of alternative representations,
1489       such that it would be usable for 200, 300, and 406 responses and
1490       be transferred in responses to the HEAD method.  However, lack of
1491       deployment and disagreement over syntax led to both URI and
1492       Alternates (a subsequent proposal) being dropped from this
1493       specification.  It is possible to communicate the list using a set
1494       of Link header fields [RFC5988], each with a relationship of
1495       "alternate", though deployment is a chicken-and-egg problem.
1496
1497
1498Section 6.4.2., paragraph 1:
1499OLD:
1500
1501    The 301 (Moved Permanently) status code indicates that the target
1502    resource has been assigned a new permanent URI and any future
1503    references to this resource ought to use one of the enclosed URIs.
1504    Clients with link editing capabilities ought to automatically re-link
1505    references to the effective request URI to one or more of the new
1506    references sent by the server, where possible.
1507
1508NEW:
1509
1510    The 301 (Moved Permanently) status code indicates that the target
1511    resource has been assigned a new permanent URI and any future
1512    references to this resource ought to use one of the enclosed URIs.
1513    Clients with link-editing capabilities ought to automatically re-link
1514    references to the effective request URI to one or more of the new
1515    references sent by the server, where possible.
1516
1517
1518Section 6.4.4., paragraph 2:
1519OLD:
1520
1521    This status code is applicable to any HTTP method.  It is primarily
1522    used to allow the output of a POST action to redirect the user agent
1523    to a selected resource, since doing so provides the information
1524    corresponding to the POST response in a form that can be separately
1525    identified, bookmarked, and cached independent of the original
1526    request.
1527
1528NEW:
1529
1530    This status code is applicable to any HTTP method.  It is primarily
1531    used to allow the output of a POST action to redirect the user agent
1532    to a selected resource, since doing so provides the information
1533    corresponding to the POST response in a form that can be separately
1534    identified, bookmarked, and cached, independent of the original
1535    request.
1536
1537
1538Section 6.4.7., paragraph 3:
1539OLD:
1540
1541       Note: This status code is similar to 302 (Found), except that it
1542       does not allow changing the request method from POST to GET.  This
1543       specification defines no equivalent counterpart for 301 (Moved
1544       Permanently) ([status-308], however, defines the status code 308
1545       (Permanent Redirect) for this purpose).
1546
1547NEW:
1548
1549       Note: This status code is similar to 302 (Found), except that it
1550       does not allow changing the request method from POST to GET.  This
1551       specification defines no equivalent counterpart for 301 (Moved
1552       Permanently) ([RFC7238]; however, it defines the status code 308
1553       (Permanent Redirect) for this purpose).
1554
1555
1556Section 6.5.1., paragraph 1:
1557OLD:
1558
1559    The 400 (Bad Request) status code indicates that the server cannot or
1560    will not process the request due to something which is perceived to
1561    be a client error (e.g., malformed request syntax, invalid request
1562    message framing, or deceptive request routing).
1563
1564NEW:
1565
1566    The 400 (Bad Request) status code indicates that the server cannot or
1567    will not process the request due to something that is perceived to be
1568    a client error (e.g., malformed request syntax, invalid request
1569    message framing, or deceptive request routing).
1570
1571
1572Section 5.3, paragraph 0:
1573OLD:
1574
1575    The 414 (URI Too Long) status code indicates that the server is
1576    refusing to service the request because the request-target (Section
1577    5.3 of [RFC7230]) is longer than the server is willing to interpret.
1578    This rare condition is only likely to occur when a client has
1579    improperly converted a POST request to a GET request with long query
1580    information, when the client has descended into a "black hole" of
1581    redirection (e.g., a redirected URI prefix that points to a suffix of
1582    itself), or when the server is under attack by a client attempting to
1583    exploit potential security holes.
1584
1585NEW:
1586
1587    The 414 (URI Too Long) status code indicates that the server is
1588    refusing to service the request because the request-target (Section
1589    5.3 of [RFC7230]) is longer than the server is willing to interpret.
1590    This rare condition is only likely to occur when a client has
1591    improperly converted a POST request to a GET request with long query
1592    information, when the client has descended into a "black hole" of
1593    redirection (e.g., a redirected URI prefix that points to a suffix of
1594    itself) or when the server is under attack by a client attempting to
1595    exploit potential security holes.
1596
1597
1598Section 7.1.1.1., paragraph 11:
1599OLD:
1600
1601      day-name     = %x4D.6F.6E ; "Mon", case-sensitive
1602                   / %x54.75.65 ; "Tue", case-sensitive
1603                   / %x57.65.64 ; "Wed", case-sensitive
1604                   / %x54.68.75 ; "Thu", case-sensitive
1605                   / %x46.72.69 ; "Fri", case-sensitive
1606                   / %x53.61.74 ; "Sat", case-sensitive
1607                   / %x53.75.6E ; "Sun", case-sensitive
1608
1609NEW:
1610
1611      day-name     = %x4D.6F.6E ; "Mon", case sensitive
1612                   / %x54.75.65 ; "Tue", case sensitive
1613                   / %x57.65.64 ; "Wed", case sensitive
1614                   / %x54.68.75 ; "Thu", case sensitive
1615                   / %x46.72.69 ; "Fri", case sensitive
1616                   / %x53.61.74 ; "Sat", case sensitive
1617                   / %x53.75.6E ; "Sun", case sensitive
1618
1619
1620Section 7.1.1.1., paragraph 13:
1621OLD:
1622
1623      day          = 2DIGIT
1624      month        = %x4A.61.6E ; "Jan", case-sensitive
1625                   / %x46.65.62 ; "Feb", case-sensitive
1626                   / %x4D.61.72 ; "Mar", case-sensitive
1627                   / %x41.70.72 ; "Apr", case-sensitive
1628                   / %x4D.61.79 ; "May", case-sensitive
1629                   / %x4A.75.6E ; "Jun", case-sensitive
1630                   / %x4A.75.6C ; "Jul", case-sensitive
1631                   / %x41.75.67 ; "Aug", case-sensitive
1632                   / %x53.65.70 ; "Sep", case-sensitive
1633                   / %x4F.63.74 ; "Oct", case-sensitive
1634                   / %x4E.6F.76 ; "Nov", case-sensitive
1635                   / %x44.65.63 ; "Dec", case-sensitive
1636      year         = 4DIGIT
1637
1638NEW:
1639
1640      day          = 2DIGIT
1641      month        = %x4A.61.6E ; "Jan", case sensitive
1642                   / %x46.65.62 ; "Feb", case sensitive
1643                   / %x4D.61.72 ; "Mar", case sensitive
1644                   / %x41.70.72 ; "Apr", case sensitive
1645                   / %x4D.61.79 ; "May", case sensitive
1646                   / %x4A.75.6E ; "Jun", case sensitive
1647                   / %x4A.75.6C ; "Jul", case sensitive
1648                   / %x41.75.67 ; "Aug", case sensitive
1649                   / %x53.65.70 ; "Sep", case sensitive
1650                   / %x4F.63.74 ; "Oct", case sensitive
1651                   / %x4E.6F.76 ; "Nov", case sensitive
1652                   / %x44.65.63 ; "Dec", case sensitive
1653      year         = 4DIGIT
1654
1655
1656Section 7.1.1.1., paragraph 14:
1657OLD:
1658
1659      GMT          = %x47.4D.54 ; "GMT", case-sensitive
1660
1661NEW:
1662
1663      GMT          = %x47.4D.54 ; "GMT", case sensitive
1664
1665
1666Section 7.1.1.1., paragraph 19:
1667OLD:
1668
1669      day-name-l   = %x4D.6F.6E.64.61.79    ; "Monday", case-sensitive
1670             / %x54.75.65.73.64.61.79       ; "Tuesday", case-sensitive
1671             / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive
1672             / %x54.68.75.72.73.64.61.79    ; "Thursday", case-sensitive
1673             / %x46.72.69.64.61.79          ; "Friday", case-sensitive
1674             / %x53.61.74.75.72.64.61.79    ; "Saturday", case-sensitive
1675             / %x53.75.6E.64.61.79          ; "Sunday", case-sensitive
1676
1677NEW:
1678
1679      day-name-l   = %x4D.6F.6E.64.61.79    ; "Monday", case sensitive
1680             / %x54.75.65.73.64.61.79       ; "Tuesday", case sensitive
1681             / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case sensitive
1682             / %x54.68.75.72.73.64.61.79    ; "Thursday", case sensitive
1683             / %x46.72.69.64.61.79          ; "Friday", case sensitive
1684             / %x53.61.74.75.72.64.61.79    ; "Saturday", case sensitive
1685             / %x53.75.6E.64.61.79          ; "Sunday", case sensitive
1686
1687
1688Section 7.1.2., paragraph 5:
1689OLD:
1690
1691    If the Location value provided in a 3xx (Redirection) does not have a
1692    fragment component, a user agent MUST process the redirection as if
1693    the value inherits the fragment component of the URI reference used
1694    to generate the request target (i.e., the redirection inherits the
1695    original reference's fragment, if any).
1696
1697NEW:
1698
1699    If the Location value provided in a 3xx (Redirection) response does
1700    not have a fragment component, a user agent MUST process the
1701    redirection as if the value inherits the fragment component of the
1702    URI reference used to generate the request target (i.e., the
1703    redirection inherits the original reference's fragment, if any).
1704
1705
1706Section 7.1.4., paragraph 1:
1707OLD:
1708
1709    The "Vary" header field in a response describes what parts of a
1710    request message, aside from the method, Host header field, and
1711    request target, might influence the origin server's process for
1712    selecting and representing this response.  The value consists of
1713    either a single asterisk ("*") or a list of header field names (case-
1714    insensitive).
1715
1716NEW:
1717
1718    The "Vary" header field in a response describes what parts of a
1719    request message, aside from the method, Host header field, and
1720    request target, might influence the origin server's process for
1721    selecting and representing this response.  The value consists of
1722    either a single asterisk ("*") or a list of header field names (case
1723    insensitive).
1724
1725
1726Section 1., paragraph 1:
1727OLD:
1728
1729    2.  To inform user agent recipients that this response is subject to
1730        content negotiation (Section 5.3) and that a different
1731        representation might be sent in a subsequent request if
1732        additional parameters are provided in the listed header fields
1733        (proactive negotiation).
1734
1735NEW:
1736
1737    2.  To inform user-agent recipients that this response is subject to
1738        content negotiation (Section 5.3) and that a different
1739        representation might be sent in a subsequent request if
1740        additional parameters are provided in the listed header fields
1741        (proactive negotiation).
1742
1743
1744Section 7.2., paragraph 3:
1745OLD:
1746
1747    For example, an ETag header field in a 201 response communicates the
1748    entity-tag of the newly created resource's representation, so that it
1749    can be used in later conditional requests to prevent the "lost
1750    update" problem [RFC7232].
1751
1752NEW:
1753
1754    For example, an ETag header field in a 201 (Created) response
1755    communicates the entity-tag of the newly created resource's
1756    representation, so that it can be used in later conditional requests
1757    to prevent the "lost update" problem [RFC7232].
1758
1759
1760Section 8.1., paragraph 1:
1761OLD:
1762
1763    The HTTP Method Registry defines the name space for the request
1764    method token (Section 4).  The method registry will be created and
1765    maintained at (the suggested URI)
1766    <http://www.iana.org/assignments/http-methods>.
1767
1768NEW:
1769
1770    The "Hypertext Transfer Protocol (HTTP) Method Registry" defines the
1771    namespace for the request method token (Section 4).  The "HTTP Method
1772    Registry" has been created and is now maintained at
1773    <http://www.iana.org/assignments/http-methods>.
1774
1775
1776Section 8.1.2., paragraph 3:
1777OLD:
1778
1779    A new method definition needs to indicate whether it is safe
1780    (Section 4.2.1), idempotent (Section 4.2.2), cacheable
1781    (Section 4.2.3), what semantics are to be associated with the payload
1782    body if any is present in the request, and what refinements the
1783    method makes to header field or status code semantics.  If the new
1784    method is cacheable, its definition ought to describe how, and under
1785    what conditions, a cache can store a response and use it to satisfy a
1786    subsequent request.  The new method ought to describe whether it can
1787    be made conditional (Section 5.2) and, if so, how a server responds
1788    when the condition is false.  Likewise, if the new method might have
1789    some use for partial response semantics ([RFC7233]), it ought to
1790    document this too.
1791
1792NEW:
1793
1794    A new method definition needs to indicate whether it is safe
1795    (Section 4.2.1), idempotent (Section 4.2.2), or cacheable
1796    (Section 4.2.3).  It needs to indicate what semantics are to be
1797    associated with the payload body if any is present in the request and
1798    what refinements the method makes to header field or status code
1799    semantics.  If the new method is cacheable, its definition ought to
1800    describe how, and under what conditions, a cache can store a response
1801    and use it to satisfy a subsequent request.  The new method ought to
1802    describe whether it can be made conditional (Section 5.2) and, if so,
1803    how a server responds when the condition is false.  Likewise, if the
1804    new method might have some use for partial response semantics
1805    ([RFC7233]), it ought to document this, too.
1806
1807
1808Section 8.1.3., paragraph 1:
1809OLD:
1810
1811    The HTTP Method Registry shall be populated with the registrations
1812    below:
1813
1814NEW:
1815
1816    The "Hypertext Transfer Protocol (HTTP) Method Registry" has been
1817    populated with the registrations below:
1818
1819
1820Section 8.2., paragraph 1:
1821OLD:
1822
1823    The HTTP Status Code Registry defines the name space for the response
1824    status-code token (Section 6).  The status code registry is
1825    maintained at <http://www.iana.org/assignments/http-status-codes>.
1826
1827NEW:
1828
1829    The "Hypertext Transfer Protocol (HTTP) Status Code Registry" defines
1830    the namespace for the response status-code token (Section 6).  The
1831    "HTTP Status Codes" registry is maintained at
1832    <http://www.iana.org/assignments/http-status-codes>.
1833
1834
1835Section 8.2., paragraph 2:
1836OLD:
1837
1838    This Section replaces the registration procedure for HTTP Status
1839    Codes previously defined in Section 7.1 of [RFC2817].
1840
1841NEW:
1842
1843    This section replaces the registration procedure for HTTP Status
1844    Codes previously defined in Section 7.1 of [RFC2817].
1845
1846
1847Section 8.2.3., paragraph 1:
1848OLD:
1849
1850    The HTTP Status Code Registry shall be updated with the registrations
1851    below:
1852
1853NEW:
1854
1855    The "HTTP Status Codes" registry has been updated with the
1856    registrations below:
1857
1858
1859Section 8.3., paragraph 1:
1860OLD:
1861
1862    HTTP header fields are registered within the Message Header Field
1863    Registry located at <http://www.iana.org/assignments/message-headers/
1864    message-header-index.html>, as defined by [BCP90].
1865
1866NEW:
1867
1868    HTTP header fields are registered within the "Message Headers"
1869    registry located at <http://www.iana.org/assignments/message-headers>
1870    as defined by [BCP90].
1871
1872
1873Section 8.3.1., paragraph 3:
1874OLD:
1875
1876    Authors of specifications defining new fields are advised to keep the
1877    name as short as practical and to not prefix the name with "X-"
1878    unless the header field will never be used on the Internet.  (The
1879    "x-" prefix idiom has been extensively misused in practice; it was
1880    intended to only be used as a mechanism for avoiding name collisions
1881    inside proprietary software or intranet processing, since the prefix
1882    would ensure that private names never collide with a newly registered
1883    Internet name; see [BCP178] for further information)
1884
1885NEW:
1886
1887    Authors of specifications defining new fields are advised to keep the
1888    name as short as practical and not to prefix the name with "X-"
1889    unless the header field will never be used on the Internet.  (The
1890    "X-" prefix idiom has been extensively misused in practice; it was
1891    intended to only be used as a mechanism for avoiding name collisions
1892    inside proprietary software or intranet processing, since the prefix
1893    would ensure that private names never collide with a newly registered
1894    Internet name; see [BCP178] for further information).
1895
1896
1897Section 8.3.1., paragraph 4:
1898OLD:
1899
1900    New header field values typically have their syntax defined using
1901    ABNF ([RFC5234]), using the extension defined in Section 7 of
1902    [RFC7230] as necessary, and are usually constrained to the range of
1903    ASCII characters.  Header fields needing a greater range of
1904    characters can use an encoding such as the one defined in [RFC5987].
1905
1906NEW:
1907
1908    New header field values typically have their syntax defined using
1909    ABNF ([RFC5234]) (implementing the extension defined in Section 7 of
1910    [RFC7230] as necessary), and they are usually constrained to the
1911    range of ASCII characters.  Header fields needing a greater range of
1912    characters can use an encoding such as the one defined in [RFC5987].
1913
1914
1915Section 8.3.1., paragraph 13:
1916OLD:
1917
1918    o  Whether the field is a single value, or whether it can be a list
1919       (delimited by commas; see Section 3.2 of [RFC7230]).
1920
1921NEW:
1922
1923    o  Whether the field is a single value or whether it can be a list
1924       (delimited by commas; see Section 3.2 of [RFC7230]).
1925
1926
1927Section 8.3.2., paragraph 1:
1928OLD:
1929
1930    The Message Header Field Registry shall be updated with the following
1931    permanent registrations:
1932
1933NEW:
1934
1935    The "Message Headers" registry has been updated with the following
1936    permanent registrations:
1937
1938
1939Section 8.3.2., paragraph 2:
1940OLD:
1941
1942    +-------------------+----------+----------+-----------------+
1943    | Header Field Name | Protocol | Status   | Reference       |
1944    +-------------------+----------+----------+-----------------+
1945    | Accept            | http     | standard | Section 5.3.2   |
1946    | Accept-Charset    | http     | standard | Section 5.3.3   |
1947    | Accept-Encoding   | http     | standard | Section 5.3.4   |
1948    | Accept-Language   | http     | standard | Section 5.3.5   |
1949    | Allow             | http     | standard | Section 7.4.1   |
1950    | Content-Encoding  | http     | standard | Section 3.1.2.2 |
1951    | Content-Language  | http     | standard | Section 3.1.3.2 |
1952    | Content-Location  | http     | standard | Section 3.1.4.2 |
1953    | Content-Type      | http     | standard | Section 3.1.1.5 |
1954    | Date              | http     | standard | Section 7.1.1.2 |
1955    | Expect            | http     | standard | Section 5.1.1   |
1956    | From              | http     | standard | Section 5.5.1   |
1957    | Location          | http     | standard | Section 7.1.2   |
1958    | MIME-Version      | http     | standard | Appendix A.1    |
1959    | Max-Forwards      | http     | standard | Section 5.1.2   |
1960    | Referer           | http     | standard | Section 5.5.2   |
1961    | Retry-After       | http     | standard | Section 7.1.3   |
1962    | Server            | http     | standard | Section 7.4.2   |
1963    | User-Agent        | http     | standard | Section 5.5.3   |
1964    | Vary              | http     | standard | Section 7.1.4   |
1965    +-------------------+----------+----------+-----------------+
1966
1967NEW:
1968
1969    +-------------------+----------+----------+-----------------+
1970    | Header Field Name | Protocol | Status   | Reference       |
1971    +-------------------+----------+----------+-----------------+
1972    | Accept            | http     | standard | Section 5.3.2   |
1973    | Accept-Charset    | http     | standard | Section 5.3.3   |
1974    | Accept-Encoding   | http     | standard | Section 5.3.4   |
1975    | Accept-Language   | http     | standard | Section 5.3.5   |
1976    | Allow             | http     | standard | Section 7.4.1   |
1977    | Content-Encoding  | http     | standard | Section 3.1.2.2 |
1978    | Content-Language  | http     | standard | Section 3.1.3.2 |
1979    | Content-Location  | http     | standard | Section 3.1.4.2 |
1980    | Content-Type      | http     | standard | Section 3.1.1.5 |
1981    | Date              | http     | standard | Section 7.1.1.2 |
1982    | Expect            | http     | standard | Section 5.1.1   |
1983    | From              | http     | standard | Section 5.5.1   |
1984    | Location          | http     | standard | Section 7.1.2   |
1985    | Max-Forwards      | http     | standard | Section 5.1.2   |
1986    | MIME-Version      | http     | standard | Appendix A.1    |
1987    | Referer           | http     | standard | Section 5.5.2   |
1988    | Retry-After       | http     | standard | Section 7.1.3   |
1989    | Server            | http     | standard | Section 7.4.2   |
1990    | User-Agent        | http     | standard | Section 5.5.3   |
1991    | Vary              | http     | standard | Section 7.1.4   |
1992    +-------------------+----------+----------+-----------------+
1993
1994
1995Section 8.4., paragraph 1:
1996OLD:
1997
1998    The HTTP Content Coding Registry defines the name space for content
1999    coding names (Section 4.2 of [RFC7230]).  The content coding registry
2000    is maintained at <http://www.iana.org/assignments/http-parameters>.
2001
2002NEW:
2003
2004    The "HTTP Content Coding Registry" defines the namespace for content
2005    coding names (Section 4.2 of [RFC7230]).  The "HTTP Content Coding
2006    Registry" is maintained at
2007    <http://www.iana.org/assignments/http-parameters>.
2008
2009
2010Section 8.4.1., paragraph 1:
2011OLD:
2012
2013    Content Coding registrations MUST include the following fields:
2014
2015NEW:
2016
2017    Content coding registrations MUST include the following fields:
2018
2019
2020Section 8.4.1., paragraph 6:
2021OLD:
2022
2023    Values to be added to this name space require IETF Review (see
2024    Section 4.1 of [RFC5226]), and MUST conform to the purpose of content
2025    coding defined in this section.
2026
2027NEW:
2028
2029    Values to be added to this namespace require IETF Review (see Section
2030    4.1 of [RFC5226]) and MUST conform to the purpose of content coding
2031    defined in this section.
2032
2033
2034Section 8.4.2., paragraph 1:
2035OLD:
2036
2037    The HTTP Content Codings Registry shall be updated with the
2038    registrations below:
2039
2040NEW:
2041
2042    The "HTTP Content Codings Registry" has been updated with the
2043    registrations below:
2044
2045
2046Section 9., paragraph 2:
2047OLD:
2048
2049    The list of considerations below is not exhaustive.  Most security
2050    concerns related to HTTP semantics are about securing server-side
2051    applications (code behind the HTTP interface), securing user agent
2052    processing of payloads received via HTTP, or secure use of the
2053    Internet in general, rather than security of the protocol.  Various
2054    organizations maintain topical information and links to current
2055    research on Web application security (e.g., [OWASP]).
2056
2057NEW:
2058
2059    The list of considerations below is not exhaustive.  Most security
2060    concerns related to HTTP semantics are about securing server-side
2061    applications (code behind the HTTP interface) or securing user-agent
2062    processing of payloads received via HTTP.  Secure use of the Internet
2063    in general, rather than security of the protocol, might also be
2064    related.  Various organizations maintain topical information and
2065    links to current research on Web application security (e.g.,
2066    [OWASP]).
2067
2068
2069Section 9., paragraph 3:
2070OLD:
2071
2072 9.1.  Attacks Based On File and Path Names
2073
2074NEW:
2075
2076 9.1.  Attacks Based on File and Path Names
2077
2078
2079Section 9., paragraph 4:
2080OLD:
2081
2082    Origin servers frequently make use of their local file system to
2083    manage the mapping from effective request URI to resource
2084    representations.  Implementers need to be aware that most file
2085    systems are not designed to protect against malicious file or path
2086    names, and thus depend on the origin server to avoid mapping to file
2087    names, folders, or directories that have special significance to the
2088    system.
2089
2090NEW:
2091
2092    Origin servers frequently make use of their local file system to
2093    manage the mapping from effective request URI to resource
2094    representations.  Implementers need to be aware that most file
2095    systems are not designed to protect against malicious file or path
2096    names and, thus, depend on the origin server to avoid mapping to file
2097    names, folders, or directories that have special significance to the
2098    system.
2099
2100
2101Section 9., paragraph 5:
2102OLD:
2103
2104    For example, UNIX, Microsoft Windows, and other operating systems use
2105    ".." as a path component to indicate a directory level above the
2106    current one, and use specially named paths or file names to send data
2107    to system devices.  Similar naming conventions might exist within
2108    other types of storage systems.  Likewise, local storage systems have
2109    an annoying tendency to prefer user-friendliness over security when
2110    handling invalid or unexpected characters, recomposition of
2111    decomposed characters, and case-normalization of case-insensitive
2112    names.
2113
2114NEW:
2115
2116    For example, UNIX, Microsoft Windows, and other operating systems use
2117    ".." as a path component to indicate a directory level above the
2118    current one, and they use specially named paths or file names to send
2119    data to system devices.  Similar naming conventions might exist
2120    within other types of storage systems.  Likewise, local storage
2121    systems have an annoying tendency to prefer user-friendliness over
2122    security when handling invalid or unexpected characters,
2123    recomposition of decomposed characters, and case-normalization of
2124    case-insensitive names.
2125
2126
2127Section 9., paragraph 7:
2128OLD:
2129
2130 9.2.  Attacks Based On Command, Code, or Query Injection
2131
2132NEW:
2133
2134 9.2.  Attacks Based on Command, Code, or Query Injection
2135
2136
2137Section 9.4., paragraph 3:
2138OLD:
2139
2140    Since the Referer header field tells a target site about the context
2141    that resulted in a request, it has the potential to reveal
2142    information about the user's immediate browsing history and any
2143    personal information that might be found in the referring resource's
2144    URI.  Limitations on Referer are described in Section 5.5.2 to
2145    address some of its security considerations.
2146
2147NEW:
2148
2149    Since the Referer header field tells a target site about the context
2150    that resulted in a request, it has the potential to reveal
2151    information about the user's immediate browsing history and any
2152    personal information that might be found in the referring resource's
2153    URI.  Limitations on the Referer header field are described in
2154    Section 5.5.2 to address some of its security considerations.
2155
2156
2157Section 11.1., paragraph 1:
2158OLD:
2159
2160    [RFC2045]     Freed, N. and N. Borenstein, "Multipurpose Internet
2161                  Mail Extensions (MIME) Part One: Format of Internet
2162                  Message Bodies", RFC 2045, November 1996.
2163
2164NEW:
2165
2166    [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
2167               Extensions (MIME) Part One: Format of Internet Message
2168               Bodies", RFC 2045, November 1996.
2169
2170
2171Section 11.1., paragraph 2:
2172OLD:
2173
2174    [RFC2046]     Freed, N. and N. Borenstein, "Multipurpose Internet
2175                  Mail Extensions (MIME) Part Two: Media Types",
2176                  RFC 2046, November 1996.
2177
2178NEW:
2179
2180    [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
2181               Extensions (MIME) Part Two: Media Types", RFC 2046,
2182               November 1996.
2183
2184
2185Section 11.1., paragraph 4:
2186OLD:
2187
2188    [RFC3986]     Berners-Lee, T., Fielding, R., and L. Masinter,
2189                  "Uniform Resource Identifier (URI): Generic Syntax",
2190                  STD 66, RFC 3986, January 2005.
2191
2192NEW:
2193
2194    [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
2195               Resource Identifier (URI): Generic Syntax", STD 66,
2196               RFC 3986, January 2005.
2197
2198
2199Section 11.1., paragraph 5:
2200OLD:
2201
2202    [RFC4647]     Phillips, A., Ed. and M. Davis, Ed., "Matching of
2203                  Language Tags", BCP 47, RFC 4647, September 2006.
2204
2205NEW:
2206
2207    [RFC4647]  Phillips, A., Ed. and M. Davis, Ed., "Matching of Language
2208               Tags", BCP 47, RFC 4647, September 2006.
2209
2210
2211Section 11.1., paragraph 6:
2212OLD:
2213
2214    [RFC5234]     Crocker, D., Ed. and P. Overell, "Augmented BNF for
2215                  Syntax Specifications: ABNF", STD 68, RFC 5234,
2216                  January 2008.
2217
2218NEW:
2219
2220    [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
2221               Specifications: ABNF", STD 68, RFC 5234, January 2008.
2222
2223
2224Section 11.1., paragraph 7:
2225OLD:
2226
2227    [RFC5646]     Phillips, A., Ed. and M. Davis, Ed., "Tags for
2228                  Identifying Languages", BCP 47, RFC 5646,
2229                  September 2009.
2230
2231NEW:
2232
2233    [RFC5646]  Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
2234               Languages", BCP 47, RFC 5646, September 2009.
2235
2236
2237Section 11.1., paragraph 9:
2238OLD:
2239
2240    [RFC7230]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
2241                  Transfer Protocol (HTTP/1.1): Message Syntax and
2242                  Routing", draft-ietf-httpbis-p1-messaging-latest (work
2243                  in progress), May 2014.
2244
2245NEW:
2246
2247    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
2248               Protocol (HTTP/1.1): Message Syntax and Routing",
2249               RFC 7230, May 2014.
2250
2251
2252Section 11.1., paragraph 10:
2253OLD:
2254
2255    [RFC7232]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
2256                  Transfer Protocol (HTTP/1.1): Conditional Requests",
2257                  draft-ietf-httpbis-p4-conditional-latest (work in
2258                  progress), May 2014.
2259
2260NEW:
2261
2262    [RFC7232]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
2263               Protocol (HTTP/1.1): Conditional Requests", RFC 7232,
2264               May 2014.
2265
2266
2267Section 11.1., paragraph 11:
2268OLD:
2269
2270    [RFC7233]     Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
2271                  "Hypertext Transfer Protocol (HTTP/1.1): Range
2272                  Requests", draft-ietf-httpbis-p5-range-latest (work in
2273                  progress), May 2014.
2274
2275NEW:
2276
2277    [RFC7233]     Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
2278               "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
2279               RFC 7233, May 2014.
2280
2281
2282Section 11.1., paragraph 12:
2283OLD:
2284
2285    [RFC7234]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
2286                  Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
2287                  draft-ietf-httpbis-p6-cache-latest (work in progress),
2288                  May 2014.
2289
2290NEW:
2291
2292    [RFC7234]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
2293                  Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
2294               RFC 7234, May 2014.
2295
2296
2297Section 11.1., paragraph 13:
2298OLD:
2299
2300    [RFC7235]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
2301                  Transfer Protocol (HTTP/1.1): Authentication",
2302                  draft-ietf-httpbis-p7-auth-latest (work in progress),
2303                  May 2014.
2304
2305NEW:
2306
2307    [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
2308               Protocol (HTTP/1.1): Authentication", RFC 7235, May 2014.
2309
2310
2311Section 11.2., paragraph 3:
2312OLD:
2313
2314    [BCP90]       Klyne, G., Nottingham, M., and J. Mogul, "Registration
2315                  Procedures for Message Header Fields", BCP 90,
2316                  RFC 3864, September 2004.
2317
2318NEW:
2319
2320    [BCP90]       Klyne, G., Nottingham, M., and J. Mogul, "Registration
2321               Procedures for Message Header Fields", BCP 90, RFC 3864,
2322               September 2004.
2323
2324
2325Section 11.2., paragraph 4:
2326OLD:
2327
2328    [OWASP]       van der Stock, A., Ed., "A Guide to Building Secure Web
2329                  Applications and Web Services", The Open Web
2330                  Application Security Project (OWASP) 2.0.1, July 2005,
2331                  <https://www.owasp.org/>.
2332
2333NEW:
2334
2335    [OWASP]       van der Stock, A., Ed., "A Guide to Building Secure Web
2336               Applications and Web Services", The Open Web Application
2337               Security Project (OWASP) 2.0.1, July 2005,
2338                  <https://www.owasp.org/>.
2339
2340
2341Section 11.2., paragraph 5:
2342OLD:
2343
2344    [REST]        Fielding, R., "Architectural Styles and the Design of
2345                  Network-based Software Architectures",
2346                  Doctoral Dissertation, University of California,
2347                  Irvine, September 2000,
2348                  <http://roy.gbiv.com/pubs/dissertation/top.htm>.
2349
2350NEW:
2351
2352    [REST]        Fielding, R., "Architectural Styles and the Design of
2353                  Network-based Software Architectures",
2354               Doctoral Dissertation, University of California, Irvine,
2355               September 2000,
2356                  <http://roy.gbiv.com/pubs/dissertation/top.htm>.
2357
2358
2359Section 11.2., paragraph 6:
2360OLD:
2361
2362    [RFC1945]     Berners-Lee, T., Fielding, R., and H. Nielsen,
2363                  "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,
2364                  May 1996.
2365
2366NEW:
2367
2368    [RFC1945]  Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
2369               Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
2370
2371
2372Section 11.2., paragraph 7:
2373OLD:
2374
2375    [RFC2049]     Freed, N. and N. Borenstein, "Multipurpose Internet
2376                  Mail Extensions (MIME) Part Five: Conformance Criteria
2377                  and Examples", RFC 2049, November 1996.
2378
2379NEW:
2380
2381    [RFC2049]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
2382               Extensions (MIME) Part Five: Conformance Criteria and
2383               Examples", RFC 2049, November 1996.
2384
2385
2386Section 11.2., paragraph 8:
2387OLD:
2388
2389    [RFC2068]     Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and
2390                  T. Berners-Lee, "Hypertext Transfer Protocol --
2391                  HTTP/1.1", RFC 2068, January 1997.
2392
2393NEW:
2394
2395    [RFC2068]  Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
2396               Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
2397               RFC 2068, January 1997.
2398
2399
2400Section 11.2., paragraph 9:
2401OLD:
2402
2403    [RFC2295]     Holtman, K. and A. Mutz, "Transparent Content
2404                  Negotiation in HTTP", RFC 2295, March 1998.
2405
2406NEW:
2407
2408    [RFC2295]  Holtman, K. and A. Mutz, "Transparent Content Negotiation
2409               in HTTP", RFC 2295, March 1998.
2410
2411
2412Section 11.2., paragraph 11:
2413OLD:
2414
2415    [RFC2557]     Palme, F., Hopmann, A., Shelness, N., and E. Stefferud,
2416                  "MIME Encapsulation of Aggregate Documents, such as
2417                  HTML (MHTML)", RFC 2557, March 1999.
2418
2419NEW:
2420
2421    [RFC2557]     Palme, F., Hopmann, A., Shelness, N., and E. Stefferud,
2422               "MIME Encapsulation of Aggregate Documents, such as HTML
2423               (MHTML)", RFC 2557, March 1999.
2424
2425
2426Section 11.2., paragraph 16:
2427OLD:
2428
2429    [RFC5226]     Narten, T. and H. Alvestrand, "Guidelines for Writing
2430                  an IANA Considerations Section in RFCs", BCP 26,
2431                  RFC 5226, May 2008.
2432
2433NEW:
2434
2435    [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
2436               IANA Considerations Section in RFCs", BCP 26, RFC 5226,
2437               May 2008.
2438
2439
2440Section 11.2., paragraph 17:
2441OLD:
2442
2443    [RFC5246]     Dierks, T. and E. Rescorla, "The Transport Layer
2444                  Security (TLS) Protocol Version 1.2", RFC 5246,
2445                  August 2008.
2446
2447NEW:
2448
2449    [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
2450               (TLS) Protocol Version 1.2", RFC 5246, August 2008.
2451
2452
2453Section 11.2., paragraph 20:
2454OLD:
2455
2456    [RFC5905]     Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
2457                  "Network Time Protocol Version 4: Protocol and
2458                  Algorithms Specification", RFC 5905, June 2010.
2459
2460NEW:
2461
2462    [RFC5905]     Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
2463               "Network Time Protocol Version 4: Protocol and Algorithms
2464               Specification", RFC 5905, June 2010.
2465
2466
2467Section 11.2., paragraph 24:
2468OLD:
2469
2470    [RFC6266]     Reschke, J., "Use of the Content-Disposition Header
2471                  Field in the Hypertext Transfer Protocol (HTTP)",
2472                  RFC 6266, June 2011.
2473
2474NEW:
2475
2476    [RFC6266]  Reschke, J., "Use of the Content-Disposition Header Field
2477               in the Hypertext Transfer Protocol (HTTP)", RFC 6266,
2478               June 2011.
2479
2480
2481Section 11.2., paragraph 25:
2482OLD:
2483
2484    [status-308]  Reschke, J., "The Hypertext Transfer Protocol (HTTP)
2485                  Status Code 308 (Permanent Redirect)",
2486                  draft-reschke-http-status-308-07 (work in progress),
2487                  March 2012.
2488
2489NEW:
2490
2491    [RFC7238]  Reschke, J., "The Hypertext Transfer Protocol (HTTP)
2492               Status Code 308 (Permanent Redirect)", RFC 7238, May 2014.
2493
2494
2495Appendix A., paragraph 1:
2496OLD:
2497
2498    HTTP/1.1 uses many of the constructs defined for the Internet Message
2499    Format [RFC5322] and the Multipurpose Internet Mail Extensions (MIME)
2500    [RFC2045] to allow a message body to be transmitted in an open
2501    variety of representations and with extensible header fields.
2502    However, RFC 2045 is focused only on email; applications of HTTP have
2503    many characteristics that differ from email, and hence HTTP has
2504    features that differ from MIME.  These differences were carefully
2505    chosen to optimize performance over binary connections, to allow
2506    greater freedom in the use of new media types, to make date
2507    comparisons easier, and to acknowledge the practice of some early
2508    HTTP servers and clients.
2509
2510NEW:
2511
2512    HTTP/1.1 uses many of the constructs defined for the Internet Message
2513    Format [RFC5322] and the Multipurpose Internet Mail Extensions (MIME)
2514    [RFC2045] to allow a message body to be transmitted in an open
2515    variety of representations and with extensible header fields.
2516    However, RFC 2045 is focused only on email; applications of HTTP have
2517    many characteristics that differ from email; hence, HTTP has features
2518    that differ from MIME.  These differences were carefully chosen to
2519    optimize performance over binary connections, to allow greater
2520    freedom in the use of new media types, to make date comparisons
2521    easier, and to acknowledge the practice of some early HTTP servers
2522    and clients.
2523
2524
2525Appendix A., paragraph 16:
2526OLD:
2527
2528 A.6.  MHTML and Line Length Limitations
2529
2530NEW:
2531
2532 A.6.  MHTML and Line-Length Limitations
2533
2534
2535Appendix A., paragraph 17:
2536OLD:
2537
2538    HTTP implementations that share code with MHTML [RFC2557]
2539    implementations need to be aware of MIME line length limitations.
2540    Since HTTP does not have this limitation, HTTP does not fold long
2541    lines.  MHTML messages being transported by HTTP follow all
2542    conventions of MHTML, including line length limitations and folding,
2543    canonicalization, etc., since HTTP transfers message-bodies as
2544    payload and, aside from the "multipart/byteranges" type (Appendix A
2545    of [RFC7233]), does not interpret the content or any MIME header
2546    lines that might be contained therein.
2547
2548NEW:
2549
2550    HTTP implementations that share code with MHTML [RFC2557]
2551    implementations need to be aware of MIME line-length limitations.
2552    Since HTTP does not have this limitation, HTTP does not fold long
2553    lines.  MHTML messages being transported by HTTP follow all
2554    conventions of MHTML, including line-length limitations and folding,
2555    canonicalization, etc., since HTTP transfers message-bodies as
2556    payload and, aside from the "multipart/byteranges" type (Appendix A
2557    of [RFC7233]), does not interpret the content or any MIME header
2558    lines that might be contained therein.
2559
2560
2561Appendix B., paragraph 2:
2562OLD:
2563
2564    A new requirement has been added that semantics embedded in a URI
2565    should be disabled when those semantics are inconsistent with the
2566    request method, since this is a common cause of interoperability
2567    failure.  (Section 2)
2568
2569NEW:
2570
2571    A new requirement has been added that semantics embedded in a URI be
2572    disabled when those semantics are inconsistent with the request
2573    method, since this is a common cause of interoperability failure
2574    (Section 2).
2575
2576
2577Appendix B., paragraph 3:
2578OLD:
2579
2580    An algorithm has been added for determining if a payload is
2581    associated with a specific identifier.  (Section 3.1.4.1)
2582
2583NEW:
2584
2585    An algorithm has been added for determining if a payload is
2586    associated with a specific identifier (Section 3.1.4.1).
2587
2588
2589Appendix B., paragraph 4:
2590OLD:
2591
2592    The default charset of ISO-8859-1 for text media types has been
2593    removed; the default is now whatever the media type definition says.
2594    Likewise, special treatment of ISO-8859-1 has been removed from the
2595    Accept-Charset header field.  (Section 3.1.1.3 and Section 5.3.3)
2596
2597NEW:
2598
2599    The default charset of ISO-8859-1 for text media types has been
2600    removed; the default is now whatever the media type definition says.
2601    Likewise, special treatment of ISO-8859-1 has been removed from the
2602    Accept-Charset header field.  (Sections 3.1.1.3 and 5.3.3.)
2603
2604
2605Appendix B., paragraph 5:
2606OLD:
2607
2608    The definition of Content-Location has been changed to no longer
2609    affect the base URI for resolving relative URI references, due to
2610    poor implementation support and the undesirable effect of potentially
2611    breaking relative links in content-negotiated resources.
2612    (Section 3.1.4.2)
2613
2614NEW:
2615
2616    The definition of Content-Location has been changed to no longer
2617    affect the base URI for resolving relative URI references, due to
2618    poor implementation support and the undesirable effect of potentially
2619    breaking relative links in content-negotiated resources
2620    (Section 3.1.4.2).
2621
2622
2623Appendix B., paragraph 6:
2624OLD:
2625
2626    To be consistent with the method-neutral parsing algorithm of
2627    [RFC7230], the definition of GET has been relaxed so that requests
2628    can have a body, even though a body has no meaning for GET.
2629    (Section 4.3.1)
2630
2631NEW:
2632
2633    To be consistent with the method-neutral parsing algorithm of
2634    [RFC7230], the definition of GET has been relaxed so that requests
2635    can have a body, even though a body has no meaning for GET
2636    (Section 4.3.1).
2637
2638
2639Appendix B., paragraph 7:
2640OLD:
2641
2642    Servers are no longer required to handle all Content-* header fields
2643    and use of Content-Range has been explicitly banned in PUT requests.
2644    (Section 4.3.4)
2645
2646NEW:
2647
2648    Servers are no longer required to handle all Content-* header fields
2649    and use of Content-Range has been explicitly banned in PUT requests
2650    (Section 4.3.4).
2651
2652
2653Appendix B., paragraph 8:
2654OLD:
2655
2656    Definition of the CONNECT method has been moved from [RFC2817] to
2657    this specification.  (Section 4.3.6)
2658
2659NEW:
2660
2661    Definition of the CONNECT method has been moved from [RFC2817] to
2662    this specification (Section 4.3.6).
2663
2664
2665Appendix B., paragraph 9:
2666OLD:
2667
2668    The OPTIONS and TRACE request methods have been defined as being
2669    safe.  (Section 4.3.7 and Section 4.3.8)
2670
2671NEW:
2672
2673    The OPTIONS and TRACE request methods have been defined as being safe
2674    (Section 4.3.7 and Section 4.3.8).
2675
2676
2677Appendix B., paragraph 10:
2678OLD:
2679
2680    The Expect header field's extension mechanism has been removed due to
2681    widely-deployed broken implementations.  (Section 5.1.1)
2682
2683NEW:
2684
2685    The Expect header field's extension mechanism has been removed due to
2686    widely deployed broken implementations (Section 5.1.1).
2687
2688
2689Appendix B., paragraph 11:
2690OLD:
2691
2692    The Max-Forwards header field has been restricted to the OPTIONS and
2693    TRACE methods; previously, extension methods could have used it as
2694    well.  (Section 5.1.2)
2695
2696NEW:
2697
2698    The Max-Forwards header field has been restricted to the OPTIONS and
2699    TRACE methods; previously, extension methods could have used it as
2700    well (Section 5.1.2).
2701
2702
2703Appendix B., paragraph 12:
2704OLD:
2705
2706    The "about:blank" URI has been suggested as a value for the Referer
2707    header field when no referring URI is applicable, which distinguishes
2708    that case from others where the Referer field is not sent or has been
2709    removed.  (Section 5.5.2)
2710
2711NEW:
2712
2713    The "about:blank" URI has been suggested as a value for the Referer
2714    header field when no referring URI is applicable, which distinguishes
2715    that case from others where the Referer field is not sent or has been
2716    removed (Section 5.5.2).
2717
2718
2719Appendix B., paragraph 13:
2720OLD:
2721
2722    The following status codes are now cacheable (that is, they can be
2723    stored and reused by a cache without explicit freshness information
2724    present): 204, 404, 405, 414, 501.  (Section 6)
2725
2726NEW:
2727
2728    The following status codes are now cacheable (that is, they can be
2729    stored and reused by a cache without explicit freshness information
2730    present): 204, 404, 405, 414, 501 (Section 6).
2731
2732
2733Appendix B., paragraph 14:
2734OLD:
2735
2736    The 201 (Created) status description has been changed to allow for
2737    the possibility that more than one resource has been created.
2738    (Section 6.3.2)
2739
2740NEW:
2741
2742    The 201 (Created) status description has been changed to allow for
2743    the possibility that more than one resource has been created
2744    (Section 6.3.2).
2745
2746
2747Appendix B., paragraph 15:
2748OLD:
2749
2750    The definition of 203 (Non-Authoritative Information) has been
2751    broadened to include cases of payload transformations as well.
2752    (Section 6.3.4)
2753
2754NEW:
2755
2756    The definition of 203 (Non-Authoritative Information) has been
2757    broadened to include cases of payload transformations as well
2758    (Section 6.3.4).
2759
2760
2761Appendix B., paragraph 16:
2762OLD:
2763
2764    The set of request methods that are safe to automatically redirect is
2765    no longer closed; user agents are able to make that determination
2766    based upon the request method semantics.  The redirect status codes
2767    301, 302, and 307 no longer have normative requirements on response
2768    payloads and user interaction.  (Section 6.4)
2769
2770NEW:
2771
2772    The set of request methods that are safe to automatically redirect is
2773    no longer closed; user agents are able to make that determination
2774    based upon the request method semantics.  The redirect status codes
2775    301, 302, and 307 no longer have normative requirements on response
2776    payloads and user interaction (Section 6.4).
2777
2778
2779Appendix B., paragraph 17:
2780OLD:
2781
2782    The status codes 301 and 302 have been changed to allow user agents
2783    to rewrite the method from POST to GET.  (Sections 6.4.2 and 6.4.3)
2784
2785NEW:
2786
2787    The status codes 301 and 302 have been changed to allow user agents
2788    to rewrite the method from POST to GET.  (Sections 6.4.2 and 6.4.3.)
2789
2790
2791Appendix B., paragraph 18:
2792OLD:
2793
2794    The description of 303 (See Other) status code has been changed to
2795    allow it to be cached if explicit freshness information is given, and
2796    a specific definition has been added for a 303 response to GET.
2797    (Section 6.4.4)
2798
2799NEW:
2800
2801    The description of the 303 (See Other) status code has been changed
2802    to allow it to be cached if explicit freshness information is given,
2803    and a specific definition has been added for a 303 response to GET
2804    (Section 6.4.4).
2805
2806
2807Appendix B., paragraph 19:
2808OLD:
2809
2810    The 305 (Use Proxy) status code has been deprecated due to security
2811    concerns regarding in-band configuration of a proxy.  (Section 6.4.5)
2812
2813NEW:
2814
2815    The 305 (Use Proxy) status code has been deprecated due to security
2816    concerns regarding in-band configuration of a proxy (Section 6.4.5).
2817
2818
2819Appendix B., paragraph 20:
2820OLD:
2821
2822    The 400 (Bad Request) status code has been relaxed so that it isn't
2823    limited to syntax errors.  (Section 6.5.1)
2824
2825NEW:
2826
2827    The 400 (Bad Request) status code has been relaxed so that it isn't
2828    limited to syntax errors (Section 6.5.1).
2829
2830
2831Appendix B., paragraph 21:
2832OLD:
2833
2834    The 426 (Upgrade Required) status code has been incorporated from
2835    [RFC2817].  (Section 6.5.15)
2836
2837NEW:
2838
2839    The 426 (Upgrade Required) status code has been incorporated from
2840    [RFC2817] (Section 6.5.15).
2841
2842
2843Appendix B., paragraph 22:
2844OLD:
2845
2846    The target of requirements on HTTP-date and the Date header field
2847    have been reduced to those systems generating the date, rather than
2848    all systems sending a date.  (Section 7.1.1)
2849
2850NEW:
2851
2852    The target of requirements on HTTP-date and the Date header field
2853    have been reduced to those systems generating the date, rather than
2854    all systems sending a date (Section 7.1.1).
2855
2856
2857Appendix B., paragraph 23:
2858OLD:
2859
2860    The syntax of the Location header field has been changed to allow all
2861    URI references, including relative references and fragments, along
2862    with some clarifications as to when use of fragments would not be
2863    appropriate.  (Section 7.1.2)
2864
2865NEW:
2866
2867    The syntax of the Location header field has been changed to allow all
2868    URI references, including relative references and fragments, along
2869    with some clarifications as to when use of fragments would not be
2870    appropriate (Section 7.1.2).
2871
2872
2873Appendix B., paragraph 24:
2874OLD:
2875
2876    Allow has been reclassified as a response header field, removing the
2877    option to specify it in a PUT request.  Requirements relating to the
2878    content of Allow have been relaxed; correspondingly, clients are not
2879    required to always trust its value.  (Section 7.4.1)
2880
2881NEW:
2882
2883    Allow has been reclassified as a response header field, removing the
2884    option to specify it in a PUT request.  Requirements relating to the
2885    content of Allow have been relaxed; correspondingly, clients are not
2886    required to always trust its value (Section 7.4.1).
2887 
2888    A Method Registry has been defined (Section 8.1).
2889
2890
2891Appendix B., paragraph 25:
2892OLD:
2893
2894    A Method Registry has been defined.  (Section 8.1)
2895    The Status Code Registry has been redefined by this specification;
2896    previously, it was defined in Section 7.1 of [RFC2817].
2897    (Section 8.2)
2898
2899NEW:
2900
2901    The Status Code Registry has been redefined by this specification;
2902    previously, it was defined in Section 7.1 of [RFC2817] (Section 8.2).
2903
2904
2905Appendix B., paragraph 26:
2906OLD:
2907
2908    Registration of Content Codings has been changed to require IETF
2909    Review.  (Section 8.4)
2910
2911NEW:
2912
2913    Registration of content codings has been changed to require IETF
2914    Review (Section 8.4).
2915
2916
2917Section 1.2, paragraph 1:
2918OLD:
2919
2920    Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
2921     OWS ( media-range [ accept-params ] ) ] ) ]
2922    Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS
2923     "," [ OWS ( ( charset / "*" ) [ weight ] ) ] )
2924    Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS
2925     ( codings [ weight ] ) ] ) ]
2926    Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS
2927     "," [ OWS ( language-range [ weight ] ) ] )
2928 
2929    Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ]
2930
2931NEW:
2932
2933    Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
2934     OWS ( media-range [ accept-params ] ) ] ) ]
2935    Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS
2936     "," [ OWS ( ( charset / "*" ) [ weight ] ) ] )
2937    Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS
2938     ( codings [ weight ] ) ] ) ]
2939    Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS
2940     "," [ OWS ( language-range [ weight ] ) ] )
2941    Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ]
2942
2943
2944Section 1.2, paragraph 3:
2945OLD:
2946
2947    Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS
2948     content-coding ] )
2949    Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS
2950     language-tag ] )
2951    Content-Location = absolute-URI / partial-URI
2952    Content-Type = media-type
2953 
2954    Date = HTTP-date
2955
2956NEW:
2957
2958    Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS
2959     content-coding ] )
2960    Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS
2961     language-tag ] )
2962    Content-Location = absolute-URI / partial-URI
2963    Content-Type = media-type
2964    Date = HTTP-date
2965
2966
2967Section 1.2, paragraph 24:
2968OLD:
2969
2970    parameter = token "=" ( token / quoted-string )
2971    partial-URI = <partial-URI, defined in [RFC7230], Section 2.7>
2972    product = token [ "/" product-version ]
2973    product-version = token
2974 
2975    quoted-string = <quoted-string, defined in [RFC7230], Section 3.2.6>
2976    qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
2977
2978NEW:
2979
2980    parameter = token "=" ( token / quoted-string )
2981    partial-URI = <partial-URI, defined in [RFC7230], Section 2.7>
2982    product = token [ "/" product-version ]
2983    product-version = token
2984    quoted-string = <quoted-string, defined in [RFC7230], Section 3.2.6>
2985    qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
2986
2987
2988Section 1.2, paragraph 30:
2989OLD:
2990
2991 Appendix E.  Change Log (to be removed by RFC Editor before publication)
2992 
2993 E.1.  Since RFC 2616
2994 
2995    Changes up to the IETF Last Call draft are summarized in <http://
2996    trac.tools.ietf.org/html/
2997    draft-ietf-httpbis-p2-semantics-24#appendix-E>.
2998 
2999 E.2.  Since draft-ietf-httpbis-p2-semantics-24
3000 
3001    Closed issues:
3002 
3003    o  <http://tools.ietf.org/wg/httpbis/trac/ticket/432>: "Review
3004       Cachability of Status Codes WRT 'Negative Caching'"
3005 
3006    o  <http://tools.ietf.org/wg/httpbis/trac/ticket/499>: "RFC 1305 ref
3007       needs to be updated to 5905"
3008 
3009    o  <http://tools.ietf.org/wg/httpbis/trac/ticket/501>: "idempotency:
3010       clarify 'effect'"
3011 
3012    o  <http://tools.ietf.org/wg/httpbis/trac/ticket/503>: "APPSDIR
3013       review of draft-ietf-httpbis-p2-semantics-24"
3014 
3015    o  <http://tools.ietf.org/wg/httpbis/trac/ticket/517>: "move IANA
3016       registrations to correct draft"
3017 
3018 E.3.  Since draft-ietf-httpbis-p2-semantics-25
3019 
3020    Closed issues:
3021 
3022    o  <http://tools.ietf.org/wg/httpbis/trac/ticket/520>: "Gen-Art
3023       review of draft-ietf-httpbis-p2-semantics-24 with security
3024       considerations"
3025 
3026    o  <http://tools.ietf.org/wg/httpbis/trac/ticket/532>: "IESG ballot
3027       on draft-ietf-httpbis-p2-semantics-25"
3028 
3029    o  <http://tools.ietf.org/wg/httpbis/trac/ticket/538>: "add
3030       'stateless' to Abstract"
3031 
3032    o  <http://tools.ietf.org/wg/httpbis/trac/ticket/542>: "improve
3033       introduction of list rule"
3034 
3035    o  <http://tools.ietf.org/wg/httpbis/trac/ticket/545>: "requirement
3036       on implementing methods according to their semantics"
3037 
3038    o  <http://tools.ietf.org/wg/httpbis/trac/ticket/546>:
3039       "considerations for new headers: privacy"
3040 
3041    o  <http://tools.ietf.org/wg/httpbis/trac/ticket/549>: "augment
3042       security considerations with pointers to current research"
3043 
3044 E.4.  Since draft-ietf-httpbis-p2-semantics-26
3045 
3046    None yet.
3047 
3048 Index
3049
3050NEW:
3051
3052 Index
3053
3054
3055Section 1.2, paragraph 50:
3056OLD:
3057
3058    M
3059       Max-Forwards header field  36
3060       MIME-Version header field  89
3061
3062NEW:
3063
3064    M
3065       Max-Forwards header field  36
3066       MIME-Version header field  88
3067
Note: See TracBrowser for help on using the repository browser.