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

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

prune change logs, add AUTH48 statement to "Editorial Note" (#553)

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