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

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

IANA considerations: vertical ws, past tense (#553)

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