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

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

punctuation (#553)

File size: 104.4 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 . . . . . . . . . . . . . . 89
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.2., paragraph 5:
580OLD:
581
582    If no Content-Language is specified, the default is that the content
583    is intended for all language audiences.  This might mean that the
584    sender does not consider it to be specific to any natural language,
585    or that the sender does not know for which language it is intended.
586
587NEW:
588
589    If no Content-Language is specified, the default is that the content
590    is intended for all language audiences.  This might mean that the
591    sender does not consider it to be specific to any natural language,
592    or that the sender does not know which language is being used.
593
594
595Section 406, paragraph 1:
596OLD:
597
598    Reactive negotiation is advantageous when the response would vary
599    over commonly-used dimensions (such as type, language, or encoding),
600    when the origin server is unable to determine a user agent's
601    capabilities from examining the request, and generally when public
602    caches are used to distribute server load and reduce network usage.
603
604NEW:
605
606    Reactive negotiation is advantageous when the response would vary
607    over commonly used dimensions (such as type, language, or encoding),
608    when the origin server is unable to determine a user agent's
609    capabilities from examining the request, and generally when public
610    caches are used to distribute server load and reduce network usage.
611
612
613Section 4.1., paragraph 4:
614OLD:
615
616    HTTP was originally designed to be usable as an interface to
617    distributed object systems.  The request method was envisioned as
618    applying semantics to a target resource in much the same way as
619    invoking a defined method on an identified object would apply
620    semantics.  The method token is case-sensitive because it might be
621    used as a gateway to object-based systems with case-sensitive method
622    names.
623
624NEW:
625
626    HTTP was originally designed to be usable as an interface to
627    distributed object systems.  The request method was envisioned as
628    applying semantics to a target resource in much the same way as
629    invoking a defined method on an identified object would apply
630    semantics.  The method token is case sensitive because it might be
631    used as a gateway to object-based systems with case-sensitive method
632    names.
633
634
635Section 4.1., paragraph 5:
636OLD:
637
638    Unlike distributed objects, the standardized request methods in HTTP
639    are not resource-specific, since uniform interfaces provide for
640    better visibility and reuse in network-based systems [REST].  Once
641    defined, a standardized method ought to have the same semantics when
642    applied to any resource, though each resource determines for itself
643    whether those semantics are implemented or allowed.
644
645NEW:
646
647    Unlike distributed objects, the standardized request methods in HTTP
648    are not resource specific, since uniform interfaces provide for
649    better visibility and reuse in network-based systems [REST].  Once
650    defined, a standardized method ought to have the same semantics when
651    applied to any resource, though each resource determines for itself
652    whether those semantics are implemented or allowed.
653
654
655Section 4.1., paragraph 9:
656OLD:
657
658    Additional methods, outside the scope of this specification, have
659    been standardized for use in HTTP.  All such methods ought to be
660    registered within the HTTP Method Registry maintained by IANA, as
661    defined in Section 8.1.
662
663NEW:
664
665    Additional methods, outside the scope of this specification, have
666    been standardized for use in HTTP.  All such methods ought to be
667    registered within the "Hypertext Transfer Protocol (HTTP) Method"
668    registry maintained by IANA, as defined in Section 8.1.
669
670
671Section 4.2.1., paragraph 2:
672OLD:
673
674    This definition of safe methods does not prevent an implementation
675    from including behavior that is potentially harmful, not entirely
676    read-only, or which causes side-effects while invoking a safe method.
677    What is important, however, is that the client did not request that
678    additional behavior and cannot be held accountable for it.  For
679    example, most servers append request information to access log files
680    at the completion of every response, regardless of the method, and
681    that is considered safe even though the log storage might become full
682    and crash the server.  Likewise, a safe request initiated by
683    selecting an advertisement on the Web will often have the side-effect
684    of charging an advertising account.
685
686NEW:
687
688    This definition of safe method does not prevent an implementation
689    from including behavior that is potentially harmful, that is not
690    entirely read-only, or that causes side effects while invoking a safe
691    method.  What is important, however, is that the client did not
692    request that additional behavior and cannot be held accountable for
693    it.  For example, most servers append request information to access
694    log files at the completion of every response, regardless of the
695    method, and that is considered safe even though the log storage might
696    become full and crash the server.  Likewise, a safe request initiated
697    by selecting an advertisement on the Web will often have the side
698    effect of charging an advertising account.
699
700
701Section 4.2.1., paragraph 6:
702OLD:
703
704    When a resource is constructed such that parameters within the
705    effective request URI have the effect of selecting an action, it is
706    the resource owner's responsibility to ensure that the action is
707    consistent with the request method semantics.  For example, it is
708    common for Web-based content editing software to use actions within
709    query parameters, such as "page?do=delete".  If the purpose of such a
710    resource is to perform an unsafe action, then the resource owner MUST
711    disable or disallow that action when it is accessed using a safe
712    request method.  Failure to do so will result in unfortunate side-
713    effects when automated processes perform a GET on every URI reference
714    for the sake of link maintenance, pre-fetching, building a search
715    index, etc.
716
717NEW:
718
719    When a resource is constructed such that parameters within the
720    effective request URI have the effect of selecting an action, it is
721    the resource owner's responsibility to ensure that the action is
722    consistent with the request method semantics.  For example, it is
723    common for Web-based content editing software to use actions within
724    query parameters, such as "page?do=delete".  If the purpose of such a
725    resource is to perform an unsafe action, then the resource owner MUST
726    disable or disallow that action when it is accessed using a safe
727    request method.  Failure to do so will result in unfortunate side
728    effects when automated processes perform a GET on every URI reference
729    for the sake of link maintenance, pre-fetching, building a search
730    index, etc.
731
732
733Section 4.2.2., paragraph 2:
734OLD:
735
736    Like the definition of safe, the idempotent property only applies to
737    what has been requested by the user; a server is free to log each
738    request separately, retain a revision control history, or implement
739    other non-idempotent side-effects for each idempotent request.
740
741NEW:
742
743    Like the definition of safe, the idempotent property only applies to
744    what has been requested by the user; a server is free to log each
745    request separately, retain a revision control history, or implement
746    other non-idempotent side effects for each idempotent request.
747
748
749Section 4.3.3., paragraph 6:
750OLD:
751
752    An origin server indicates response semantics by choosing an
753    appropriate status code depending on the result of processing the
754    POST request; almost all of the status codes defined by this
755    specification might be received in a response to POST (the exceptions
756    being 206, 304, and 416).
757
758NEW:
759
760    An origin server indicates response semantics by choosing an
761    appropriate status code depending on the result of processing the
762    POST request; almost all of the status codes defined by this
763    specification might be received in a response to POST (the exceptions
764    being 206 (Partial Content), 304 (Not Modified), and 416 (Range Not
765    Satisfiable)).
766
767
768Section 4.3.4., paragraph 10:
769OLD:
770
771    An origin server MUST NOT send a validator header field
772    (Section 7.2), such as an ETag or Last-Modified field, in a
773    successful response to PUT unless the request's representation data
774    was saved without any transformation applied to the body (i.e., the
775    resource's new representation data is identical to the representation
776    data received in the PUT request) and the validator field value
777    reflects the new representation.  This requirement allows a user
778    agent to know when the representation body it has in memory remains
779    current as a result of the PUT, thus not in need of retrieving again
780    from the origin server, and that the new validator(s) received in the
781    response can be used for future conditional requests in order to
782    prevent accidental overwrites (Section 5.2).
783
784NEW:
785
786    An origin server MUST NOT send a validator header field
787    (Section 7.2), such as an ETag or Last-Modified field, in a
788    successful response to PUT unless the request's representation data
789    was saved without any transformation applied to the body (i.e., the
790    resource's new representation data is identical to the representation
791    data received in the PUT request) and the validator field value
792    reflects the new representation.  This requirement allows a user
793    agent to know when the representation body it has in memory remains
794    current as a result of the PUT, thus not in need of being retrieved
795    again from the origin server, and that the new validator(s) received
796    in the response can be used for future conditional requests in order
797    to prevent accidental overwrites (Section 5.2).
798
799
800Section 4.3.4., paragraph 13:
801OLD:
802
803    A PUT request applied to the target resource can have side-effects on
804    other resources.  For example, an article might have a URI for
805    identifying "the current version" (a resource) that is separate from
806    the URIs identifying each particular version (different resources
807    that at one point shared the same state as the current version
808    resource).  A successful PUT request on "the current version" URI
809    might therefore create a new version resource in addition to changing
810    the state of the target resource, and might also cause links to be
811    added between the related resources.
812
813NEW:
814
815    A PUT request applied to the target resource can have side effects on
816    other resources.  For example, an article might have a URI for
817    identifying "the current version" (a resource) that is separate from
818    the URIs identifying each particular version (different resources
819    that at one point shared the same state as the current version
820    resource).  A successful PUT request on "the current version" URI
821    might therefore create a new version resource in addition to changing
822    the state of the target resource, and might also cause links to be
823    added between the related resources.
824
825
826Section 4.3.6., paragraph 2:
827OLD:
828
829    CONNECT is intended only for use in requests to a proxy.  An origin
830    server that receives a CONNECT request for itself MAY respond with a
831    2xx status code to indicate that a connection is established.
832    However, most origin servers do not implement CONNECT.
833
834NEW:
835
836    CONNECT is intended only for use in requests to a proxy.  An origin
837    server that receives a CONNECT request for itself MAY respond with a
838    2xx (Successful) status code to indicate that a connection is
839    established.  However, most origin servers do not implement CONNECT.
840
841
842Section 4.3.7., paragraph 1:
843OLD:
844
845    The OPTIONS method requests information about the communication
846    options available for the target resource, either at the origin
847    server or an intervening intermediary.  This method allows a client
848    to determine the options and/or requirements associated with a
849    resource, or the capabilities of a server, without implying a
850    resource action.
851
852NEW:
853
854    The OPTIONS method requests information about the communication
855    options available for the target resource, at either the origin
856    server or an intervening intermediary.  This method allows a client
857    to determine the options and/or requirements associated with a
858    resource, or the capabilities of a server, without implying a
859    resource action.
860
861
862Section 4.3.8., paragraph 2:
863OLD:
864
865    A client MUST NOT generate header fields in a TRACE request
866    containing sensitive data that might be disclosed by the response.
867 
868    For example, it would be foolish for a user agent to send stored user
869    credentials [RFC7235] or cookies [RFC6265] in a TRACE request.  The
870    final recipient of the request SHOULD exclude any request header
871    fields that are likely to contain sensitive data when that recipient
872    generates the response body.
873
874NEW:
875
876    A client MUST NOT generate header fields in a TRACE request
877    containing sensitive data that might be disclosed by the response.
878    For example, it would be foolish for a user agent to send stored user
879    credentials [RFC7235] or cookies [RFC6265] in a TRACE request.  The
880    final recipient of the request SHOULD exclude any request header
881    fields that are likely to contain sensitive data when that recipient
882    generates the response body.
883
884
885Section 5.1.1., paragraph 3:
886OLD:
887
888    The Expect field-value is case-insensitive.
889
890NEW:
891
892    The Expect field-value is case insensitive.
893
894
895Section 5.1.1., paragraph 21:
896OLD:
897
898       Note: The Expect header field was added after the original
899       publication of HTTP/1.1 [RFC2068] as both the means to request an
900       interim 100 response and the general mechanism for indicating
901       must-understand extensions.  However, the extension mechanism has
902       not been used by clients and the must-understand requirements have
903       not been implemented by many servers, rendering the extension
904       mechanism useless.  This specification has removed the extension
905       mechanism in order to simplify the definition and processing of
906       100-continue.
907
908NEW:
909
910       Note: The Expect header field was added after the original
911       publication of HTTP/1.1 [RFC2068] as both the means to request an
912       interim 100 (Continue) response and the general mechanism for
913       indicating must-understand extensions.  However, the extension
914       mechanism has not been used by clients and the must-understand
915       requirements have not been implemented by many servers, rendering
916       the extension mechanism useless.  This specification has removed
917       the extension mechanism in order to simplify the definition and
918       processing of 100-continue.
919
920
921Section 5.3.2., paragraph 9:
922OLD:
923
924    is interpreted as "I prefer audio/basic, but send me any audio type
925    if it is the best available after an 80% mark-down in quality".
926
927NEW:
928
929    is interpreted as "I prefer audio/basic, but send me any audio type
930    if it is the best available after an 80% markdown in quality".
931
932
933Section 5.5.1., paragraph 1:
934OLD:
935
936    The "From" header field contains an Internet email address for a
937    human user who controls the requesting user agent.  The address ought
938    to be machine-usable, as defined by "mailbox" in Section 3.4 of
939    [RFC5322]:
940
941NEW:
942
943    The "From" header field contains an Internet email address for a
944    human user who controls the requesting user agent.  The address ought
945    to be machine usable, as defined by "mailbox" in Section 3.4 of
946    [RFC5322]:
947
948
949Section 5.5.2., paragraph 6:
950OLD:
951
952    If the target URI was obtained from a source that does not have its
953    own URI (e.g., input from the user keyboard, or an entry within the
954    user's bookmarks/favorites), the user agent MUST either exclude
955    Referer or send it with a value of "about:blank".
956
957NEW:
958
959    If the target URI was obtained from a source that does not have its
960    own URI (e.g., input from the user keyboard, or an entry within the
961    user's bookmarks/favorites), the user agent MUST either exclude the
962    Referer or send it with a value of "about:blank".
963
964
965Section 5.5.2., paragraph 8:
966OLD:
967
968    Some intermediaries have been known to indiscriminately remove
969    Referer header fields from outgoing requests.  This has the
970    unfortunate side-effect of interfering with protection against CSRF
971    attacks, which can be far more harmful to their users.
972    Intermediaries and user agent extensions that wish to limit
973    information disclosure in Referer ought to restrict their changes to
974    specific edits, such as replacing internal domain names with
975    pseudonyms or truncating the query and/or path components.  An
976    intermediary SHOULD NOT modify or delete the Referer header field
977    when the field value shares the same scheme and host as the request
978    target.
979
980NEW:
981
982    Some intermediaries have been known to indiscriminately remove
983    Referer header fields from outgoing requests.  This has the
984    unfortunate side effect of interfering with protection against CSRF
985    attacks, which can be far more harmful to their users.
986    Intermediaries and user agent extensions that wish to limit
987    information disclosure in Referer ought to restrict their changes to
988    specific edits, such as replacing internal domain names with
989    pseudonyms or truncating the query and/or path components.  An
990    intermediary SHOULD NOT modify or delete the Referer header field
991    when the field value shares the same scheme and host as the request
992    target.
993
994
995Section 5.5.3., paragraph 1:
996OLD:
997
998    The "User-Agent" header field contains information about the user
999    agent originating the request, which is often used by servers to help
1000    identify the scope of reported interoperability problems, to work
1001    around or tailor responses to avoid particular user agent
1002    limitations, and for analytics regarding browser or operating system
1003    use.  A user agent SHOULD send a User-Agent field in each request
1004    unless specifically configured not to do so.
1005
1006NEW:
1007
1008    The "User-Agent" header field contains information about the user
1009    agent originating the request, which is often used by servers to help
1010    identify the scope of reported interoperability problems, to work
1011    around or tailor responses to avoid particular user-agent
1012    limitations, and for analytics regarding browser or operating system
1013    use.  A user agent SHOULD send a User-Agent field in each request
1014    unless specifically configured not to do so.
1015
1016
1017Section 5.5.3., paragraph 3:
1018OLD:
1019
1020    The User-Agent field-value consists of one or more product
1021    identifiers, each followed by zero or more comments (Section 3.2 of
1022    [RFC7230]), which together identify the user agent software and its
1023    significant subproducts.  By convention, the product identifiers are
1024    listed in decreasing order of their significance for identifying the
1025    user agent software.  Each product identifier consists of a name and
1026    optional version.
1027
1028NEW:
1029
1030    The User-Agent field-value consists of one or more product
1031    identifiers, each followed by zero or more comments (Section 3.2 of
1032    [RFC7230]), which together identify the user-agent software and its
1033    significant subproducts.  By convention, the product identifiers are
1034    listed in decreasing order of their significance for identifying the
1035    user-agent software.  Each product identifier consists of a name and
1036    optional version.
1037
1038
1039Section 5.5.3., paragraph 5:
1040OLD:
1041
1042    A sender SHOULD limit generated product identifiers to what is
1043    necessary to identify the product; a sender MUST NOT generate
1044    advertising or other non-essential information within the product
1045    identifier.  A sender SHOULD NOT generate information in product-
1046    version that is not a version identifier (i.e., successive versions
1047    of the same product name ought to only differ in the product-version
1048    portion of the product identifier).
1049
1050NEW:
1051
1052    A sender SHOULD limit generated product identifiers to what is
1053    necessary to identify the product; a sender MUST NOT generate
1054    advertising or other nonessential information within the product
1055    identifier.  A sender SHOULD NOT generate information in product-
1056    version that is not a version identifier (i.e., successive versions
1057    of the same product name ought only to differ in the product-version
1058    portion of the product identifier).
1059
1060
1061Section 5.5.3., paragraph 9:
1062OLD:
1063
1064    Likewise, implementations are encouraged not to use the product
1065    tokens of other implementations in order to declare compatibility
1066    with them, as this circumvents the purpose of the field.  If a user
1067    agent masquerades as a different user agent, recipients can assume
1068    that the user intentionally desires to see responses tailored for
1069    that identified user agent, even if they might not work as well for
1070    the actual user agent being used.
1071
1072NEW:
1073
1074    Likewise, implementations are encouraged not to use the product
1075    tokens of other implementations in order to declare compatibility
1076    with them, as this circumvents the purpose of the field.  If a user
1077    agent masquerades as a different user agent, recipients can assume
1078    that the user intentionally desires to see responses tailored for
1079    that identified user agent, even if they might not work as well for
1080    the actual user agent being implemented.
1081
1082
1083Section 6., paragraph 1:
1084OLD:
1085
1086    The status-code element is a 3-digit integer code giving the result
1087    of the attempt to understand and satisfy the request.
1088
1089NEW:
1090
1091    The status-code element is a three-digit integer code giving the
1092    result of the attempt to understand and satisfy the request.
1093
1094
1095Section 6., paragraph 3:
1096OLD:
1097
1098    For example, if an unrecognized status code of 471 is received by a
1099    client, the client can assume that there was something wrong with its
1100    request and treat the response as if it had received a 400 status
1101    code.  The response message will usually contain a representation
1102    that explains the status.
1103
1104NEW:
1105
1106    For example, if an unrecognized status code of 471 is received by a
1107    client, the client can assume that there was something wrong with its
1108    request and treat the response as if it had received a 400 (Bad
1109    Request) status code.  The response message will usually contain a
1110    representation that explains the status.
1111
1112
1113Section 6., paragraph 4:
1114OLD:
1115
1116    The first digit of the status-code defines the class of response.
1117    The last two digits do not have any categorization role.  There are 5
1118    values for the first digit:
1119
1120NEW:
1121
1122    The first digit of the status-code defines the class of response.
1123    The last two digits do not have any categorization role.  There are
1124    five values for the first digit:
1125
1126
1127Section 6.1., paragraph 2:
1128OLD:
1129
1130    Responses with status codes that are defined as cacheable by default
1131    (e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501 in this
1132    specification) can be reused by a cache with heuristic expiration
1133    unless otherwise indicated by the method definition or explicit cache
1134    controls [RFC7234]; all other status codes are not cacheable by
1135    default.
1136
1137NEW:
1138
1139    Responses with status codes that are defined as cacheable by default
1140    (e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501 in
1141    this specification) can be reused by a cache with heuristic
1142    expiration unless otherwise indicated by the method definition or
1143    explicit cache controls [RFC7234]; all other status codes are not
1144    cacheable by default.
1145
1146
1147Section 6.1., paragraph 3:
1148OLD:
1149
1150    +------+-------------------------------+--------------------------+
1151    | code | reason-phrase                 | Defined in...            |
1152    +------+-------------------------------+--------------------------+
1153    | 100  | Continue                      | Section 6.2.1            |
1154    | 101  | Switching Protocols           | Section 6.2.2            |
1155    | 200  | OK                            | Section 6.3.1            |
1156    | 201  | Created                       | Section 6.3.2            |
1157    | 202  | Accepted                      | Section 6.3.3            |
1158    | 203  | Non-Authoritative Information | Section 6.3.4            |
1159    | 204  | No Content                    | Section 6.3.5            |
1160    | 205  | Reset Content                 | Section 6.3.6            |
1161    | 206  | Partial Content               | Section 4.1 of [RFC7233] |
1162    | 300  | Multiple Choices              | Section 6.4.1            |
1163    | 301  | Moved Permanently             | Section 6.4.2            |
1164    | 302  | Found                         | Section 6.4.3            |
1165    | 303  | See Other                     | Section 6.4.4            |
1166    | 304  | Not Modified                  | Section 4.1 of [RFC7232] |
1167    | 305  | Use Proxy                     | Section 6.4.5            |
1168    | 307  | Temporary Redirect            | Section 6.4.7            |
1169    | 400  | Bad Request                   | Section 6.5.1            |
1170    | 401  | Unauthorized                  | Section 3.1 of [RFC7235] |
1171    | 402  | Payment Required              | Section 6.5.2            |
1172    | 403  | Forbidden                     | Section 6.5.3            |
1173    | 404  | Not Found                     | Section 6.5.4            |
1174    | 405  | Method Not Allowed            | Section 6.5.5            |
1175    | 406  | Not Acceptable                | Section 6.5.6            |
1176    | 407  | Proxy Authentication Required | Section 3.2 of [RFC7235] |
1177    | 408  | Request Time-out              | Section 6.5.7            |
1178    | 409  | Conflict                      | Section 6.5.8            |
1179    | 410  | Gone                          | Section 6.5.9            |
1180    | 411  | Length Required               | Section 6.5.10           |
1181    | 412  | Precondition Failed           | Section 4.2 of [RFC7232] |
1182    | 413  | Payload Too Large             | Section 6.5.11           |
1183    | 414  | URI Too Long                  | Section 6.5.12           |
1184    | 415  | Unsupported Media Type        | Section 6.5.13           |
1185    | 416  | Range Not Satisfiable         | Section 4.4 of [RFC7233] |
1186    | 417  | Expectation Failed            | Section 6.5.14           |
1187    | 426  | Upgrade Required              | Section 6.5.15           |
1188    | 500  | Internal Server Error         | Section 6.6.1            |
1189    | 501  | Not Implemented               | Section 6.6.2            |
1190    | 502  | Bad Gateway                   | Section 6.6.3            |
1191    | 503  | Service Unavailable           | Section 6.6.4            |
1192    | 504  | Gateway Time-out              | Section 6.6.5            |
1193    | 505  | HTTP Version Not Supported    | Section 6.6.6            |
1194    +------+-------------------------------+--------------------------+
1195
1196NEW:
1197
1198    +------+-------------------------------+--------------------------+
1199    | Code | Reason-Phrase                 | Defined in...            |
1200    +------+-------------------------------+--------------------------+
1201    | 100  | Continue                      | Section 6.2.1            |
1202    | 101  | Switching Protocols           | Section 6.2.2            |
1203    | 200  | OK                            | Section 6.3.1            |
1204    | 201  | Created                       | Section 6.3.2            |
1205    | 202  | Accepted                      | Section 6.3.3            |
1206    | 203  | Non-Authoritative Information | Section 6.3.4            |
1207    | 204  | No Content                    | Section 6.3.5            |
1208    | 205  | Reset Content                 | Section 6.3.6            |
1209    | 206  | Partial Content               | Section 4.1 of [RFC7233] |
1210    | 300  | Multiple Choices              | Section 6.4.1            |
1211    | 301  | Moved Permanently             | Section 6.4.2            |
1212    | 302  | Found                         | Section 6.4.3            |
1213    | 303  | See Other                     | Section 6.4.4            |
1214    | 304  | Not Modified                  | Section 4.1 of [RFC7232] |
1215    | 305  | Use Proxy                     | Section 6.4.5            |
1216    | 307  | Temporary Redirect            | Section 6.4.7            |
1217    | 400  | Bad Request                   | Section 6.5.1            |
1218    | 401  | Unauthorized                  | Section 3.1 of [RFC7235] |
1219    | 402  | Payment Required              | Section 6.5.2            |
1220    | 403  | Forbidden                     | Section 6.5.3            |
1221    | 404  | Not Found                     | Section 6.5.4            |
1222    | 405  | Method Not Allowed            | Section 6.5.5            |
1223    | 406  | Not Acceptable                | Section 6.5.6            |
1224    | 407  | Proxy Authentication Required | Section 3.2 of [RFC7235] |
1225    | 408  | Request Time-out              | Section 6.5.7            |
1226    | 409  | Conflict                      | Section 6.5.8            |
1227    | 410  | Gone                          | Section 6.5.9            |
1228    | 411  | Length Required               | Section 6.5.10           |
1229    | 412  | Precondition Failed           | Section 4.2 of [RFC7232] |
1230    | 413  | Payload Too Large             | Section 6.5.11           |
1231    | 414  | URI Too Long                  | Section 6.5.12           |
1232    | 415  | Unsupported Media Type        | Section 6.5.13           |
1233    | 416  | Range Not Satisfiable         | Section 4.4 of [RFC7233] |
1234    | 417  | Expectation Failed            | Section 6.5.14           |
1235    | 426  | Upgrade Required              | Section 6.5.15           |
1236    | 500  | Internal Server Error         | Section 6.6.1            |
1237    | 501  | Not Implemented               | Section 6.6.2            |
1238    | 502  | Bad Gateway                   | Section 6.6.3            |
1239    | 503  | Service Unavailable           | Section 6.6.4            |
1240    | 504  | Gateway Time-out              | Section 6.6.5            |
1241    | 505  | HTTP Version Not Supported    | Section 6.6.6            |
1242    +------+-------------------------------+--------------------------+
1243
1244
1245Section 6.3.3., paragraph 2:
1246OLD:
1247
1248    The 202 response is intentionally non-committal.  Its purpose is to
1249    allow a server to accept a request for some other process (perhaps a
1250    batch-oriented process that is only run once per day) without
1251    requiring that the user agent's connection to the server persist
1252    until the process is completed.  The representation sent with this
1253    response ought to describe the request's current status and point to
1254    (or embed) a status monitor that can provide the user with an
1255    estimate of when the request will be fulfilled.
1256
1257NEW:
1258
1259    The 202 response is intentionally noncommittal.  Its purpose is to
1260    allow a server to accept a request for some other process (perhaps a
1261    batch-oriented process that is only run once per day) without
1262    requiring that the user agent's connection to the server persist
1263    until the process is completed.  The representation sent with this
1264    response ought to describe the request's current status and point to
1265    (or embed) a status monitor that can provide the user with an
1266    estimate of when the request will be fulfilled.
1267
1268
1269Section 6.4.1., paragraph 5:
1270OLD:
1271
1272       Note: The original proposal for 300 defined the URI header field
1273       as providing a list of alternative representations, such that it
1274       would be usable for 200, 300, and 406 responses and be transferred
1275       in responses to the HEAD method.  However, lack of deployment and
1276       disagreement over syntax led to both URI and Alternates (a
1277       subsequent proposal) being dropped from this specification.  It is
1278       possible to communicate the list using a set of Link header fields
1279       [RFC5988], each with a relationship of "alternate", though
1280       deployment is a chicken-and-egg problem.
1281
1282NEW:
1283
1284       Note: The original proposal for the 300 response defined the URI
1285       header field as providing a list of alternative representations,
1286       such that it would be usable for 200, 300, and 406 responses and
1287       be transferred in responses to the HEAD method.  However, lack of
1288       deployment and disagreement over syntax led to both URI and
1289       Alternates (a subsequent proposal) being dropped from this
1290       specification.  It is possible to communicate the list using a set
1291       of Link header fields [RFC5988], each with a relationship of
1292       "alternate", though deployment is a chicken-and-egg problem.
1293
1294
1295Section 6.4.2., paragraph 1:
1296OLD:
1297
1298    The 301 (Moved Permanently) status code indicates that the target
1299    resource has been assigned a new permanent URI and any future
1300    references to this resource ought to use one of the enclosed URIs.
1301    Clients with link editing capabilities ought to automatically re-link
1302    references to the effective request URI to one or more of the new
1303    references sent by the server, where possible.
1304
1305NEW:
1306
1307    The 301 (Moved Permanently) status code indicates that the target
1308    resource has been assigned a new permanent URI and any future
1309    references to this resource ought to use one of the enclosed URIs.
1310    Clients with link-editing capabilities ought to automatically re-link
1311    references to the effective request URI to one or more of the new
1312    references sent by the server, where possible.
1313
1314
1315Section 6.4.7., paragraph 3:
1316OLD:
1317
1318       Note: This status code is similar to 302 (Found), except that it
1319       does not allow changing the request method from POST to GET.  This
1320       specification defines no equivalent counterpart for 301 (Moved
1321       Permanently) ([RFC7238], however, defines the status code 308
1322       (Permanent Redirect) for this purpose).
1323
1324NEW:
1325
1326       Note: This status code is similar to 302 (Found), except that it
1327       does not allow changing the request method from POST to GET.  This
1328       specification defines no equivalent counterpart for 301 (Moved
1329       Permanently) ([RFC7238]; however, it defines the status code 308
1330       (Permanent Redirect) for this purpose).
1331
1332
1333Section 6.5.1., paragraph 1:
1334OLD:
1335
1336    The 400 (Bad Request) status code indicates that the server cannot or
1337    will not process the request due to something which is perceived to
1338    be a client error (e.g., malformed request syntax, invalid request
1339    message framing, or deceptive request routing).
1340
1341NEW:
1342
1343    The 400 (Bad Request) status code indicates that the server cannot or
1344    will not process the request due to something that is perceived to be
1345    a client error (e.g., malformed request syntax, invalid request
1346    message framing, or deceptive request routing).
1347
1348
1349Section 7.1.1.1., paragraph 11:
1350OLD:
1351
1352      day-name     = %x4D.6F.6E ; "Mon", case-sensitive
1353                   / %x54.75.65 ; "Tue", case-sensitive
1354                   / %x57.65.64 ; "Wed", case-sensitive
1355                   / %x54.68.75 ; "Thu", case-sensitive
1356                   / %x46.72.69 ; "Fri", case-sensitive
1357                   / %x53.61.74 ; "Sat", case-sensitive
1358                   / %x53.75.6E ; "Sun", case-sensitive
1359
1360NEW:
1361
1362      day-name     = %x4D.6F.6E ; "Mon", case sensitive
1363                   / %x54.75.65 ; "Tue", case sensitive
1364                   / %x57.65.64 ; "Wed", case sensitive
1365                   / %x54.68.75 ; "Thu", case sensitive
1366                   / %x46.72.69 ; "Fri", case sensitive
1367                   / %x53.61.74 ; "Sat", case sensitive
1368                   / %x53.75.6E ; "Sun", case sensitive
1369
1370
1371Section 7.1.1.1., paragraph 13:
1372OLD:
1373
1374      day          = 2DIGIT
1375      month        = %x4A.61.6E ; "Jan", case-sensitive
1376                   / %x46.65.62 ; "Feb", case-sensitive
1377                   / %x4D.61.72 ; "Mar", case-sensitive
1378                   / %x41.70.72 ; "Apr", case-sensitive
1379                   / %x4D.61.79 ; "May", case-sensitive
1380                   / %x4A.75.6E ; "Jun", case-sensitive
1381                   / %x4A.75.6C ; "Jul", case-sensitive
1382                   / %x41.75.67 ; "Aug", case-sensitive
1383                   / %x53.65.70 ; "Sep", case-sensitive
1384                   / %x4F.63.74 ; "Oct", case-sensitive
1385                   / %x4E.6F.76 ; "Nov", case-sensitive
1386                   / %x44.65.63 ; "Dec", case-sensitive
1387      year         = 4DIGIT
1388
1389NEW:
1390
1391      day          = 2DIGIT
1392      month        = %x4A.61.6E ; "Jan", case sensitive
1393                   / %x46.65.62 ; "Feb", case sensitive
1394                   / %x4D.61.72 ; "Mar", case sensitive
1395                   / %x41.70.72 ; "Apr", case sensitive
1396                   / %x4D.61.79 ; "May", case sensitive
1397                   / %x4A.75.6E ; "Jun", case sensitive
1398                   / %x4A.75.6C ; "Jul", case sensitive
1399                   / %x41.75.67 ; "Aug", case sensitive
1400                   / %x53.65.70 ; "Sep", case sensitive
1401                   / %x4F.63.74 ; "Oct", case sensitive
1402                   / %x4E.6F.76 ; "Nov", case sensitive
1403                   / %x44.65.63 ; "Dec", case sensitive
1404      year         = 4DIGIT
1405
1406
1407Section 7.1.1.1., paragraph 14:
1408OLD:
1409
1410      GMT          = %x47.4D.54 ; "GMT", case-sensitive
1411
1412NEW:
1413
1414      GMT          = %x47.4D.54 ; "GMT", case sensitive
1415
1416
1417Section 7.1.1.1., paragraph 19:
1418OLD:
1419
1420      day-name-l   = %x4D.6F.6E.64.61.79    ; "Monday", case-sensitive
1421             / %x54.75.65.73.64.61.79       ; "Tuesday", case-sensitive
1422             / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive
1423             / %x54.68.75.72.73.64.61.79    ; "Thursday", case-sensitive
1424             / %x46.72.69.64.61.79          ; "Friday", case-sensitive
1425             / %x53.61.74.75.72.64.61.79    ; "Saturday", case-sensitive
1426             / %x53.75.6E.64.61.79          ; "Sunday", case-sensitive
1427
1428NEW:
1429
1430      day-name-l   = %x4D.6F.6E.64.61.79    ; "Monday", case sensitive
1431             / %x54.75.65.73.64.61.79       ; "Tuesday", case sensitive
1432             / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case sensitive
1433             / %x54.68.75.72.73.64.61.79    ; "Thursday", case sensitive
1434             / %x46.72.69.64.61.79          ; "Friday", case sensitive
1435             / %x53.61.74.75.72.64.61.79    ; "Saturday", case sensitive
1436             / %x53.75.6E.64.61.79          ; "Sunday", case sensitive
1437
1438
1439Section 7.1.2., paragraph 5:
1440OLD:
1441
1442    If the Location value provided in a 3xx (Redirection) does not have a
1443    fragment component, a user agent MUST process the redirection as if
1444    the value inherits the fragment component of the URI reference used
1445    to generate the request target (i.e., the redirection inherits the
1446    original reference's fragment, if any).
1447
1448NEW:
1449
1450    If the Location value provided in a 3xx (Redirection) response does
1451    not have a fragment component, a user agent MUST process the
1452    redirection as if the value inherits the fragment component of the
1453    URI reference used to generate the request target (i.e., the
1454    redirection inherits the original reference's fragment, if any).
1455
1456
1457Section 7.1.4., paragraph 1:
1458OLD:
1459
1460    The "Vary" header field in a response describes what parts of a
1461    request message, aside from the method, Host header field, and
1462    request target, might influence the origin server's process for
1463    selecting and representing this response.  The value consists of
1464    either a single asterisk ("*") or a list of header field names (case-
1465    insensitive).
1466
1467NEW:
1468
1469    The "Vary" header field in a response describes what parts of a
1470    request message, aside from the method, Host header field, and
1471    request target, might influence the origin server's process for
1472    selecting and representing this response.  The value consists of
1473    either a single asterisk ("*") or a list of header field names (case
1474    insensitive).
1475
1476
1477Section 1., paragraph 1:
1478OLD:
1479
1480    2.  To inform user agent recipients that this response is subject to
1481        content negotiation (Section 5.3) and that a different
1482        representation might be sent in a subsequent request if
1483        additional parameters are provided in the listed header fields
1484        (proactive negotiation).
1485
1486NEW:
1487
1488    2.  To inform user-agent recipients that this response is subject to
1489        content negotiation (Section 5.3) and that a different
1490        representation might be sent in a subsequent request if
1491        additional parameters are provided in the listed header fields
1492        (proactive negotiation).
1493
1494
1495Section 7.2., paragraph 3:
1496OLD:
1497
1498    For example, an ETag header field in a 201 response communicates the
1499    entity-tag of the newly created resource's representation, so that it
1500    can be used in later conditional requests to prevent the "lost
1501    update" problem [RFC7232].
1502
1503NEW:
1504
1505    For example, an ETag header field in a 201 (Created) response
1506    communicates the entity-tag of the newly created resource's
1507    representation, so that it can be used in later conditional requests
1508    to prevent the "lost update" problem [RFC7232].
1509
1510
1511Section 8.1., paragraph 1:
1512OLD:
1513
1514    The HTTP Method Registry defines the name space for the request
1515    method token (Section 4).  The method registry will be created and
1516    maintained at (the suggested URI)
1517    <http://www.iana.org/assignments/http-methods>.
1518
1519NEW:
1520
1521    The "Hypertext Transfer Protocol (HTTP) Method Registry" defines the
1522    namespace for the request method token (Section 4).  The "HTTP Method
1523    Registry" has been created and is now maintained at
1524    <http://www.iana.org/assignments/http-methods>.
1525
1526
1527Section 8.1.2., paragraph 3:
1528OLD:
1529
1530    A new method definition needs to indicate whether it is safe
1531    (Section 4.2.1), idempotent (Section 4.2.2), cacheable
1532    (Section 4.2.3), what semantics are to be associated with the payload
1533    body if any is present in the request, and what refinements the
1534    method makes to header field or status code semantics.  If the new
1535    method is cacheable, its definition ought to describe how, and under
1536    what conditions, a cache can store a response and use it to satisfy a
1537    subsequent request.  The new method ought to describe whether it can
1538    be made conditional (Section 5.2) and, if so, how a server responds
1539    when the condition is false.  Likewise, if the new method might have
1540    some use for partial response semantics ([RFC7233]), it ought to
1541    document this, too.
1542
1543NEW:
1544
1545    A new method definition needs to indicate whether it is safe
1546    (Section 4.2.1), idempotent (Section 4.2.2), or cacheable
1547    (Section 4.2.3).  It needs to indicate what semantics are to be
1548    associated with the payload body if any is present in the request and
1549    what refinements the method makes to header field or status code
1550    semantics.  If the new method is cacheable, its definition ought to
1551    describe how, and under what conditions, a cache can store a response
1552    and use it to satisfy a subsequent request.  The new method ought to
1553    describe whether it can be made conditional (Section 5.2) and, if so,
1554    how a server responds when the condition is false.  Likewise, if the
1555    new method might have some use for partial response semantics
1556    ([RFC7233]), it ought to document this, too.
1557
1558
1559Section 8.1.3., paragraph 1:
1560OLD:
1561
1562    The HTTP Method Registry shall be populated with the registrations
1563    below:
1564
1565NEW:
1566
1567    The "Hypertext Transfer Protocol (HTTP) Method Registry" has been
1568    populated with the registrations below:
1569
1570
1571Section 8.2., paragraph 1:
1572OLD:
1573
1574    The HTTP Status Code Registry defines the name space for the response
1575    status-code token (Section 6).  The status code registry is
1576    maintained at <http://www.iana.org/assignments/http-status-codes>.
1577
1578NEW:
1579
1580    The "Hypertext Transfer Protocol (HTTP) Status Code Registry" defines
1581    the namespace for the response status-code token (Section 6).  The
1582    "HTTP Status Codes" registry is maintained at
1583    <http://www.iana.org/assignments/http-status-codes>.
1584
1585
1586Section 8.2., paragraph 2:
1587OLD:
1588
1589    This Section replaces the registration procedure for HTTP Status
1590    Codes previously defined in Section 7.1 of [RFC2817].
1591
1592NEW:
1593
1594    This section replaces the registration procedure for HTTP Status
1595    Codes previously defined in Section 7.1 of [RFC2817].
1596
1597
1598Section 8.2.3., paragraph 1:
1599OLD:
1600
1601    The HTTP Status Code Registry shall be updated with the registrations
1602    below:
1603
1604NEW:
1605
1606    The "HTTP Status Codes" registry has been updated with the
1607    registrations below:
1608
1609
1610Section 8.3., paragraph 1:
1611OLD:
1612
1613    HTTP header fields are registered within the Message Header Field
1614    Registry located at <http://www.iana.org/assignments/message-headers/
1615    message-header-index.html>, as defined by [BCP90].
1616
1617NEW:
1618
1619    HTTP header fields are registered within the "Message Headers"
1620    registry located at <http://www.iana.org/assignments/message-headers>
1621    as defined by [BCP90].
1622
1623
1624Section 8.3.1., paragraph 3:
1625OLD:
1626
1627    Authors of specifications defining new fields are advised to keep the
1628    name as short as practical and to not prefix the name with "X-"
1629    unless the header field will never be used on the Internet.  (The
1630    "x-" prefix idiom has been extensively misused in practice; it was
1631    intended to only be used as a mechanism for avoiding name collisions
1632    inside proprietary software or intranet processing, since the prefix
1633    would ensure that private names never collide with a newly registered
1634    Internet name; see [BCP178] for further information)
1635
1636NEW:
1637
1638    Authors of specifications defining new fields are advised to keep the
1639    name as short as practical and not to prefix the name with "X-"
1640    unless the header field will never be used on the Internet.  (The
1641    "X-" prefix idiom has been extensively misused in practice; it was
1642    intended to only be used as a mechanism for avoiding name collisions
1643    inside proprietary software or intranet processing, since the prefix
1644    would ensure that private names never collide with a newly registered
1645    Internet name; see [BCP178] for further information).
1646
1647
1648Section 8.3.1., paragraph 4:
1649OLD:
1650
1651    New header field values typically have their syntax defined using
1652    ABNF ([RFC5234]), using the extension defined in Section 7 of
1653    [RFC7230] as necessary, and are usually constrained to the range of
1654    ASCII characters.  Header fields needing a greater range of
1655    characters can use an encoding such as the one defined in [RFC5987].
1656
1657NEW:
1658
1659    New header field values typically have their syntax defined using
1660    ABNF ([RFC5234]) (implementing the extension defined in Section 7 of
1661    [RFC7230] as necessary), and they are usually constrained to the
1662    range of ASCII characters.  Header fields needing a greater range of
1663    characters can use an encoding such as the one defined in [RFC5987].
1664
1665
1666Section 8.3.2., paragraph 1:
1667OLD:
1668
1669    The Message Header Field Registry shall be updated with the following
1670    permanent registrations:
1671
1672NEW:
1673
1674    The "Message Headers" registry has been updated with the following
1675    permanent registrations:
1676
1677
1678Section 8.3.2., paragraph 2:
1679OLD:
1680
1681    +-------------------+----------+----------+-----------------+
1682    | Header Field Name | Protocol | Status   | Reference       |
1683    +-------------------+----------+----------+-----------------+
1684    | Accept            | http     | standard | Section 5.3.2   |
1685    | Accept-Charset    | http     | standard | Section 5.3.3   |
1686    | Accept-Encoding   | http     | standard | Section 5.3.4   |
1687    | Accept-Language   | http     | standard | Section 5.3.5   |
1688    | Allow             | http     | standard | Section 7.4.1   |
1689    | Content-Encoding  | http     | standard | Section 3.1.2.2 |
1690    | Content-Language  | http     | standard | Section 3.1.3.2 |
1691    | Content-Location  | http     | standard | Section 3.1.4.2 |
1692    | Content-Type      | http     | standard | Section 3.1.1.5 |
1693    | Date              | http     | standard | Section 7.1.1.2 |
1694    | Expect            | http     | standard | Section 5.1.1   |
1695    | From              | http     | standard | Section 5.5.1   |
1696    | Location          | http     | standard | Section 7.1.2   |
1697    | MIME-Version      | http     | standard | Appendix A.1    |
1698    | Max-Forwards      | http     | standard | Section 5.1.2   |
1699    | Referer           | http     | standard | Section 5.5.2   |
1700    | Retry-After       | http     | standard | Section 7.1.3   |
1701    | Server            | http     | standard | Section 7.4.2   |
1702    | User-Agent        | http     | standard | Section 5.5.3   |
1703    | Vary              | http     | standard | Section 7.1.4   |
1704    +-------------------+----------+----------+-----------------+
1705
1706NEW:
1707
1708    +-------------------+----------+----------+-----------------+
1709    | Header Field Name | Protocol | Status   | Reference       |
1710    +-------------------+----------+----------+-----------------+
1711    | Accept            | http     | standard | Section 5.3.2   |
1712    | Accept-Charset    | http     | standard | Section 5.3.3   |
1713    | Accept-Encoding   | http     | standard | Section 5.3.4   |
1714    | Accept-Language   | http     | standard | Section 5.3.5   |
1715    | Allow             | http     | standard | Section 7.4.1   |
1716    | Content-Encoding  | http     | standard | Section 3.1.2.2 |
1717    | Content-Language  | http     | standard | Section 3.1.3.2 |
1718    | Content-Location  | http     | standard | Section 3.1.4.2 |
1719    | Content-Type      | http     | standard | Section 3.1.1.5 |
1720    | Date              | http     | standard | Section 7.1.1.2 |
1721    | Expect            | http     | standard | Section 5.1.1   |
1722    | From              | http     | standard | Section 5.5.1   |
1723    | Location          | http     | standard | Section 7.1.2   |
1724    | Max-Forwards      | http     | standard | Section 5.1.2   |
1725    | MIME-Version      | http     | standard | Appendix A.1    |
1726    | Referer           | http     | standard | Section 5.5.2   |
1727    | Retry-After       | http     | standard | Section 7.1.3   |
1728    | Server            | http     | standard | Section 7.4.2   |
1729    | User-Agent        | http     | standard | Section 5.5.3   |
1730    | Vary              | http     | standard | Section 7.1.4   |
1731    +-------------------+----------+----------+-----------------+
1732
1733
1734Section 8.4., paragraph 1:
1735OLD:
1736
1737    The HTTP Content Coding Registry defines the name space for content
1738    coding names (Section 4.2 of [RFC7230]).  The content coding registry
1739    is maintained at <http://www.iana.org/assignments/http-parameters>.
1740
1741NEW:
1742
1743    The "HTTP Content Coding Registry" defines the namespace for content
1744    coding names (Section 4.2 of [RFC7230]).  The "HTTP Content Coding
1745    Registry" is maintained at
1746    <http://www.iana.org/assignments/http-parameters>.
1747
1748
1749Section 8.4.1., paragraph 1:
1750OLD:
1751
1752    Content Coding registrations MUST include the following fields:
1753
1754NEW:
1755
1756    Content coding registrations MUST include the following fields:
1757
1758
1759Section 8.4.1., paragraph 6:
1760OLD:
1761
1762    Values to be added to this name space require IETF Review (see
1763    Section 4.1 of [RFC5226]), and MUST conform to the purpose of content
1764    coding defined in this section.
1765
1766NEW:
1767
1768    Values to be added to this namespace require IETF Review (see Section
1769    4.1 of [RFC5226]) and MUST conform to the purpose of content coding
1770    defined in this section.
1771
1772
1773Section 8.4.2., paragraph 1:
1774OLD:
1775
1776    The HTTP Content Codings Registry shall be updated with the
1777    registrations below:
1778
1779NEW:
1780
1781    The "HTTP Content Codings Registry" has been updated with the
1782    registrations below:
1783
1784
1785Section 9., paragraph 2:
1786OLD:
1787
1788    The list of considerations below is not exhaustive.  Most security
1789    concerns related to HTTP semantics are about securing server-side
1790    applications (code behind the HTTP interface), securing user agent
1791    processing of payloads received via HTTP, or secure use of the
1792    Internet in general, rather than security of the protocol.  Various
1793    organizations maintain topical information and links to current
1794    research on Web application security (e.g., [OWASP]).
1795
1796NEW:
1797
1798    The list of considerations below is not exhaustive.  Most security
1799    concerns related to HTTP semantics are about securing server-side
1800    applications (code behind the HTTP interface) or securing user-agent
1801    processing of payloads received via HTTP.  Secure use of the Internet
1802    in general, rather than security of the protocol, might also be
1803    related.  Various organizations maintain topical information and
1804    links to current research on Web application security (e.g.,
1805    [OWASP]).
1806
1807
1808Section 9.1., paragraph 2:
1809OLD:
1810
1811    For example, UNIX, Microsoft Windows, and other operating systems use
1812    ".." as a path component to indicate a directory level above the
1813    current one, and use specially named paths or file names to send data
1814    to system devices.  Similar naming conventions might exist within
1815    other types of storage systems.  Likewise, local storage systems have
1816    an annoying tendency to prefer user-friendliness over security when
1817    handling invalid or unexpected characters, recomposition of
1818    decomposed characters, and case-normalization of case-insensitive
1819    names.
1820
1821NEW:
1822
1823    For example, UNIX, Microsoft Windows, and other operating systems use
1824    ".." as a path component to indicate a directory level above the
1825    current one, and they use specially named paths or file names to send
1826    data to system devices.  Similar naming conventions might exist
1827    within other types of storage systems.  Likewise, local storage
1828    systems have an annoying tendency to prefer user-friendliness over
1829    security when handling invalid or unexpected characters,
1830    recomposition of decomposed characters, and case-normalization of
1831    case-insensitive names.
1832
1833
1834Section 9.4., paragraph 3:
1835OLD:
1836
1837    Since the Referer header field tells a target site about the context
1838    that resulted in a request, it has the potential to reveal
1839    information about the user's immediate browsing history and any
1840    personal information that might be found in the referring resource's
1841    URI.  Limitations on Referer are described in Section 5.5.2 to
1842    address some of its security considerations.
1843
1844NEW:
1845
1846    Since the Referer header field tells a target site about the context
1847    that resulted in a request, it has the potential to reveal
1848    information about the user's immediate browsing history and any
1849    personal information that might be found in the referring resource's
1850    URI.  Limitations on the Referer header field are described in
1851    Section 5.5.2 to address some of its security considerations.
1852
1853
1854Section 11.1., paragraph 9:
1855OLD:
1856
1857    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1858               Protocol (HTTP/1.1): Message Syntax and Routing",
1859               draft-ietf-httpbis-p1-messaging-latest (work in progress),
1860               May 2014.
1861
1862NEW:
1863
1864    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1865               Protocol (HTTP/1.1): Message Syntax and Routing",
1866               RFC 7230, May 2014.
1867
1868
1869Section 11.1., paragraph 10:
1870OLD:
1871
1872    [RFC7232]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1873               Protocol (HTTP/1.1): Conditional Requests",
1874               draft-ietf-httpbis-p4-conditional-latest (work in
1875               progress), May 2014.
1876
1877NEW:
1878
1879    [RFC7232]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1880               Protocol (HTTP/1.1): Conditional Requests", RFC 7232,
1881               May 2014.
1882
1883
1884Section 11.1., paragraph 11:
1885OLD:
1886
1887    [RFC7233]  Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
1888               "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
1889               draft-ietf-httpbis-p5-range-latest (work in progress),
1890               May 2014.
1891
1892NEW:
1893
1894    [RFC7233]  Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
1895               "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
1896               RFC 7233, May 2014.
1897
1898
1899Section 11.1., paragraph 12:
1900OLD:
1901
1902    [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1903               Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
1904               draft-ietf-httpbis-p6-cache-latest (work in progress),
1905               May 2014.
1906
1907NEW:
1908
1909    [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1910               Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
1911               RFC 7234, May 2014.
1912
1913
1914Section 11.1., paragraph 13:
1915OLD:
1916
1917    [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1918               Protocol (HTTP/1.1): Authentication",
1919               draft-ietf-httpbis-p7-auth-latest (work in progress),
1920               May 2014.
1921
1922NEW:
1923
1924    [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1925               Protocol (HTTP/1.1): Authentication", RFC 7235, May 2014.
1926
1927
1928Section 11.2., paragraph 25:
1929OLD:
1930
1931    [RFC7238]  Reschke, J., "The Hypertext Transfer Protocol (HTTP)
1932               Status Code 308 (Permanent Redirect)",
1933               draft-reschke-http-status-308-07 (work in progress),
1934               March 2012.
1935
1936NEW:
1937
1938    [RFC7238]  Reschke, J., "The Hypertext Transfer Protocol (HTTP)
1939               Status Code 308 (Permanent Redirect)", RFC 7238, May 2014.
1940
1941
1942Appendix A., paragraph 1:
1943OLD:
1944
1945    HTTP/1.1 uses many of the constructs defined for the Internet Message
1946    Format [RFC5322] and the Multipurpose Internet Mail Extensions (MIME)
1947    [RFC2045] to allow a message body to be transmitted in an open
1948    variety of representations and with extensible header fields.
1949    However, RFC 2045 is focused only on email; applications of HTTP have
1950    many characteristics that differ from email, and hence HTTP has
1951    features that differ from MIME.  These differences were carefully
1952    chosen to optimize performance over binary connections, to allow
1953    greater freedom in the use of new media types, to make date
1954    comparisons easier, and to acknowledge the practice of some early
1955    HTTP servers and clients.
1956
1957NEW:
1958
1959    HTTP/1.1 uses many of the constructs defined for the Internet Message
1960    Format [RFC5322] and the Multipurpose Internet Mail Extensions (MIME)
1961    [RFC2045] to allow a message body to be transmitted in an open
1962    variety of representations and with extensible header fields.
1963    However, RFC 2045 is focused only on email; applications of HTTP have
1964    many characteristics that differ from email; hence, HTTP has features
1965    that differ from MIME.  These differences were carefully chosen to
1966    optimize performance over binary connections, to allow greater
1967    freedom in the use of new media types, to make date comparisons
1968    easier, and to acknowledge the practice of some early HTTP servers
1969    and clients.
1970
1971
1972Appendix A., paragraph 16:
1973OLD:
1974
1975 A.6.  MHTML and Line Length Limitations
1976
1977NEW:
1978
1979 A.6.  MHTML and Line-Length Limitations
1980
1981
1982Appendix A., paragraph 17:
1983OLD:
1984
1985    HTTP implementations that share code with MHTML [RFC2557]
1986    implementations need to be aware of MIME line length limitations.
1987    Since HTTP does not have this limitation, HTTP does not fold long
1988    lines.  MHTML messages being transported by HTTP follow all
1989    conventions of MHTML, including line length limitations and folding,
1990    canonicalization, etc., since HTTP transfers message-bodies as
1991    payload and, aside from the "multipart/byteranges" type (Appendix A
1992    of [RFC7233]), does not interpret the content or any MIME header
1993    lines that might be contained therein.
1994
1995NEW:
1996
1997    HTTP implementations that share code with MHTML [RFC2557]
1998    implementations need to be aware of MIME line-length limitations.
1999    Since HTTP does not have this limitation, HTTP does not fold long
2000    lines.  MHTML messages being transported by HTTP follow all
2001    conventions of MHTML, including line-length limitations and folding,
2002    canonicalization, etc., since HTTP transfers message-bodies as
2003    payload and, aside from the "multipart/byteranges" type (Appendix A
2004    of [RFC7233]), does not interpret the content or any MIME header
2005    lines that might be contained therein.
2006
2007
2008Appendix B., paragraph 2:
2009OLD:
2010
2011    A new requirement has been added that semantics embedded in a URI
2012    should be disabled when those semantics are inconsistent with the
2013    request method, since this is a common cause of interoperability
2014    failure.  (Section 2)
2015
2016NEW:
2017
2018    A new requirement has been added that semantics embedded in a URI be
2019    disabled when those semantics are inconsistent with the request
2020    method, since this is a common cause of interoperability failure
2021    (Section 2).
2022
2023
2024Appendix B., paragraph 3:
2025OLD:
2026
2027    An algorithm has been added for determining if a payload is
2028    associated with a specific identifier.  (Section 3.1.4.1)
2029
2030NEW:
2031
2032    An algorithm has been added for determining if a payload is
2033    associated with a specific identifier (Section 3.1.4.1).
2034
2035
2036Appendix B., paragraph 4:
2037OLD:
2038
2039    The default charset of ISO-8859-1 for text media types has been
2040    removed; the default is now whatever the media type definition says.
2041    Likewise, special treatment of ISO-8859-1 has been removed from the
2042    Accept-Charset header field.  (Section 3.1.1.3 and Section 5.3.3)
2043
2044NEW:
2045
2046    The default charset of ISO-8859-1 for text media types has been
2047    removed; the default is now whatever the media type definition says.
2048    Likewise, special treatment of ISO-8859-1 has been removed from the
2049    Accept-Charset header field.  (Sections 3.1.1.3 and 5.3.3.)
2050
2051
2052Appendix B., paragraph 5:
2053OLD:
2054
2055    The definition of Content-Location has been changed to no longer
2056    affect the base URI for resolving relative URI references, due to
2057    poor implementation support and the undesirable effect of potentially
2058    breaking relative links in content-negotiated resources.
2059    (Section 3.1.4.2)
2060
2061NEW:
2062
2063    The definition of Content-Location has been changed to no longer
2064    affect the base URI for resolving relative URI references, due to
2065    poor implementation support and the undesirable effect of potentially
2066    breaking relative links in content-negotiated resources
2067    (Section 3.1.4.2).
2068
2069
2070Appendix B., paragraph 6:
2071OLD:
2072
2073    To be consistent with the method-neutral parsing algorithm of
2074    [RFC7230], the definition of GET has been relaxed so that requests
2075    can have a body, even though a body has no meaning for GET.
2076    (Section 4.3.1)
2077
2078NEW:
2079
2080    To be consistent with the method-neutral parsing algorithm of
2081    [RFC7230], the definition of GET has been relaxed so that requests
2082    can have a body, even though a body has no meaning for GET
2083    (Section 4.3.1).
2084
2085
2086Appendix B., paragraph 7:
2087OLD:
2088
2089    Servers are no longer required to handle all Content-* header fields
2090    and use of Content-Range has been explicitly banned in PUT requests.
2091    (Section 4.3.4)
2092
2093NEW:
2094
2095    Servers are no longer required to handle all Content-* header fields
2096    and use of Content-Range has been explicitly banned in PUT requests
2097    (Section 4.3.4).
2098
2099
2100Appendix B., paragraph 8:
2101OLD:
2102
2103    Definition of the CONNECT method has been moved from [RFC2817] to
2104    this specification.  (Section 4.3.6)
2105
2106NEW:
2107
2108    Definition of the CONNECT method has been moved from [RFC2817] to
2109    this specification (Section 4.3.6).
2110
2111
2112Appendix B., paragraph 9:
2113OLD:
2114
2115    The OPTIONS and TRACE request methods have been defined as being
2116    safe.  (Section 4.3.7 and Section 4.3.8)
2117
2118NEW:
2119
2120    The OPTIONS and TRACE request methods have been defined as being safe
2121    (Section 4.3.7 and Section 4.3.8).
2122
2123
2124Appendix B., paragraph 10:
2125OLD:
2126
2127    The Expect header field's extension mechanism has been removed due to
2128    widely-deployed broken implementations.  (Section 5.1.1)
2129
2130NEW:
2131
2132    The Expect header field's extension mechanism has been removed due to
2133    widely deployed broken implementations (Section 5.1.1).
2134
2135
2136Appendix B., paragraph 11:
2137OLD:
2138
2139    The Max-Forwards header field has been restricted to the OPTIONS and
2140    TRACE methods; previously, extension methods could have used it as
2141    well.  (Section 5.1.2)
2142
2143NEW:
2144
2145    The Max-Forwards header field has been restricted to the OPTIONS and
2146    TRACE methods; previously, extension methods could have used it as
2147    well (Section 5.1.2).
2148
2149
2150Appendix B., paragraph 12:
2151OLD:
2152
2153    The "about:blank" URI has been suggested as a value for the Referer
2154    header field when no referring URI is applicable, which distinguishes
2155    that case from others where the Referer field is not sent or has been
2156    removed.  (Section 5.5.2)
2157
2158NEW:
2159
2160    The "about:blank" URI has been suggested as a value for the Referer
2161    header field when no referring URI is applicable, which distinguishes
2162    that case from others where the Referer field is not sent or has been
2163    removed (Section 5.5.2).
2164
2165
2166Appendix B., paragraph 13:
2167OLD:
2168
2169    The following status codes are now cacheable (that is, they can be
2170    stored and reused by a cache without explicit freshness information
2171    present): 204, 404, 405, 414, 501.  (Section 6)
2172
2173NEW:
2174
2175    The following status codes are now cacheable (that is, they can be
2176    stored and reused by a cache without explicit freshness information
2177    present): 204, 404, 405, 414, 501 (Section 6).
2178
2179
2180Appendix B., paragraph 14:
2181OLD:
2182
2183    The 201 (Created) status description has been changed to allow for
2184    the possibility that more than one resource has been created.
2185    (Section 6.3.2)
2186
2187NEW:
2188
2189    The 201 (Created) status description has been changed to allow for
2190    the possibility that more than one resource has been created
2191    (Section 6.3.2).
2192
2193
2194Appendix B., paragraph 15:
2195OLD:
2196
2197    The definition of 203 (Non-Authoritative Information) has been
2198    broadened to include cases of payload transformations as well.
2199    (Section 6.3.4)
2200
2201NEW:
2202
2203    The definition of 203 (Non-Authoritative Information) has been
2204    broadened to include cases of payload transformations as well
2205    (Section 6.3.4).
2206
2207
2208Appendix B., paragraph 16:
2209OLD:
2210
2211    The set of request methods that are safe to automatically redirect is
2212    no longer closed; user agents are able to make that determination
2213    based upon the request method semantics.  The redirect status codes
2214    301, 302, and 307 no longer have normative requirements on response
2215    payloads and user interaction.  (Section 6.4)
2216
2217NEW:
2218
2219    The set of request methods that are safe to automatically redirect is
2220    no longer closed; user agents are able to make that determination
2221    based upon the request method semantics.  The redirect status codes
2222    301, 302, and 307 no longer have normative requirements on response
2223    payloads and user interaction (Section 6.4).
2224
2225
2226Appendix B., paragraph 17:
2227OLD:
2228
2229    The status codes 301 and 302 have been changed to allow user agents
2230    to rewrite the method from POST to GET.  (Sections 6.4.2 and 6.4.3)
2231
2232NEW:
2233
2234    The status codes 301 and 302 have been changed to allow user agents
2235    to rewrite the method from POST to GET.  (Sections 6.4.2 and 6.4.3.)
2236
2237
2238Appendix B., paragraph 18:
2239OLD:
2240
2241    The description of 303 (See Other) status code has been changed to
2242    allow it to be cached if explicit freshness information is given, and
2243    a specific definition has been added for a 303 response to GET.
2244    (Section 6.4.4)
2245
2246NEW:
2247
2248    The description of the 303 (See Other) status code has been changed
2249    to allow it to be cached if explicit freshness information is given,
2250    and a specific definition has been added for a 303 response to GET
2251    (Section 6.4.4).
2252
2253
2254Appendix B., paragraph 19:
2255OLD:
2256
2257    The 305 (Use Proxy) status code has been deprecated due to security
2258    concerns regarding in-band configuration of a proxy.  (Section 6.4.5)
2259
2260NEW:
2261
2262    The 305 (Use Proxy) status code has been deprecated due to security
2263    concerns regarding in-band configuration of a proxy (Section 6.4.5).
2264
2265
2266Appendix B., paragraph 20:
2267OLD:
2268
2269    The 400 (Bad Request) status code has been relaxed so that it isn't
2270    limited to syntax errors.  (Section 6.5.1)
2271
2272NEW:
2273
2274    The 400 (Bad Request) status code has been relaxed so that it isn't
2275    limited to syntax errors (Section 6.5.1).
2276
2277
2278Appendix B., paragraph 21:
2279OLD:
2280
2281    The 426 (Upgrade Required) status code has been incorporated from
2282    [RFC2817].  (Section 6.5.15)
2283
2284NEW:
2285
2286    The 426 (Upgrade Required) status code has been incorporated from
2287    [RFC2817] (Section 6.5.15).
2288
2289
2290Appendix B., paragraph 22:
2291OLD:
2292
2293    The target of requirements on HTTP-date and the Date header field
2294    have been reduced to those systems generating the date, rather than
2295    all systems sending a date.  (Section 7.1.1)
2296
2297NEW:
2298
2299    The target of requirements on HTTP-date and the Date header field
2300    have been reduced to those systems generating the date, rather than
2301    all systems sending a date (Section 7.1.1).
2302
2303
2304Appendix B., paragraph 23:
2305OLD:
2306
2307    The syntax of the Location header field has been changed to allow all
2308    URI references, including relative references and fragments, along
2309    with some clarifications as to when use of fragments would not be
2310    appropriate.  (Section 7.1.2)
2311
2312NEW:
2313
2314    The syntax of the Location header field has been changed to allow all
2315    URI references, including relative references and fragments, along
2316    with some clarifications as to when use of fragments would not be
2317    appropriate (Section 7.1.2).
2318
2319
2320Appendix B., paragraph 24:
2321OLD:
2322
2323    Allow has been reclassified as a response header field, removing the
2324    option to specify it in a PUT request.  Requirements relating to the
2325    content of Allow have been relaxed; correspondingly, clients are not
2326    required to always trust its value.  (Section 7.4.1)
2327
2328NEW:
2329
2330    Allow has been reclassified as a response header field, removing the
2331    option to specify it in a PUT request.  Requirements relating to the
2332    content of Allow have been relaxed; correspondingly, clients are not
2333    required to always trust its value (Section 7.4.1).
2334
2335
2336Appendix B., paragraph 25:
2337OLD:
2338
2339    A Method Registry has been defined.  (Section 8.1)
2340
2341NEW:
2342
2343    A Method Registry has been defined (Section 8.1).
2344
2345
2346Appendix B., paragraph 26:
2347OLD:
2348
2349    The Status Code Registry has been redefined by this specification;
2350    previously, it was defined in Section 7.1 of [RFC2817].
2351 
2352    (Section 8.2)
2353
2354NEW:
2355
2356    The Status Code Registry has been redefined by this specification;
2357    previously, it was defined in Section 7.1 of [RFC2817] (Section 8.2).
2358
2359
2360Appendix B., paragraph 27:
2361OLD:
2362
2363    Registration of Content Codings has been changed to require IETF
2364    Review.  (Section 8.4)
2365
2366NEW:
2367
2368    Registration of content codings has been changed to require IETF
2369    Review (Section 8.4).
2370
2371
2372Section 1.2, paragraph 1:
2373OLD:
2374
2375    Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
2376     OWS ( media-range [ accept-params ] ) ] ) ]
2377    Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS
2378     "," [ OWS ( ( charset / "*" ) [ weight ] ) ] )
2379    Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS
2380     ( codings [ weight ] ) ] ) ]
2381    Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS
2382     "," [ OWS ( language-range [ weight ] ) ] )
2383    Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ]
2384    BWS = <BWS, defined in [RFC7230], Section 3.2.3>
2385
2386NEW:
2387
2388    Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
2389     OWS ( media-range [ accept-params ] ) ] ) ]
2390    Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS
2391     "," [ OWS ( ( charset / "*" ) [ weight ] ) ] )
2392    Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS
2393     ( codings [ weight ] ) ] ) ]
2394    Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS
2395     "," [ OWS ( language-range [ weight ] ) ] )
2396    Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ]
2397 
2398    BWS = <BWS, defined in [RFC7230], Section 3.2.3>
2399
2400
2401Section 1.2, paragraph 2:
2402OLD:
2403
2404    Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS
2405     content-coding ] )
2406    Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS
2407     language-tag ] )
2408    Content-Location = absolute-URI / partial-URI
2409    Content-Type = media-type
2410 
2411    Date = HTTP-date
2412
2413NEW:
2414
2415    Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS
2416     content-coding ] )
2417    Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS
2418     language-tag ] )
2419    Content-Location = absolute-URI / partial-URI
2420    Content-Type = media-type
2421    Date = HTTP-date
2422
2423
2424Section 1.2, paragraph 16:
2425OLD:
2426
2427    charset = token
2428    codings = content-coding / "identity" / "*"
2429    comment = <comment, defined in [RFC7230], Section 3.2.6>
2430    content-coding = token
2431    date1 = day SP month SP year
2432    date2 = day "-" month "-" 2DIGIT
2433    date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
2434    day = 2DIGIT
2435    day-name = %x4D.6F.6E ; Mon
2436     / %x54.75.65 ; Tue
2437     / %x57.65.64 ; Wed
2438     / %x54.68.75 ; Thu
2439     / %x46.72.69 ; Fri
2440     / %x53.61.74 ; Sat
2441     / %x53.75.6E ; Sun
2442    day-name-l = %x4D.6F.6E.64.61.79 ; Monday
2443     / %x54.75.65.73.64.61.79 ; Tuesday
2444     / %x57.65.64.6E.65.73.64.61.79 ; Wednesday
2445     / %x54.68.75.72.73.64.61.79 ; Thursday
2446     / %x46.72.69.64.61.79 ; Friday
2447     / %x53.61.74.75.72.64.61.79 ; Saturday
2448     / %x53.75.6E.64.61.79 ; Sunday
2449    delay-seconds = 1*DIGIT
2450
2451NEW:
2452
2453    charset = token
2454    codings = content-coding / "identity" / "*"
2455    comment = <comment, defined in [RFC7230], Section 3.2.6>
2456    content-coding = token
2457 
2458    date1 = day SP month SP year
2459    date2 = day "-" month "-" 2DIGIT
2460    date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
2461    day = 2DIGIT
2462    day-name = %x4D.6F.6E ; Mon
2463     / %x54.75.65 ; Tue
2464     / %x57.65.64 ; Wed
2465     / %x54.68.75 ; Thu
2466     / %x46.72.69 ; Fri
2467     / %x53.61.74 ; Sat
2468     / %x53.75.6E ; Sun
2469    day-name-l = %x4D.6F.6E.64.61.79 ; Monday
2470     / %x54.75.65.73.64.61.79 ; Tuesday
2471     / %x57.65.64.6E.65.73.64.61.79 ; Wednesday
2472     / %x54.68.75.72.73.64.61.79 ; Thursday
2473     / %x46.72.69.64.61.79 ; Friday
2474     / %x53.61.74.75.72.64.61.79 ; Saturday
2475     / %x53.75.6E.64.61.79 ; Sunday
2476    delay-seconds = 1*DIGIT
2477
2478
2479Section 1.2, paragraph 21:
2480OLD:
2481
2482    obs-date = rfc850-date / asctime-date
2483    parameter = token "=" ( token / quoted-string )
2484    partial-URI = <partial-URI, defined in [RFC7230], Section 2.7>
2485    product = token [ "/" product-version ]
2486    product-version = token
2487 
2488    quoted-string = <quoted-string, defined in [RFC7230], Section 3.2.6>
2489    qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
2490
2491NEW:
2492
2493    obs-date = rfc850-date / asctime-date
2494 
2495    parameter = token "=" ( token / quoted-string )
2496    partial-URI = <partial-URI, defined in [RFC7230], Section 2.7>
2497    product = token [ "/" product-version ]
2498    product-version = token
2499    quoted-string = <quoted-string, defined in [RFC7230], Section 3.2.6>
2500    qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
2501
2502
2503Section 1.2, paragraph 47:
2504OLD:
2505
2506    M
2507       Max-Forwards header field  36
2508       MIME-Version header field  89
2509
2510NEW:
2511
2512    M
2513       Max-Forwards header field  36
2514       MIME-Version header field  88
2515
2516
2517Section 345, paragraph 1:
2518OLD:
2519
2520    EMail: fielding@gbiv.com
2521    URI:   http://roy.gbiv.com/
2522    Julian F. Reschke (editor)
2523    greenbytes GmbH
2524    Hafenweg 16
2525    Muenster, NW  48155
2526    Germany
2527
2528NEW:
2529
2530    EMail: fielding@gbiv.com
2531    URI:   http://roy.gbiv.com/
2532 
2533    Julian F. Reschke (editor)
2534    greenbytes GmbH
2535    Hafenweg 16
2536    Muenster, NW  48155
2537    Germany
2538
Note: See TracBrowser for help on using the repository browser.