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

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

mainly grammatical fixes (#553)

File size: 84.9 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 2., paragraph 1:
390OLD:
391
392    The target of an HTTP request is called a resource.  HTTP does not
393    limit the nature of a resource; it merely defines an interface that
394    might be used to interact with resources.  Each resource is
395    identified by a Uniform Resource Identifier (URI), as described in
396    Section 2.7 of [RFC7230].
397
398NEW:
399
400    The target of an HTTP request is called a "resource".  HTTP does not
401    limit the nature of a resource; it merely defines an interface that
402    might be used to interact with resources.  Each resource is
403    identified by a Uniform Resource Identifier (URI), as described in
404    Section 2.7 of [RFC7230].
405
406
407Section 3.1.1.1., paragraph 1:
408OLD:
409
410    HTTP uses Internet Media Types [RFC2046] in the Content-Type
411    (Section 3.1.1.5) and Accept (Section 5.3.2) header fields in order
412    to provide open and extensible data typing and type negotiation.
413    Media types define both a data format and various processing models:
414    how to process that data in accordance with each context in which it
415    is received.
416
417NEW:
418
419    HTTP uses Internet media types [RFC2046] in the Content-Type
420    (Section 3.1.1.5) and Accept (Section 5.3.2) header fields in order
421    to provide open and extensible data typing and type negotiation.
422    Media types define both a data format and various processing models:
423    how to process that data in accordance with each context in which it
424    is received.
425
426
427Section 3.1.1.1., paragraph 5:
428OLD:
429
430    The type, subtype, and parameter name tokens are case-insensitive.
431    Parameter values might or might not be case-sensitive, depending on
432    the semantics of the parameter name.  The presence or absence of a
433    parameter might be significant to the processing of a media-type,
434    depending on its definition within the media type registry.
435
436NEW:
437
438    The type, subtype, and parameter name tokens are case insensitive.
439    Parameter values might or might not be case sensitive, depending on
440    the semantics of the parameter name.  The presence or absence of a
441    parameter might be significant to the processing of a media-type,
442    depending on its definition within the media type registry.
443
444
445Section 3.1.1.2., paragraph 3:
446OLD:
447
448    Charset names ought to be registered in the IANA Character Set
449    registry (<http://www.iana.org/assignments/character-sets>) according
450    to the procedures defined in [RFC2978].
451
452NEW:
453
454    Charset names ought to be registered in the IANA "Character Sets"
455    registry <http://www.iana.org/assignments/character-sets> according
456    to the procedures defined in [RFC2978].
457
458
459Section 3.1.1.3., paragraph 2:
460OLD:
461
462    MIME's canonical form requires that media subtypes of the "text" type
463    use CRLF as the text line break.  HTTP allows the transfer of text
464    media with plain CR or LF alone representing a line break, when such
465    line breaks are consistent for an entire representation.  An HTTP
466    sender MAY generate, and a recipient MUST be able to parse, line
467    breaks in text media that consist of CRLF, bare CR, or bare LF.  In
468    addition, text media in HTTP is not limited to charsets that use
469    octets 13 and 10 for CR and LF, respectively.  This flexibility
470    regarding line breaks applies only to text within a representation
471    that has been assigned a "text" media type; it does not apply to
472    "multipart" types or HTTP elements outside the payload body (e.g.,
473    header fields).
474
475NEW:
476
477    MIME's canonical form requires that media subtypes of the "text" type
478    use CRLF as the text line break.  HTTP allows the transfer of text
479    media with plain carriage return (CR) or line feed (LF) alone
480    representing a line break, when such line breaks are consistent for
481    an entire representation.  An HTTP sender MAY generate, and a
482    recipient MUST be able to parse, line breaks in text media that
483    consist of CRLF, bare CR, or bare LF.  In addition, text media in
484    HTTP is not limited to charsets that use octets 13 and 10 for CR and
485    LF, respectively.  This flexibility regarding line breaks applies
486    only to text within a representation that has been assigned a "text"
487    media type; it does not apply to "multipart" types or HTTP elements
488    outside the payload body (e.g., header fields).
489
490
491Section 3.1.2.1., paragraph 3:
492OLD:
493
494    All content-coding values are case-insensitive and ought to be
495    registered within the HTTP Content Coding registry, as defined in
496    Section 8.4.  They are used in the Accept-Encoding (Section 5.3.4)
497    and Content-Encoding (Section 3.1.2.2) header fields.
498
499NEW:
500
501    All content-coding values are case insensitive and ought to be
502    registered within the "HTTP Content Coding Registry", as defined in
503    Section 8.4.  They are used in the Accept-Encoding (Section 5.3.4)
504    and Content-Encoding (Section 3.1.2.2) header fields.
505
506
507Section 3.1.3.2., paragraph 5:
508OLD:
509
510    If no Content-Language is specified, the default is that the content
511    is intended for all language audiences.  This might mean that the
512    sender does not consider it to be specific to any natural language,
513    or that the sender does not know for which language it is intended.
514
515NEW:
516
517    If no Content-Language is specified, the default is that the content
518    is intended for all language audiences.  This might mean that the
519    sender does not consider it to be specific to any natural language,
520    or that the sender does not know which language is being used.
521
522
523Section 3.4.1., paragraph 2:
524OLD:
525
526    Proactive negotiation is advantageous when the algorithm for
527    selecting from among the available representations is difficult to
528    describe to a user agent, or when the server desires to send its
529    "best guess" to the user agent along with the first response (hoping
530    to avoid the round trip delay of a subsequent request if the "best
531    guess" is good enough for the user).  In order to improve the
532    server's guess, a user agent MAY send request header fields that
533    describe its preferences.
534
535NEW:
536
537    Proactive negotiation is advantageous when the algorithm for
538    selecting from among the available representations is difficult to
539    describe to a user agent, or when the server desires to send its
540    "best guess" to the user agent along with the first response (hoping
541    to avoid the round-trip delay of a subsequent request if the "best
542    guess" is good enough for the user).  In order to improve the
543    server's guess, a user agent MAY send request header fields that
544    describe its preferences.
545
546
547Section 406, paragraph 1:
548OLD:
549
550    Reactive negotiation is advantageous when the response would vary
551    over commonly-used dimensions (such as type, language, or encoding),
552    when the origin server is unable to determine a user agent's
553    capabilities from examining the request, and generally when public
554    caches are used to distribute server load and reduce network usage.
555
556NEW:
557
558    Reactive negotiation is advantageous when the response would vary
559    over commonly used dimensions (such as type, language, or encoding),
560    when the origin server is unable to determine a user agent's
561    capabilities from examining the request, and generally when public
562    caches are used to distribute server load and reduce network usage.
563
564
565Section 4.1., paragraph 4:
566OLD:
567
568    HTTP was originally designed to be usable as an interface to
569    distributed object systems.  The request method was envisioned as
570    applying semantics to a target resource in much the same way as
571    invoking a defined method on an identified object would apply
572    semantics.  The method token is case-sensitive because it might be
573    used as a gateway to object-based systems with case-sensitive method
574    names.
575
576NEW:
577
578    HTTP was originally designed to be usable as an interface to
579    distributed object systems.  The request method was envisioned as
580    applying semantics to a target resource in much the same way as
581    invoking a defined method on an identified object would apply
582    semantics.  The method token is case sensitive because it might be
583    used as a gateway to object-based systems with case-sensitive method
584    names.
585
586
587Section 4.1., paragraph 5:
588OLD:
589
590    Unlike distributed objects, the standardized request methods in HTTP
591    are not resource-specific, since uniform interfaces provide for
592    better visibility and reuse in network-based systems [REST].  Once
593    defined, a standardized method ought to have the same semantics when
594    applied to any resource, though each resource determines for itself
595    whether those semantics are implemented or allowed.
596
597NEW:
598
599    Unlike distributed objects, the standardized request methods in HTTP
600    are not resource specific, since uniform interfaces provide for
601    better visibility and reuse in network-based systems [REST].  Once
602    defined, a standardized method ought to have the same semantics when
603    applied to any resource, though each resource determines for itself
604    whether those semantics are implemented or allowed.
605
606
607Section 4.1., paragraph 9:
608OLD:
609
610    Additional methods, outside the scope of this specification, have
611    been standardized for use in HTTP.  All such methods ought to be
612    registered within the HTTP Method Registry maintained by IANA, as
613    defined in Section 8.1.
614
615NEW:
616
617    Additional methods, outside the scope of this specification, have
618    been standardized for use in HTTP.  All such methods ought to be
619    registered within the "Hypertext Transfer Protocol (HTTP) Method"
620    registry maintained by IANA, as defined in Section 8.1.
621
622
623Section 4.2.1., paragraph 2:
624OLD:
625
626    This definition of safe methods does not prevent an implementation
627    from including behavior that is potentially harmful, not entirely
628    read-only, or which causes side-effects while invoking a safe method.
629    What is important, however, is that the client did not request that
630    additional behavior and cannot be held accountable for it.  For
631    example, most servers append request information to access log files
632    at the completion of every response, regardless of the method, and
633    that is considered safe even though the log storage might become full
634    and crash the server.  Likewise, a safe request initiated by
635    selecting an advertisement on the Web will often have the side-effect
636    of charging an advertising account.
637
638NEW:
639
640    This definition of safe method does not prevent an implementation
641    from including behavior that is potentially harmful, that is not
642    entirely read-only, or that causes side effects while invoking a safe
643    method.  What is important, however, is that the client did not
644    request that additional behavior and cannot be held accountable for
645    it.  For example, most servers append request information to access
646    log files at the completion of every response, regardless of the
647    method, and that is considered safe even though the log storage might
648    become full and crash the server.  Likewise, a safe request initiated
649    by selecting an advertisement on the Web will often have the side
650    effect of charging an advertising account.
651
652
653Section 4.2.1., paragraph 6:
654OLD:
655
656    When a resource is constructed such that parameters within the
657    effective request URI have the effect of selecting an action, it is
658    the resource owner's responsibility to ensure that the action is
659    consistent with the request method semantics.  For example, it is
660    common for Web-based content editing software to use actions within
661    query parameters, such as "page?do=delete".  If the purpose of such a
662    resource is to perform an unsafe action, then the resource owner MUST
663    disable or disallow that action when it is accessed using a safe
664    request method.  Failure to do so will result in unfortunate side-
665    effects when automated processes perform a GET on every URI reference
666    for the sake of link maintenance, pre-fetching, building a search
667    index, etc.
668
669NEW:
670
671    When a resource is constructed such that parameters within the
672    effective request URI have the effect of selecting an action, it is
673    the resource owner's responsibility to ensure that the action is
674    consistent with the request method semantics.  For example, it is
675    common for Web-based content editing software to use actions within
676    query parameters, such as "page?do=delete".  If the purpose of such a
677    resource is to perform an unsafe action, then the resource owner MUST
678    disable or disallow that action when it is accessed using a safe
679    request method.  Failure to do so will result in unfortunate side
680    effects when automated processes perform a GET on every URI reference
681    for the sake of link maintenance, pre-fetching, building a search
682    index, etc.
683
684
685Section 4.2.2., paragraph 2:
686OLD:
687
688    Like the definition of safe, the idempotent property only applies to
689    what has been requested by the user; a server is free to log each
690    request separately, retain a revision control history, or implement
691    other non-idempotent side-effects for each idempotent request.
692
693NEW:
694
695    Like the definition of safe, the idempotent property only applies to
696    what has been requested by the user; a server is free to log each
697    request separately, retain a revision control history, or implement
698    other non-idempotent side effects for each idempotent request.
699
700
701Section 4.3.3., paragraph 6:
702OLD:
703
704    An origin server indicates response semantics by choosing an
705    appropriate status code depending on the result of processing the
706    POST request; almost all of the status codes defined by this
707    specification might be received in a response to POST (the exceptions
708    being 206, 304, and 416).
709
710NEW:
711
712    An origin server indicates response semantics by choosing an
713    appropriate status code depending on the result of processing the
714    POST request; almost all of the status codes defined by this
715    specification might be received in a response to POST (the exceptions
716    being 206 (Partial Content), 304 (Not Modified), and 416 (Range Not
717    Satisfiable)).
718
719
720Section 4.3.4., paragraph 13:
721OLD:
722
723    A PUT request applied to the target resource can have side-effects on
724    other resources.  For example, an article might have a URI for
725    identifying "the current version" (a resource) that is separate from
726    the URIs identifying each particular version (different resources
727    that at one point shared the same state as the current version
728    resource).  A successful PUT request on "the current version" URI
729    might therefore create a new version resource in addition to changing
730    the state of the target resource, and might also cause links to be
731    added between the related resources.
732
733NEW:
734
735    A PUT request applied to the target resource can have side effects on
736    other resources.  For example, an article might have a URI for
737    identifying "the current version" (a resource) that is separate from
738    the URIs identifying each particular version (different resources
739    that at one point shared the same state as the current version
740    resource).  A successful PUT request on "the current version" URI
741    might therefore create a new version resource in addition to changing
742    the state of the target resource, and might also cause links to be
743    added between the related resources.
744
745
746Section 4.3.6., paragraph 2:
747OLD:
748
749    CONNECT is intended only for use in requests to a proxy.  An origin
750    server that receives a CONNECT request for itself MAY respond with a
751    2xx status code to indicate that a connection is established.
752    However, most origin servers do not implement CONNECT.
753
754NEW:
755
756    CONNECT is intended only for use in requests to a proxy.  An origin
757    server that receives a CONNECT request for itself MAY respond with a
758    2xx (Successful) status code to indicate that a connection is
759    established.  However, most origin servers do not implement CONNECT.
760
761
762Section 4.3.8., paragraph 2:
763OLD:
764
765    A client MUST NOT generate header fields in a TRACE request
766    containing sensitive data that might be disclosed by the response.
767 
768    For example, it would be foolish for a user agent to send stored user
769    credentials [RFC7235] or cookies [RFC6265] in a TRACE request.  The
770    final recipient of the request SHOULD exclude any request header
771    fields that are likely to contain sensitive data when that recipient
772    generates the response body.
773
774NEW:
775
776    A client MUST NOT generate header fields in a TRACE request
777    containing sensitive data that might be disclosed by the response.
778    For example, it would be foolish for a user agent to send stored user
779    credentials [RFC7235] or cookies [RFC6265] in a TRACE request.  The
780    final recipient of the request SHOULD exclude any request header
781    fields that are likely to contain sensitive data when that recipient
782    generates the response body.
783
784
785Section 5.1.1., paragraph 3:
786OLD:
787
788    The Expect field-value is case-insensitive.
789
790NEW:
791
792    The Expect field-value is case insensitive.
793
794
795Section 5.1.1., paragraph 21:
796OLD:
797
798       Note: The Expect header field was added after the original
799       publication of HTTP/1.1 [RFC2068] as both the means to request an
800       interim 100 response and the general mechanism for indicating
801       must-understand extensions.  However, the extension mechanism has
802       not been used by clients and the must-understand requirements have
803       not been implemented by many servers, rendering the extension
804       mechanism useless.  This specification has removed the extension
805       mechanism in order to simplify the definition and processing of
806       100-continue.
807
808NEW:
809
810       Note: The Expect header field was added after the original
811       publication of HTTP/1.1 [RFC2068] as both the means to request an
812       interim 100 (Continue) response and the general mechanism for
813       indicating must-understand extensions.  However, the extension
814       mechanism has not been used by clients and the must-understand
815       requirements have not been implemented by many servers, rendering
816       the extension mechanism useless.  This specification has removed
817       the extension mechanism in order to simplify the definition and
818       processing of 100-continue.
819
820
821Section 5.3.2., paragraph 9:
822OLD:
823
824    is interpreted as "I prefer audio/basic, but send me any audio type
825    if it is the best available after an 80% mark-down in quality".
826
827NEW:
828
829    is interpreted as "I prefer audio/basic, but send me any audio type
830    if it is the best available after an 80% markdown in quality".
831
832
833Section 5.5.1., paragraph 1:
834OLD:
835
836    The "From" header field contains an Internet email address for a
837    human user who controls the requesting user agent.  The address ought
838    to be machine-usable, as defined by "mailbox" in Section 3.4 of
839    [RFC5322]:
840
841NEW:
842
843    The "From" header field contains an Internet email address for a
844    human user who controls the requesting user agent.  The address ought
845    to be machine usable, as defined by "mailbox" in Section 3.4 of
846    [RFC5322]:
847
848
849Section 5.5.2., paragraph 6:
850OLD:
851
852    If the target URI was obtained from a source that does not have its
853    own URI (e.g., input from the user keyboard, or an entry within the
854    user's bookmarks/favorites), the user agent MUST either exclude
855    Referer or send it with a value of "about:blank".
856
857NEW:
858
859    If the target URI was obtained from a source that does not have its
860    own URI (e.g., input from the user keyboard, or an entry within the
861    user's bookmarks/favorites), the user agent MUST either exclude the
862    Referer or send it with a value of "about:blank".
863
864
865Section 5.5.2., paragraph 8:
866OLD:
867
868    Some intermediaries have been known to indiscriminately remove
869    Referer header fields from outgoing requests.  This has the
870    unfortunate side-effect of interfering with protection against CSRF
871    attacks, which can be far more harmful to their users.
872    Intermediaries and user agent extensions that wish to limit
873    information disclosure in Referer ought to restrict their changes to
874    specific edits, such as replacing internal domain names with
875    pseudonyms or truncating the query and/or path components.  An
876    intermediary SHOULD NOT modify or delete the Referer header field
877    when the field value shares the same scheme and host as the request
878    target.
879
880NEW:
881
882    Some intermediaries have been known to indiscriminately remove
883    Referer header fields from outgoing requests.  This has the
884    unfortunate side effect of interfering with protection against CSRF
885    attacks, which can be far more harmful to their users.
886    Intermediaries and user agent extensions that wish to limit
887    information disclosure in Referer ought to restrict their changes to
888    specific edits, such as replacing internal domain names with
889    pseudonyms or truncating the query and/or path components.  An
890    intermediary SHOULD NOT modify or delete the Referer header field
891    when the field value shares the same scheme and host as the request
892    target.
893
894
895Section 5.5.3., paragraph 1:
896OLD:
897
898    The "User-Agent" header field contains information about the user
899    agent originating the request, which is often used by servers to help
900    identify the scope of reported interoperability problems, to work
901    around or tailor responses to avoid particular user agent
902    limitations, and for analytics regarding browser or operating system
903    use.  A user agent SHOULD send a User-Agent field in each request
904    unless specifically configured not to do so.
905
906NEW:
907
908    The "User-Agent" header field contains information about the user
909    agent originating the request, which is often used by servers to help
910    identify the scope of reported interoperability problems, to work
911    around or tailor responses to avoid particular user-agent
912    limitations, and for analytics regarding browser or operating system
913    use.  A user agent SHOULD send a User-Agent field in each request
914    unless specifically configured not to do so.
915
916
917Section 5.5.3., paragraph 3:
918OLD:
919
920    The User-Agent field-value consists of one or more product
921    identifiers, each followed by zero or more comments (Section 3.2 of
922    [RFC7230]), which together identify the user agent software and its
923    significant subproducts.  By convention, the product identifiers are
924    listed in decreasing order of their significance for identifying the
925    user agent software.  Each product identifier consists of a name and
926    optional version.
927
928NEW:
929
930    The User-Agent field-value consists of one or more product
931    identifiers, each followed by zero or more comments (Section 3.2 of
932    [RFC7230]), which together identify the user-agent software and its
933    significant subproducts.  By convention, the product identifiers are
934    listed in decreasing order of their significance for identifying the
935    user-agent software.  Each product identifier consists of a name and
936    optional version.
937
938
939Section 5.5.3., paragraph 5:
940OLD:
941
942    A sender SHOULD limit generated product identifiers to what is
943    necessary to identify the product; a sender MUST NOT generate
944    advertising or other non-essential information within the product
945    identifier.  A sender SHOULD NOT generate information in product-
946    version that is not a version identifier (i.e., successive versions
947    of the same product name ought only to differ in the product-version
948    portion of the product identifier).
949
950NEW:
951
952    A sender SHOULD limit generated product identifiers to what is
953    necessary to identify the product; a sender MUST NOT generate
954    advertising or other nonessential information within the product
955    identifier.  A sender SHOULD NOT generate information in product-
956    version that is not a version identifier (i.e., successive versions
957    of the same product name ought only to differ in the product-version
958    portion of the product identifier).
959
960
961Section 5.5.3., paragraph 9:
962OLD:
963
964    Likewise, implementations are encouraged not to use the product
965    tokens of other implementations in order to declare compatibility
966    with them, as this circumvents the purpose of the field.  If a user
967    agent masquerades as a different user agent, recipients can assume
968    that the user intentionally desires to see responses tailored for
969    that identified user agent, even if they might not work as well for
970    the actual user agent being used.
971
972NEW:
973
974    Likewise, implementations are encouraged not to use the product
975    tokens of other implementations in order to declare compatibility
976    with them, as this circumvents the purpose of the field.  If a user
977    agent masquerades as a different user agent, recipients can assume
978    that the user intentionally desires to see responses tailored for
979    that identified user agent, even if they might not work as well for
980    the actual user agent being implemented.
981
982
983Section 6., paragraph 3:
984OLD:
985
986    For example, if an unrecognized status code of 471 is received by a
987    client, the client can assume that there was something wrong with its
988    request and treat the response as if it had received a 400 status
989    code.  The response message will usually contain a representation
990    that explains the status.
991
992NEW:
993
994    For example, if an unrecognized status code of 471 is received by a
995    client, the client can assume that there was something wrong with its
996    request and treat the response as if it had received a 400 (Bad
997    Request) status code.  The response message will usually contain a
998    representation that explains the status.
999
1000
1001Section 6.1., paragraph 2:
1002OLD:
1003
1004    Responses with status codes that are defined as cacheable by default
1005    (e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501 in this
1006    specification) can be reused by a cache with heuristic expiration
1007    unless otherwise indicated by the method definition or explicit cache
1008    controls [RFC7234]; all other status codes are not cacheable by
1009    default.
1010
1011NEW:
1012
1013    Responses with status codes that are defined as cacheable by default
1014    (e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501 in
1015    this specification) can be reused by a cache with heuristic
1016    expiration unless otherwise indicated by the method definition or
1017    explicit cache controls [RFC7234]; all other status codes are not
1018    cacheable by default.
1019
1020
1021Section 6.3.3., paragraph 2:
1022OLD:
1023
1024    The 202 response is intentionally non-committal.  Its purpose is to
1025    allow a server to accept a request for some other process (perhaps a
1026    batch-oriented process that is only run once per day) without
1027    requiring that the user agent's connection to the server persist
1028    until the process is completed.  The representation sent with this
1029    response ought to describe the request's current status and point to
1030    (or embed) a status monitor that can provide the user with an
1031    estimate of when the request will be fulfilled.
1032
1033NEW:
1034
1035    The 202 response is intentionally noncommittal.  Its purpose is to
1036    allow a server to accept a request for some other process (perhaps a
1037    batch-oriented process that is only run once per day) without
1038    requiring that the user agent's connection to the server persist
1039    until the process is completed.  The representation sent with this
1040    response ought to describe the request's current status and point to
1041    (or embed) a status monitor that can provide the user with an
1042    estimate of when the request will be fulfilled.
1043
1044
1045Section 6.4.1., paragraph 5:
1046OLD:
1047
1048       Note: The original proposal for 300 defined the URI header field
1049       as providing a list of alternative representations, such that it
1050       would be usable for 200, 300, and 406 responses and be transferred
1051       in responses to the HEAD method.  However, lack of deployment and
1052       disagreement over syntax led to both URI and Alternates (a
1053       subsequent proposal) being dropped from this specification.  It is
1054       possible to communicate the list using a set of Link header fields
1055       [RFC5988], each with a relationship of "alternate", though
1056       deployment is a chicken-and-egg problem.
1057
1058NEW:
1059
1060       Note: The original proposal for the 300 response defined the URI
1061       header field as providing a list of alternative representations,
1062       such that it would be usable for 200, 300, and 406 responses and
1063       be transferred in responses to the HEAD method.  However, lack of
1064       deployment and disagreement over syntax led to both URI and
1065       Alternates (a subsequent proposal) being dropped from this
1066       specification.  It is possible to communicate the list using a set
1067       of Link header fields [RFC5988], each with a relationship of
1068       "alternate", though deployment is a chicken-and-egg problem.
1069
1070
1071Section 6.4.2., paragraph 1:
1072OLD:
1073
1074    The 301 (Moved Permanently) status code indicates that the target
1075    resource has been assigned a new permanent URI and any future
1076    references to this resource ought to use one of the enclosed URIs.
1077    Clients with link editing capabilities ought to automatically re-link
1078    references to the effective request URI to one or more of the new
1079    references sent by the server, where possible.
1080
1081NEW:
1082
1083    The 301 (Moved Permanently) status code indicates that the target
1084    resource has been assigned a new permanent URI and any future
1085    references to this resource ought to use one of the enclosed URIs.
1086    Clients with link-editing capabilities ought to automatically re-link
1087    references to the effective request URI to one or more of the new
1088    references sent by the server, where possible.
1089
1090
1091Section 6.4.7., paragraph 3:
1092OLD:
1093
1094       Note: This status code is similar to 302 (Found), except that it
1095       does not allow changing the request method from POST to GET.  This
1096       specification defines no equivalent counterpart for 301 (Moved
1097       Permanently) ([RFC7238], however, defines the status code 308
1098       (Permanent Redirect) for this purpose).
1099
1100NEW:
1101
1102       Note: This status code is similar to 302 (Found), except that it
1103       does not allow changing the request method from POST to GET.  This
1104       specification defines no equivalent counterpart for 301 (Moved
1105       Permanently) ([RFC7238]; however, it defines the status code 308
1106       (Permanent Redirect) for this purpose).
1107
1108
1109Section 7.1.1.1., paragraph 11:
1110OLD:
1111
1112      day-name     = %x4D.6F.6E ; "Mon", case-sensitive
1113                   / %x54.75.65 ; "Tue", case-sensitive
1114                   / %x57.65.64 ; "Wed", case-sensitive
1115                   / %x54.68.75 ; "Thu", case-sensitive
1116                   / %x46.72.69 ; "Fri", case-sensitive
1117                   / %x53.61.74 ; "Sat", case-sensitive
1118                   / %x53.75.6E ; "Sun", case-sensitive
1119
1120NEW:
1121
1122      day-name     = %x4D.6F.6E ; "Mon", case sensitive
1123                   / %x54.75.65 ; "Tue", case sensitive
1124                   / %x57.65.64 ; "Wed", case sensitive
1125                   / %x54.68.75 ; "Thu", case sensitive
1126                   / %x46.72.69 ; "Fri", case sensitive
1127                   / %x53.61.74 ; "Sat", case sensitive
1128                   / %x53.75.6E ; "Sun", case sensitive
1129
1130
1131Section 7.1.1.1., paragraph 13:
1132OLD:
1133
1134      day          = 2DIGIT
1135      month        = %x4A.61.6E ; "Jan", case-sensitive
1136                   / %x46.65.62 ; "Feb", case-sensitive
1137                   / %x4D.61.72 ; "Mar", case-sensitive
1138                   / %x41.70.72 ; "Apr", case-sensitive
1139                   / %x4D.61.79 ; "May", case-sensitive
1140                   / %x4A.75.6E ; "Jun", case-sensitive
1141                   / %x4A.75.6C ; "Jul", case-sensitive
1142                   / %x41.75.67 ; "Aug", case-sensitive
1143                   / %x53.65.70 ; "Sep", case-sensitive
1144                   / %x4F.63.74 ; "Oct", case-sensitive
1145                   / %x4E.6F.76 ; "Nov", case-sensitive
1146                   / %x44.65.63 ; "Dec", case-sensitive
1147      year         = 4DIGIT
1148
1149NEW:
1150
1151      day          = 2DIGIT
1152      month        = %x4A.61.6E ; "Jan", case sensitive
1153                   / %x46.65.62 ; "Feb", case sensitive
1154                   / %x4D.61.72 ; "Mar", case sensitive
1155                   / %x41.70.72 ; "Apr", case sensitive
1156                   / %x4D.61.79 ; "May", case sensitive
1157                   / %x4A.75.6E ; "Jun", case sensitive
1158                   / %x4A.75.6C ; "Jul", case sensitive
1159                   / %x41.75.67 ; "Aug", case sensitive
1160                   / %x53.65.70 ; "Sep", case sensitive
1161                   / %x4F.63.74 ; "Oct", case sensitive
1162                   / %x4E.6F.76 ; "Nov", case sensitive
1163                   / %x44.65.63 ; "Dec", case sensitive
1164      year         = 4DIGIT
1165
1166
1167Section 7.1.1.1., paragraph 14:
1168OLD:
1169
1170      GMT          = %x47.4D.54 ; "GMT", case-sensitive
1171
1172NEW:
1173
1174      GMT          = %x47.4D.54 ; "GMT", case sensitive
1175
1176
1177Section 7.1.1.1., paragraph 19:
1178OLD:
1179
1180      day-name-l   = %x4D.6F.6E.64.61.79    ; "Monday", case-sensitive
1181             / %x54.75.65.73.64.61.79       ; "Tuesday", case-sensitive
1182             / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive
1183             / %x54.68.75.72.73.64.61.79    ; "Thursday", case-sensitive
1184             / %x46.72.69.64.61.79          ; "Friday", case-sensitive
1185             / %x53.61.74.75.72.64.61.79    ; "Saturday", case-sensitive
1186             / %x53.75.6E.64.61.79          ; "Sunday", case-sensitive
1187
1188NEW:
1189
1190      day-name-l   = %x4D.6F.6E.64.61.79    ; "Monday", case sensitive
1191             / %x54.75.65.73.64.61.79       ; "Tuesday", case sensitive
1192             / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case sensitive
1193             / %x54.68.75.72.73.64.61.79    ; "Thursday", case sensitive
1194             / %x46.72.69.64.61.79          ; "Friday", case sensitive
1195             / %x53.61.74.75.72.64.61.79    ; "Saturday", case sensitive
1196             / %x53.75.6E.64.61.79          ; "Sunday", case sensitive
1197
1198
1199Section 7.1.4., paragraph 1:
1200OLD:
1201
1202    The "Vary" header field in a response describes what parts of a
1203    request message, aside from the method, Host header field, and
1204    request target, might influence the origin server's process for
1205    selecting and representing this response.  The value consists of
1206    either a single asterisk ("*") or a list of header field names (case-
1207    insensitive).
1208
1209NEW:
1210
1211    The "Vary" header field in a response describes what parts of a
1212    request message, aside from the method, Host header field, and
1213    request target, might influence the origin server's process for
1214    selecting and representing this response.  The value consists of
1215    either a single asterisk ("*") or a list of header field names (case
1216    insensitive).
1217
1218
1219Section 1., paragraph 1:
1220OLD:
1221
1222    2.  To inform user agent recipients that this response is subject to
1223        content negotiation (Section 5.3) and that a different
1224        representation might be sent in a subsequent request if
1225        additional parameters are provided in the listed header fields
1226        (proactive negotiation).
1227
1228NEW:
1229
1230    2.  To inform user-agent recipients that this response is subject to
1231        content negotiation (Section 5.3) and that a different
1232        representation might be sent in a subsequent request if
1233        additional parameters are provided in the listed header fields
1234        (proactive negotiation).
1235
1236
1237Section 7.2., paragraph 3:
1238OLD:
1239
1240    For example, an ETag header field in a 201 response communicates the
1241    entity-tag of the newly created resource's representation, so that it
1242    can be used in later conditional requests to prevent the "lost
1243    update" problem [RFC7232].
1244
1245NEW:
1246
1247    For example, an ETag header field in a 201 (Created) response
1248    communicates the entity-tag of the newly created resource's
1249    representation, so that it can be used in later conditional requests
1250    to prevent the "lost update" problem [RFC7232].
1251
1252
1253Section 8.1., paragraph 1:
1254OLD:
1255
1256    The HTTP Method Registry defines the name space for the request
1257    method token (Section 4).  The method registry will be created and
1258    maintained at (the suggested URI)
1259    <http://www.iana.org/assignments/http-methods>.
1260
1261NEW:
1262
1263    The "Hypertext Transfer Protocol (HTTP) Method Registry" defines the
1264    namespace for the request method token (Section 4).  The "HTTP Method
1265    Registry" has been created and is now maintained at
1266    <http://www.iana.org/assignments/http-methods>.
1267
1268
1269Section 8.1.2., paragraph 3:
1270OLD:
1271
1272    A new method definition needs to indicate whether it is safe
1273    (Section 4.2.1), idempotent (Section 4.2.2), cacheable
1274    (Section 4.2.3), what semantics are to be associated with the payload
1275    body if any is present in the request, and what refinements the
1276    method makes to header field or status code semantics.  If the new
1277    method is cacheable, its definition ought to describe how, and under
1278    what conditions, a cache can store a response and use it to satisfy a
1279    subsequent request.  The new method ought to describe whether it can
1280    be made conditional (Section 5.2) and, if so, how a server responds
1281    when the condition is false.  Likewise, if the new method might have
1282    some use for partial response semantics ([RFC7233]), it ought to
1283    document this, too.
1284
1285NEW:
1286
1287    A new method definition needs to indicate whether it is safe
1288    (Section 4.2.1), idempotent (Section 4.2.2), or cacheable
1289    (Section 4.2.3).  It needs to indicate what semantics are to be
1290    associated with the payload body if any is present in the request and
1291    what refinements the method makes to header field or status code
1292    semantics.  If the new method is cacheable, its definition ought to
1293    describe how, and under what conditions, a cache can store a response
1294    and use it to satisfy a subsequent request.  The new method ought to
1295    describe whether it can be made conditional (Section 5.2) and, if so,
1296    how a server responds when the condition is false.  Likewise, if the
1297    new method might have some use for partial response semantics
1298    ([RFC7233]), it ought to document this, too.
1299
1300
1301Section 8.1.3., paragraph 1:
1302OLD:
1303
1304    The HTTP Method Registry shall be populated with the registrations
1305    below:
1306
1307NEW:
1308
1309    The "Hypertext Transfer Protocol (HTTP) Method Registry" has been
1310    populated with the registrations below:
1311
1312
1313Section 8.2., paragraph 1:
1314OLD:
1315
1316    The HTTP Status Code Registry defines the name space for the response
1317    status-code token (Section 6).  The status code registry is
1318    maintained at <http://www.iana.org/assignments/http-status-codes>.
1319
1320NEW:
1321
1322    The "Hypertext Transfer Protocol (HTTP) Status Code Registry" defines
1323    the namespace for the response status-code token (Section 6).  The
1324    "HTTP Status Codes" registry is maintained at
1325    <http://www.iana.org/assignments/http-status-codes>.
1326
1327
1328Section 8.2.3., paragraph 1:
1329OLD:
1330
1331    The HTTP Status Code Registry shall be updated with the registrations
1332    below:
1333
1334NEW:
1335
1336    The "HTTP Status Codes" registry has been updated with the
1337    registrations below:
1338
1339
1340Section 8.3., paragraph 1:
1341OLD:
1342
1343    HTTP header fields are registered within the Message Header Field
1344    Registry located at <http://www.iana.org/assignments/message-headers/
1345    message-header-index.html>, as defined by [BCP90].
1346
1347NEW:
1348
1349    HTTP header fields are registered within the "Message Headers"
1350    registry located at <http://www.iana.org/assignments/message-headers>
1351    as defined by [BCP90].
1352
1353
1354Section 8.3.1., paragraph 4:
1355OLD:
1356
1357    New header field values typically have their syntax defined using
1358    ABNF ([RFC5234]), using the extension defined in Section 7 of
1359    [RFC7230] as necessary, and are usually constrained to the range of
1360    ASCII characters.  Header fields needing a greater range of
1361    characters can use an encoding such as the one defined in [RFC5987].
1362
1363NEW:
1364
1365    New header field values typically have their syntax defined using
1366    ABNF ([RFC5234]) (implementing the extension defined in Section 7 of
1367    [RFC7230] as necessary), and they are usually constrained to the
1368    range of ASCII characters.  Header fields needing a greater range of
1369    characters can use an encoding such as the one defined in [RFC5987].
1370
1371
1372Section 8.3.2., paragraph 1:
1373OLD:
1374
1375    The Message Header Field Registry shall be updated with the following
1376    permanent registrations:
1377
1378NEW:
1379
1380    The "Message Headers" registry has been updated with the following
1381    permanent registrations:
1382
1383
1384Section 8.4., paragraph 1:
1385OLD:
1386
1387    The HTTP Content Coding Registry defines the name space for content
1388    coding names (Section 4.2 of [RFC7230]).  The content coding registry
1389    is maintained at <http://www.iana.org/assignments/http-parameters>.
1390
1391NEW:
1392
1393    The "HTTP Content Coding Registry" defines the namespace for content
1394    coding names (Section 4.2 of [RFC7230]).  The "HTTP Content Coding
1395    Registry" is maintained at
1396    <http://www.iana.org/assignments/http-parameters>.
1397
1398
1399Section 8.4.1., paragraph 1:
1400OLD:
1401
1402    Content Coding registrations MUST include the following fields:
1403
1404NEW:
1405
1406    Content coding registrations MUST include the following fields:
1407
1408
1409Section 8.4.1., paragraph 6:
1410OLD:
1411
1412    Values to be added to this name space require IETF Review (see
1413    Section 4.1 of [RFC5226]), and MUST conform to the purpose of content
1414    coding defined in this section.
1415
1416NEW:
1417
1418    Values to be added to this namespace require IETF Review (see Section
1419    4.1 of [RFC5226]) and MUST conform to the purpose of content coding
1420    defined in this section.
1421
1422
1423Section 8.4.2., paragraph 1:
1424OLD:
1425
1426    The HTTP Content Codings Registry shall be updated with the
1427    registrations below:
1428
1429NEW:
1430
1431    The "HTTP Content Codings Registry" has been updated with the
1432    registrations below:
1433
1434
1435Section 9., paragraph 2:
1436OLD:
1437
1438    The list of considerations below is not exhaustive.  Most security
1439    concerns related to HTTP semantics are about securing server-side
1440    applications (code behind the HTTP interface), securing user agent
1441    processing of payloads received via HTTP, or secure use of the
1442    Internet in general, rather than security of the protocol.  Various
1443    organizations maintain topical information and links to current
1444    research on Web application security (e.g., [OWASP]).
1445
1446NEW:
1447
1448    The list of considerations below is not exhaustive.  Most security
1449    concerns related to HTTP semantics are about securing server-side
1450    applications (code behind the HTTP interface) or securing user-agent
1451    processing of payloads received via HTTP.  Secure use of the Internet
1452    in general, rather than security of the protocol, might also be
1453    related.  Various organizations maintain topical information and
1454    links to current research on Web application security (e.g.,
1455    [OWASP]).
1456
1457
1458Section 9.1., paragraph 3:
1459OLD:
1460
1461    Attacks based on such special names tend to focus on either denial-
1462    of-service (e.g., telling the server to read from a COM port) or
1463    disclosure of configuration and source files that are not meant to be
1464    served.
1465
1466NEW:
1467
1468    Attacks based on such special names tend to focus on either denial of
1469    service (e.g., telling the server to read from a COM port) or
1470    disclosure of configuration and source files that are not meant to be
1471    served.
1472
1473
1474Section 9.4., paragraph 3:
1475OLD:
1476
1477    Since the Referer header field tells a target site about the context
1478    that resulted in a request, it has the potential to reveal
1479    information about the user's immediate browsing history and any
1480    personal information that might be found in the referring resource's
1481    URI.  Limitations on Referer are described in Section 5.5.2 to
1482    address some of its security considerations.
1483
1484NEW:
1485
1486    Since the Referer header field tells a target site about the context
1487    that resulted in a request, it has the potential to reveal
1488    information about the user's immediate browsing history and any
1489    personal information that might be found in the referring resource's
1490    URI.  Limitations on the Referer header field are described in
1491    Section 5.5.2 to address some of its security considerations.
1492
1493
1494Section 11.1., paragraph 9:
1495OLD:
1496
1497    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1498               Protocol (HTTP/1.1): Message Syntax and Routing",
1499               draft-ietf-httpbis-p1-messaging-latest (work in progress),
1500               May 2014.
1501
1502NEW:
1503
1504    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1505               Protocol (HTTP/1.1): Message Syntax and Routing",
1506               RFC 7230, May 2014.
1507
1508
1509Section 11.1., paragraph 10:
1510OLD:
1511
1512    [RFC7232]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1513               Protocol (HTTP/1.1): Conditional Requests",
1514               draft-ietf-httpbis-p4-conditional-latest (work in
1515               progress), May 2014.
1516
1517NEW:
1518
1519    [RFC7232]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1520               Protocol (HTTP/1.1): Conditional Requests", RFC 7232,
1521               May 2014.
1522
1523
1524Section 11.1., paragraph 11:
1525OLD:
1526
1527    [RFC7233]  Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
1528               "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
1529               draft-ietf-httpbis-p5-range-latest (work in progress),
1530               May 2014.
1531
1532NEW:
1533
1534    [RFC7233]  Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
1535               "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
1536               RFC 7233, May 2014.
1537
1538
1539Section 11.1., paragraph 12:
1540OLD:
1541
1542    [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1543               Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
1544               draft-ietf-httpbis-p6-cache-latest (work in progress),
1545               May 2014.
1546
1547NEW:
1548
1549    [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1550               Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
1551               RFC 7234, May 2014.
1552
1553
1554Section 11.1., paragraph 13:
1555OLD:
1556
1557    [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1558               Protocol (HTTP/1.1): Authentication",
1559               draft-ietf-httpbis-p7-auth-latest (work in progress),
1560               May 2014.
1561
1562NEW:
1563
1564    [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1565               Protocol (HTTP/1.1): Authentication", RFC 7235, May 2014.
1566
1567
1568Section 11.2., paragraph 25:
1569OLD:
1570
1571    [RFC7238]  Reschke, J., "The Hypertext Transfer Protocol (HTTP)
1572               Status Code 308 (Permanent Redirect)",
1573               draft-reschke-http-status-308-07 (work in progress),
1574               March 2012.
1575
1576NEW:
1577
1578    [RFC7238]  Reschke, J., "The Hypertext Transfer Protocol (HTTP)
1579               Status Code 308 (Permanent Redirect)", RFC 7238, May 2014.
1580
1581
1582Appendix A., paragraph 16:
1583OLD:
1584
1585 A.6.  MHTML and Line Length Limitations
1586
1587NEW:
1588
1589 A.6.  MHTML and Line-Length Limitations
1590
1591
1592Appendix A., paragraph 17:
1593OLD:
1594
1595    HTTP implementations that share code with MHTML [RFC2557]
1596    implementations need to be aware of MIME line length limitations.
1597    Since HTTP does not have this limitation, HTTP does not fold long
1598    lines.  MHTML messages being transported by HTTP follow all
1599    conventions of MHTML, including line length limitations and folding,
1600    canonicalization, etc., since HTTP transfers message-bodies as
1601    payload and, aside from the "multipart/byteranges" type (Appendix A
1602    of [RFC7233]), does not interpret the content or any MIME header
1603    lines that might be contained therein.
1604
1605NEW:
1606
1607    HTTP implementations that share code with MHTML [RFC2557]
1608    implementations need to be aware of MIME line-length limitations.
1609    Since HTTP does not have this limitation, HTTP does not fold long
1610    lines.  MHTML messages being transported by HTTP follow all
1611    conventions of MHTML, including line-length limitations and folding,
1612    canonicalization, etc., since HTTP transfers message-bodies as
1613    payload and, aside from the "multipart/byteranges" type (Appendix A
1614    of [RFC7233]), does not interpret the content or any MIME header
1615    lines that might be contained therein.
1616
1617
1618Appendix B., paragraph 2:
1619OLD:
1620
1621    A new requirement has been added that semantics embedded in a URI
1622    should be disabled when those semantics are inconsistent with the
1623    request method, since this is a common cause of interoperability
1624    failure.  (Section 2)
1625
1626NEW:
1627
1628    A new requirement has been added that semantics embedded in a URI be
1629    disabled when those semantics are inconsistent with the request
1630    method, since this is a common cause of interoperability failure
1631    (Section 2).
1632
1633
1634Appendix B., paragraph 3:
1635OLD:
1636
1637    An algorithm has been added for determining if a payload is
1638    associated with a specific identifier.  (Section 3.1.4.1)
1639
1640NEW:
1641
1642    An algorithm has been added for determining if a payload is
1643    associated with a specific identifier (Section 3.1.4.1).
1644
1645
1646Appendix B., paragraph 4:
1647OLD:
1648
1649    The default charset of ISO-8859-1 for text media types has been
1650    removed; the default is now whatever the media type definition says.
1651    Likewise, special treatment of ISO-8859-1 has been removed from the
1652    Accept-Charset header field.  (Section 3.1.1.3 and Section 5.3.3)
1653
1654NEW:
1655
1656    The default charset of ISO-8859-1 for text media types has been
1657    removed; the default is now whatever the media type definition says.
1658    Likewise, special treatment of ISO-8859-1 has been removed from the
1659    Accept-Charset header field.  (Sections 3.1.1.3 and 5.3.3.)
1660
1661
1662Appendix B., paragraph 5:
1663OLD:
1664
1665    The definition of Content-Location has been changed to no longer
1666    affect the base URI for resolving relative URI references, due to
1667    poor implementation support and the undesirable effect of potentially
1668    breaking relative links in content-negotiated resources.
1669    (Section 3.1.4.2)
1670
1671NEW:
1672
1673    The definition of Content-Location has been changed to no longer
1674    affect the base URI for resolving relative URI references, due to
1675    poor implementation support and the undesirable effect of potentially
1676    breaking relative links in content-negotiated resources
1677    (Section 3.1.4.2).
1678
1679
1680Appendix B., paragraph 6:
1681OLD:
1682
1683    To be consistent with the method-neutral parsing algorithm of
1684    [RFC7230], the definition of GET has been relaxed so that requests
1685    can have a body, even though a body has no meaning for GET.
1686    (Section 4.3.1)
1687
1688NEW:
1689
1690    To be consistent with the method-neutral parsing algorithm of
1691    [RFC7230], the definition of GET has been relaxed so that requests
1692    can have a body, even though a body has no meaning for GET
1693    (Section 4.3.1).
1694
1695
1696Appendix B., paragraph 7:
1697OLD:
1698
1699    Servers are no longer required to handle all Content-* header fields
1700    and use of Content-Range has been explicitly banned in PUT requests.
1701    (Section 4.3.4)
1702
1703NEW:
1704
1705    Servers are no longer required to handle all Content-* header fields
1706    and use of Content-Range has been explicitly banned in PUT requests
1707    (Section 4.3.4).
1708
1709
1710Appendix B., paragraph 8:
1711OLD:
1712
1713    Definition of the CONNECT method has been moved from [RFC2817] to
1714    this specification.  (Section 4.3.6)
1715
1716NEW:
1717
1718    Definition of the CONNECT method has been moved from [RFC2817] to
1719    this specification (Section 4.3.6).
1720
1721
1722Appendix B., paragraph 9:
1723OLD:
1724
1725    The OPTIONS and TRACE request methods have been defined as being
1726    safe.  (Section 4.3.7 and Section 4.3.8)
1727
1728NEW:
1729
1730    The OPTIONS and TRACE request methods have been defined as being safe
1731    (Section 4.3.7 and Section 4.3.8).
1732
1733
1734Appendix B., paragraph 10:
1735OLD:
1736
1737    The Expect header field's extension mechanism has been removed due to
1738    widely-deployed broken implementations.  (Section 5.1.1)
1739
1740NEW:
1741
1742    The Expect header field's extension mechanism has been removed due to
1743    widely deployed broken implementations (Section 5.1.1).
1744
1745
1746Appendix B., paragraph 11:
1747OLD:
1748
1749    The Max-Forwards header field has been restricted to the OPTIONS and
1750    TRACE methods; previously, extension methods could have used it as
1751    well.  (Section 5.1.2)
1752
1753NEW:
1754
1755    The Max-Forwards header field has been restricted to the OPTIONS and
1756    TRACE methods; previously, extension methods could have used it as
1757    well (Section 5.1.2).
1758
1759
1760Appendix B., paragraph 12:
1761OLD:
1762
1763    The "about:blank" URI has been suggested as a value for the Referer
1764    header field when no referring URI is applicable, which distinguishes
1765    that case from others where the Referer field is not sent or has been
1766    removed.  (Section 5.5.2)
1767
1768NEW:
1769
1770    The "about:blank" URI has been suggested as a value for the Referer
1771    header field when no referring URI is applicable, which distinguishes
1772    that case from others where the Referer field is not sent or has been
1773    removed (Section 5.5.2).
1774
1775
1776Appendix B., paragraph 13:
1777OLD:
1778
1779    The following status codes are now cacheable (that is, they can be
1780    stored and reused by a cache without explicit freshness information
1781    present): 204, 404, 405, 414, 501.  (Section 6)
1782
1783NEW:
1784
1785    The following status codes are now cacheable (that is, they can be
1786    stored and reused by a cache without explicit freshness information
1787    present): 204, 404, 405, 414, 501 (Section 6).
1788
1789
1790Appendix B., paragraph 14:
1791OLD:
1792
1793    The 201 (Created) status description has been changed to allow for
1794    the possibility that more than one resource has been created.
1795    (Section 6.3.2)
1796
1797NEW:
1798
1799    The 201 (Created) status description has been changed to allow for
1800    the possibility that more than one resource has been created
1801    (Section 6.3.2).
1802
1803
1804Appendix B., paragraph 15:
1805OLD:
1806
1807    The definition of 203 (Non-Authoritative Information) has been
1808    broadened to include cases of payload transformations as well.
1809    (Section 6.3.4)
1810
1811NEW:
1812
1813    The definition of 203 (Non-Authoritative Information) has been
1814    broadened to include cases of payload transformations as well
1815    (Section 6.3.4).
1816
1817
1818Appendix B., paragraph 16:
1819OLD:
1820
1821    The set of request methods that are safe to automatically redirect is
1822    no longer closed; user agents are able to make that determination
1823    based upon the request method semantics.  The redirect status codes
1824    301, 302, and 307 no longer have normative requirements on response
1825    payloads and user interaction.  (Section 6.4)
1826
1827NEW:
1828
1829    The set of request methods that are safe to automatically redirect is
1830    no longer closed; user agents are able to make that determination
1831    based upon the request method semantics.  The redirect status codes
1832    301, 302, and 307 no longer have normative requirements on response
1833    payloads and user interaction (Section 6.4).
1834
1835
1836Appendix B., paragraph 17:
1837OLD:
1838
1839    The status codes 301 and 302 have been changed to allow user agents
1840    to rewrite the method from POST to GET.  (Sections 6.4.2 and 6.4.3)
1841
1842NEW:
1843
1844    The status codes 301 and 302 have been changed to allow user agents
1845    to rewrite the method from POST to GET.  (Sections 6.4.2 and 6.4.3.)
1846
1847
1848Appendix B., paragraph 18:
1849OLD:
1850
1851    The description of 303 (See Other) status code has been changed to
1852    allow it to be cached if explicit freshness information is given, and
1853    a specific definition has been added for a 303 response to GET.
1854    (Section 6.4.4)
1855
1856NEW:
1857
1858    The description of the 303 (See Other) status code has been changed
1859    to allow it to be cached if explicit freshness information is given,
1860    and a specific definition has been added for a 303 response to GET
1861    (Section 6.4.4).
1862
1863
1864Appendix B., paragraph 19:
1865OLD:
1866
1867    The 305 (Use Proxy) status code has been deprecated due to security
1868    concerns regarding in-band configuration of a proxy.  (Section 6.4.5)
1869
1870NEW:
1871
1872    The 305 (Use Proxy) status code has been deprecated due to security
1873    concerns regarding in-band configuration of a proxy (Section 6.4.5).
1874
1875
1876Appendix B., paragraph 20:
1877OLD:
1878
1879    The 400 (Bad Request) status code has been relaxed so that it isn't
1880    limited to syntax errors.  (Section 6.5.1)
1881
1882NEW:
1883
1884    The 400 (Bad Request) status code has been relaxed so that it isn't
1885    limited to syntax errors (Section 6.5.1).
1886
1887
1888Appendix B., paragraph 21:
1889OLD:
1890
1891    The 426 (Upgrade Required) status code has been incorporated from
1892    [RFC2817].  (Section 6.5.15)
1893
1894NEW:
1895
1896    The 426 (Upgrade Required) status code has been incorporated from
1897    [RFC2817] (Section 6.5.15).
1898
1899
1900Appendix B., paragraph 22:
1901OLD:
1902
1903    The target of requirements on HTTP-date and the Date header field
1904    have been reduced to those systems generating the date, rather than
1905    all systems sending a date.  (Section 7.1.1)
1906
1907NEW:
1908
1909    The target of requirements on HTTP-date and the Date header field
1910    have been reduced to those systems generating the date, rather than
1911    all systems sending a date (Section 7.1.1).
1912
1913
1914Appendix B., paragraph 23:
1915OLD:
1916
1917    The syntax of the Location header field has been changed to allow all
1918    URI references, including relative references and fragments, along
1919    with some clarifications as to when use of fragments would not be
1920    appropriate.  (Section 7.1.2)
1921
1922NEW:
1923
1924    The syntax of the Location header field has been changed to allow all
1925    URI references, including relative references and fragments, along
1926    with some clarifications as to when use of fragments would not be
1927    appropriate (Section 7.1.2).
1928
1929
1930Appendix B., paragraph 24:
1931OLD:
1932
1933    Allow has been reclassified as a response header field, removing the
1934    option to specify it in a PUT request.  Requirements relating to the
1935    content of Allow have been relaxed; correspondingly, clients are not
1936    required to always trust its value.  (Section 7.4.1)
1937
1938NEW:
1939
1940    Allow has been reclassified as a response header field, removing the
1941    option to specify it in a PUT request.  Requirements relating to the
1942    content of Allow have been relaxed; correspondingly, clients are not
1943    required to always trust its value (Section 7.4.1).
1944
1945
1946Appendix B., paragraph 25:
1947OLD:
1948
1949    A Method Registry has been defined.  (Section 8.1)
1950
1951NEW:
1952
1953    A Method Registry has been defined (Section 8.1).
1954
1955
1956Appendix B., paragraph 26:
1957OLD:
1958
1959    The Status Code Registry has been redefined by this specification;
1960    previously, it was defined in Section 7.1 of [RFC2817].
1961 
1962    (Section 8.2)
1963
1964NEW:
1965
1966    The Status Code Registry has been redefined by this specification;
1967    previously, it was defined in Section 7.1 of [RFC2817] (Section 8.2).
1968
1969
1970Appendix B., paragraph 27:
1971OLD:
1972
1973    Registration of Content Codings has been changed to require IETF
1974    Review.  (Section 8.4)
1975
1976NEW:
1977
1978    Registration of content codings has been changed to require IETF
1979    Review (Section 8.4).
1980
1981
1982Section 1.2, paragraph 1:
1983OLD:
1984
1985    Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
1986     OWS ( media-range [ accept-params ] ) ] ) ]
1987    Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS
1988     "," [ OWS ( ( charset / "*" ) [ weight ] ) ] )
1989    Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS
1990     ( codings [ weight ] ) ] ) ]
1991    Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS
1992     "," [ OWS ( language-range [ weight ] ) ] )
1993    Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ]
1994    BWS = <BWS, defined in [RFC7230], Section 3.2.3>
1995
1996NEW:
1997
1998    Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
1999     OWS ( media-range [ accept-params ] ) ] ) ]
2000    Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS
2001     "," [ OWS ( ( charset / "*" ) [ weight ] ) ] )
2002    Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS
2003     ( codings [ weight ] ) ] ) ]
2004    Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS
2005     "," [ OWS ( language-range [ weight ] ) ] )
2006    Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ]
2007 
2008    BWS = <BWS, defined in [RFC7230], Section 3.2.3>
2009
2010
2011Section 1.2, paragraph 2:
2012OLD:
2013
2014    Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS
2015     content-coding ] )
2016    Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS
2017     language-tag ] )
2018    Content-Location = absolute-URI / partial-URI
2019    Content-Type = media-type
2020 
2021    Date = HTTP-date
2022
2023NEW:
2024
2025    Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS
2026     content-coding ] )
2027    Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS
2028     language-tag ] )
2029    Content-Location = absolute-URI / partial-URI
2030    Content-Type = media-type
2031    Date = HTTP-date
2032
2033
2034Section 1.2, paragraph 16:
2035OLD:
2036
2037    charset = token
2038    codings = content-coding / "identity" / "*"
2039    comment = <comment, defined in [RFC7230], Section 3.2.6>
2040    content-coding = token
2041    date1 = day SP month SP year
2042    date2 = day "-" month "-" 2DIGIT
2043    date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
2044    day = 2DIGIT
2045    day-name = %x4D.6F.6E ; Mon
2046     / %x54.75.65 ; Tue
2047     / %x57.65.64 ; Wed
2048     / %x54.68.75 ; Thu
2049     / %x46.72.69 ; Fri
2050     / %x53.61.74 ; Sat
2051     / %x53.75.6E ; Sun
2052    day-name-l = %x4D.6F.6E.64.61.79 ; Monday
2053     / %x54.75.65.73.64.61.79 ; Tuesday
2054     / %x57.65.64.6E.65.73.64.61.79 ; Wednesday
2055     / %x54.68.75.72.73.64.61.79 ; Thursday
2056     / %x46.72.69.64.61.79 ; Friday
2057     / %x53.61.74.75.72.64.61.79 ; Saturday
2058     / %x53.75.6E.64.61.79 ; Sunday
2059    delay-seconds = 1*DIGIT
2060
2061NEW:
2062
2063    charset = token
2064    codings = content-coding / "identity" / "*"
2065    comment = <comment, defined in [RFC7230], Section 3.2.6>
2066    content-coding = token
2067 
2068    date1 = day SP month SP year
2069    date2 = day "-" month "-" 2DIGIT
2070    date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
2071    day = 2DIGIT
2072    day-name = %x4D.6F.6E ; Mon
2073     / %x54.75.65 ; Tue
2074     / %x57.65.64 ; Wed
2075     / %x54.68.75 ; Thu
2076     / %x46.72.69 ; Fri
2077     / %x53.61.74 ; Sat
2078     / %x53.75.6E ; Sun
2079    day-name-l = %x4D.6F.6E.64.61.79 ; Monday
2080     / %x54.75.65.73.64.61.79 ; Tuesday
2081     / %x57.65.64.6E.65.73.64.61.79 ; Wednesday
2082     / %x54.68.75.72.73.64.61.79 ; Thursday
2083     / %x46.72.69.64.61.79 ; Friday
2084     / %x53.61.74.75.72.64.61.79 ; Saturday
2085     / %x53.75.6E.64.61.79 ; Sunday
2086    delay-seconds = 1*DIGIT
2087
2088
2089Section 1.2, paragraph 21:
2090OLD:
2091
2092    obs-date = rfc850-date / asctime-date
2093    parameter = token "=" ( token / quoted-string )
2094    partial-URI = <partial-URI, defined in [RFC7230], Section 2.7>
2095    product = token [ "/" product-version ]
2096    product-version = token
2097 
2098    quoted-string = <quoted-string, defined in [RFC7230], Section 3.2.6>
2099    qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
2100
2101NEW:
2102
2103    obs-date = rfc850-date / asctime-date
2104 
2105    parameter = token "=" ( token / quoted-string )
2106    partial-URI = <partial-URI, defined in [RFC7230], Section 2.7>
2107    product = token [ "/" product-version ]
2108    product-version = token
2109    quoted-string = <quoted-string, defined in [RFC7230], Section 3.2.6>
2110    qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
2111
2112
2113Section 1.2, paragraph 47:
2114OLD:
2115
2116    M
2117       Max-Forwards header field  36
2118       MIME-Version header field  89
2119
2120NEW:
2121
2122    M
2123       Max-Forwards header field  36
2124       MIME-Version header field  88
2125
2126
2127Section 345, paragraph 1:
2128OLD:
2129
2130    EMail: fielding@gbiv.com
2131    URI:   http://roy.gbiv.com/
2132    Julian F. Reschke (editor)
2133    greenbytes GmbH
2134    Hafenweg 16
2135    Muenster, NW  48155
2136    Germany
2137
2138NEW:
2139
2140    EMail: fielding@gbiv.com
2141    URI:   http://roy.gbiv.com/
2142 
2143    Julian F. Reschke (editor)
2144    greenbytes GmbH
2145    Hafenweg 16
2146    Muenster, NW  48155
2147    Germany
2148
Note: See TracBrowser for help on using the repository browser.