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

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

hyphenation (#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 will be created and
1090    maintained at (the suggested URI)
1091    <http://www.iana.org/assignments/http-methods>.
1092
1093NEW:
1094
1095    The "Hypertext Transfer Protocol (HTTP) Method Registry" defines the
1096    namespace for the request method token (Section 4).  The "HTTP Method
1097    Registry" has been created and is now maintained at
1098    <http://www.iana.org/assignments/http-methods>.
1099
1100
1101Section 8.1.2., paragraph 3:
1102OLD:
1103
1104    A new method definition needs to indicate whether it is safe
1105    (Section 4.2.1), idempotent (Section 4.2.2), cacheable
1106    (Section 4.2.3), what semantics are to be associated with the payload
1107    body if any is present in the request, and what refinements the
1108    method makes to header field or status code semantics.  If the new
1109    method is cacheable, its definition ought to describe how, and under
1110    what conditions, a cache can store a response and use it to satisfy a
1111    subsequent request.  The new method ought to describe whether it can
1112    be made conditional (Section 5.2) and, if so, how a server responds
1113    when the condition is false.  Likewise, if the new method might have
1114    some use for partial response semantics ([RFC7233]), it ought to
1115    document this, too.
1116
1117NEW:
1118
1119    A new method definition needs to indicate whether it is safe
1120    (Section 4.2.1), idempotent (Section 4.2.2), or cacheable
1121    (Section 4.2.3).  It needs to indicate what semantics are to be
1122    associated with the payload body if any is present in the request and
1123    what refinements the method makes to header field or status code
1124    semantics.  If the new method is cacheable, its definition ought to
1125    describe how, and under what conditions, a cache can store a response
1126    and use it to satisfy a subsequent request.  The new method ought to
1127    describe whether it can be made conditional (Section 5.2) and, if so,
1128    how a server responds when the condition is false.  Likewise, if the
1129    new method might have some use for partial response semantics
1130    ([RFC7233]), it ought to document this, too.
1131
1132
1133Section 8.1.3., paragraph 1:
1134OLD:
1135
1136    The HTTP Method Registry shall be populated with the registrations
1137    below:
1138
1139NEW:
1140
1141    The "Hypertext Transfer Protocol (HTTP) Method Registry" has been
1142    populated with the registrations below:
1143
1144
1145Section 8.2., paragraph 1:
1146OLD:
1147
1148    The HTTP Status Code Registry defines the namespace for the response
1149    status-code token (Section 6).  The status code registry is
1150    maintained at <http://www.iana.org/assignments/http-status-codes>.
1151
1152NEW:
1153
1154    The "Hypertext Transfer Protocol (HTTP) Status Code Registry" defines
1155    the namespace for the response status-code token (Section 6).  The
1156    "HTTP Status Codes" registry is maintained at
1157    <http://www.iana.org/assignments/http-status-codes>.
1158
1159
1160Section 8.2.3., paragraph 1:
1161OLD:
1162
1163    The HTTP Status Code Registry shall be updated with the registrations
1164    below:
1165
1166NEW:
1167
1168    The "HTTP Status Codes" registry has been updated with the
1169    registrations below:
1170
1171
1172Section 8.3., paragraph 1:
1173OLD:
1174
1175    HTTP header fields are registered within the Message Header Field
1176    Registry located at <http://www.iana.org/assignments/message-headers/
1177    message-header-index.html>, as defined by [BCP90].
1178
1179NEW:
1180
1181    HTTP header fields are registered within the "Message Headers"
1182    registry located at <http://www.iana.org/assignments/message-headers>
1183    as defined by [BCP90].
1184
1185
1186Section 8.3.1., paragraph 4:
1187OLD:
1188
1189    New header field values typically have their syntax defined using
1190    ABNF ([RFC5234]), using the extension defined in Section 7 of
1191    [RFC7230] as necessary, and are usually constrained to the range of
1192    ASCII characters.  Header fields needing a greater range of
1193    characters can use an encoding such as the one defined in [RFC5987].
1194
1195NEW:
1196
1197    New header field values typically have their syntax defined using
1198    ABNF ([RFC5234]) (implementing the extension defined in Section 7 of
1199    [RFC7230] as necessary), and they are usually constrained to the
1200    range of ASCII characters.  Header fields needing a greater range of
1201    characters can use an encoding such as the one defined in [RFC5987].
1202
1203
1204Section 8.3.2., paragraph 1:
1205OLD:
1206
1207    The Message Header Field Registry shall be updated with the following
1208    permanent registrations:
1209
1210NEW:
1211
1212    The "Message Headers" registry has been updated with the following
1213    permanent registrations:
1214
1215
1216Section 8.4., paragraph 1:
1217OLD:
1218
1219    The HTTP Content Coding Registry defines the namespace for content
1220    coding names (Section 4.2 of [RFC7230]).  The content coding registry
1221    is maintained at <http://www.iana.org/assignments/http-parameters>.
1222
1223NEW:
1224
1225    The "HTTP Content Coding Registry" defines the namespace for content
1226    coding names (Section 4.2 of [RFC7230]).  The "HTTP Content Coding
1227    Registry" is maintained at
1228    <http://www.iana.org/assignments/http-parameters>.
1229
1230
1231Section 8.4.1., paragraph 1:
1232OLD:
1233
1234    Content Coding registrations MUST include the following fields:
1235
1236NEW:
1237
1238    Content coding registrations MUST include the following fields:
1239
1240
1241Section 8.4.1., paragraph 6:
1242OLD:
1243
1244    Values to be added to this namespace require IETF Review (see Section
1245    4.1 of [RFC5226]), and MUST conform to the purpose of content coding
1246    defined in this section.
1247
1248NEW:
1249
1250    Values to be added to this namespace require IETF Review (see Section
1251    4.1 of [RFC5226]) and MUST conform to the purpose of content coding
1252    defined in this section.
1253
1254
1255Section 8.4.2., paragraph 1:
1256OLD:
1257
1258    The HTTP Content Codings Registry shall be updated with the
1259    registrations below:
1260
1261NEW:
1262
1263    The "HTTP Content Codings Registry" has been updated with the
1264    registrations below:
1265
1266
1267Section 9., paragraph 2:
1268OLD:
1269
1270    The list of considerations below is not exhaustive.  Most security
1271    concerns related to HTTP semantics are about securing server-side
1272    applications (code behind the HTTP interface), securing user agent
1273    processing of payloads received via HTTP, or secure use of the
1274    Internet in general, rather than security of the protocol.  Various
1275    organizations maintain topical information and links to current
1276    research on Web application security (e.g., [OWASP]).
1277
1278NEW:
1279
1280    The list of considerations below is not exhaustive.  Most security
1281    concerns related to HTTP semantics are about securing server-side
1282    applications (code behind the HTTP interface) or securing user-agent
1283    processing of payloads received via HTTP.  Secure use of the Internet
1284    in general, rather than security of the protocol, might also be
1285    related.  Various organizations maintain topical information and
1286    links to current research on Web application security (e.g.,
1287    [OWASP]).
1288
1289
1290Section 9.1., paragraph 3:
1291OLD:
1292
1293    Attacks based on such special names tend to focus on either denial-
1294    of-service (e.g., telling the server to read from a COM port) or
1295    disclosure of configuration and source files that are not meant to be
1296    served.
1297
1298NEW:
1299
1300    Attacks based on such special names tend to focus on either denial of
1301    service (e.g., telling the server to read from a COM port) or
1302    disclosure of configuration and source files that are not meant to be
1303    served.
1304
1305
1306Section 9.4., paragraph 3:
1307OLD:
1308
1309    Since the Referer header field tells a target site about the context
1310    that resulted in a request, it has the potential to reveal
1311    information about the user's immediate browsing history and any
1312    personal information that might be found in the referring resource's
1313    URI.  Limitations on Referer are described in Section 5.5.2 to
1314    address some of its security considerations.
1315
1316NEW:
1317
1318    Since the Referer header field tells a target site about the context
1319    that resulted in a request, it has the potential to reveal
1320    information about the user's immediate browsing history and any
1321    personal information that might be found in the referring resource's
1322    URI.  Limitations on the Referer header field are described in
1323    Section 5.5.2 to address some of its security considerations.
1324
1325
1326Section 11.1., paragraph 9:
1327OLD:
1328
1329    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1330               Protocol (HTTP/1.1): Message Syntax and Routing",
1331               draft-ietf-httpbis-p1-messaging-latest (work in progress),
1332               May 2014.
1333
1334NEW:
1335
1336    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1337               Protocol (HTTP/1.1): Message Syntax and Routing",
1338               RFC 7230, May 2014.
1339
1340
1341Section 11.1., paragraph 10:
1342OLD:
1343
1344    [RFC7232]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1345               Protocol (HTTP/1.1): Conditional Requests",
1346               draft-ietf-httpbis-p4-conditional-latest (work in
1347               progress), May 2014.
1348
1349NEW:
1350
1351    [RFC7232]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1352               Protocol (HTTP/1.1): Conditional Requests", RFC 7232,
1353               May 2014.
1354
1355
1356Section 11.1., paragraph 11:
1357OLD:
1358
1359    [RFC7233]  Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
1360               "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
1361               draft-ietf-httpbis-p5-range-latest (work in progress),
1362               May 2014.
1363
1364NEW:
1365
1366    [RFC7233]  Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
1367               "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
1368               RFC 7233, May 2014.
1369
1370
1371Section 11.1., paragraph 12:
1372OLD:
1373
1374    [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1375               Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
1376               draft-ietf-httpbis-p6-cache-latest (work in progress),
1377               May 2014.
1378
1379NEW:
1380
1381    [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1382               Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
1383               RFC 7234, May 2014.
1384
1385
1386Section 11.1., paragraph 13:
1387OLD:
1388
1389    [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1390               Protocol (HTTP/1.1): Authentication",
1391               draft-ietf-httpbis-p7-auth-latest (work in progress),
1392               May 2014.
1393
1394NEW:
1395
1396    [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1397               Protocol (HTTP/1.1): Authentication", RFC 7235, May 2014.
1398
1399
1400Section 11.2., paragraph 25:
1401OLD:
1402
1403    [RFC7238]  Reschke, J., "The Hypertext Transfer Protocol (HTTP)
1404               Status Code 308 (Permanent Redirect)",
1405               draft-reschke-http-status-308-07 (work in progress),
1406               March 2012.
1407
1408NEW:
1409
1410    [RFC7238]  Reschke, J., "The Hypertext Transfer Protocol (HTTP)
1411               Status Code 308 (Permanent Redirect)", RFC 7238, May 2014.
1412
1413
1414Appendix A., paragraph 16:
1415OLD:
1416
1417 A.6.  MHTML and Line Length Limitations
1418
1419NEW:
1420
1421 A.6.  MHTML and Line-Length Limitations
1422
1423
1424Appendix A., paragraph 17:
1425OLD:
1426
1427    HTTP implementations that share code with MHTML [RFC2557]
1428    implementations need to be aware of MIME line length limitations.
1429    Since HTTP does not have this limitation, HTTP does not fold long
1430    lines.  MHTML messages being transported by HTTP follow all
1431    conventions of MHTML, including line length limitations and folding,
1432    canonicalization, etc., since HTTP transfers message-bodies as
1433    payload and, aside from the "multipart/byteranges" type (Appendix A
1434    of [RFC7233]), does not interpret the content or any MIME header
1435    lines that might be contained therein.
1436
1437NEW:
1438
1439    HTTP implementations that share code with MHTML [RFC2557]
1440    implementations need to be aware of MIME line-length limitations.
1441    Since HTTP does not have this limitation, HTTP does not fold long
1442    lines.  MHTML messages being transported by HTTP follow all
1443    conventions of MHTML, including line-length limitations and folding,
1444    canonicalization, etc., since HTTP transfers message-bodies as
1445    payload and, aside from the "multipart/byteranges" type (Appendix A
1446    of [RFC7233]), does not interpret the content or any MIME header
1447    lines that might be contained therein.
1448
1449
1450Appendix B., paragraph 2:
1451OLD:
1452
1453    A new requirement has been added that semantics embedded in a URI
1454    should be disabled when those semantics are inconsistent with the
1455    request method, since this is a common cause of interoperability
1456    failure.  (Section 2)
1457
1458NEW:
1459
1460    A new requirement has been added that semantics embedded in a URI be
1461    disabled when those semantics are inconsistent with the request
1462    method, since this is a common cause of interoperability failure
1463    (Section 2).
1464
1465
1466Appendix B., paragraph 3:
1467OLD:
1468
1469    An algorithm has been added for determining if a payload is
1470    associated with a specific identifier.  (Section 3.1.4.1)
1471
1472NEW:
1473
1474    An algorithm has been added for determining if a payload is
1475    associated with a specific identifier (Section 3.1.4.1).
1476
1477
1478Appendix B., paragraph 4:
1479OLD:
1480
1481    The default charset of ISO-8859-1 for text media types has been
1482    removed; the default is now whatever the media type definition says.
1483    Likewise, special treatment of ISO-8859-1 has been removed from the
1484    Accept-Charset header field.  (Section 3.1.1.3 and Section 5.3.3)
1485
1486NEW:
1487
1488    The default charset of ISO-8859-1 for text media types has been
1489    removed; the default is now whatever the media type definition says.
1490    Likewise, special treatment of ISO-8859-1 has been removed from the
1491    Accept-Charset header field.  (Sections 3.1.1.3 and 5.3.3.)
1492
1493
1494Appendix B., paragraph 5:
1495OLD:
1496
1497    The definition of Content-Location has been changed to no longer
1498    affect the base URI for resolving relative URI references, due to
1499    poor implementation support and the undesirable effect of potentially
1500    breaking relative links in content-negotiated resources.
1501    (Section 3.1.4.2)
1502
1503NEW:
1504
1505    The definition of Content-Location has been changed to no longer
1506    affect the base URI for resolving relative URI references, due to
1507    poor implementation support and the undesirable effect of potentially
1508    breaking relative links in content-negotiated resources
1509    (Section 3.1.4.2).
1510
1511
1512Appendix B., paragraph 6:
1513OLD:
1514
1515    To be consistent with the method-neutral parsing algorithm of
1516    [RFC7230], the definition of GET has been relaxed so that requests
1517    can have a body, even though a body has no meaning for GET.
1518    (Section 4.3.1)
1519
1520NEW:
1521
1522    To be consistent with the method-neutral parsing algorithm of
1523    [RFC7230], the definition of GET has been relaxed so that requests
1524    can have a body, even though a body has no meaning for GET
1525    (Section 4.3.1).
1526
1527
1528Appendix B., paragraph 7:
1529OLD:
1530
1531    Servers are no longer required to handle all Content-* header fields
1532    and use of Content-Range has been explicitly banned in PUT requests.
1533    (Section 4.3.4)
1534
1535NEW:
1536
1537    Servers are no longer required to handle all Content-* header fields
1538    and use of Content-Range has been explicitly banned in PUT requests
1539    (Section 4.3.4).
1540
1541
1542Appendix B., paragraph 8:
1543OLD:
1544
1545    Definition of the CONNECT method has been moved from [RFC2817] to
1546    this specification.  (Section 4.3.6)
1547
1548NEW:
1549
1550    Definition of the CONNECT method has been moved from [RFC2817] to
1551    this specification (Section 4.3.6).
1552
1553
1554Appendix B., paragraph 9:
1555OLD:
1556
1557    The OPTIONS and TRACE request methods have been defined as being
1558    safe.  (Section 4.3.7 and Section 4.3.8)
1559
1560NEW:
1561
1562    The OPTIONS and TRACE request methods have been defined as being safe
1563    (Section 4.3.7 and Section 4.3.8).
1564
1565
1566Appendix B., paragraph 10:
1567OLD:
1568
1569    The Expect header field's extension mechanism has been removed due to
1570    widely-deployed broken implementations.  (Section 5.1.1)
1571
1572NEW:
1573
1574    The Expect header field's extension mechanism has been removed due to
1575    widely deployed broken implementations (Section 5.1.1).
1576
1577
1578Appendix B., paragraph 11:
1579OLD:
1580
1581    The Max-Forwards header field has been restricted to the OPTIONS and
1582    TRACE methods; previously, extension methods could have used it as
1583    well.  (Section 5.1.2)
1584
1585NEW:
1586
1587    The Max-Forwards header field has been restricted to the OPTIONS and
1588    TRACE methods; previously, extension methods could have used it as
1589    well (Section 5.1.2).
1590
1591
1592Appendix B., paragraph 12:
1593OLD:
1594
1595    The "about:blank" URI has been suggested as a value for the Referer
1596    header field when no referring URI is applicable, which distinguishes
1597    that case from others where the Referer field is not sent or has been
1598    removed.  (Section 5.5.2)
1599
1600NEW:
1601
1602    The "about:blank" URI has been suggested as a value for the Referer
1603    header field when no referring URI is applicable, which distinguishes
1604    that case from others where the Referer field is not sent or has been
1605    removed (Section 5.5.2).
1606
1607
1608Appendix B., paragraph 13:
1609OLD:
1610
1611    The following status codes are now cacheable (that is, they can be
1612    stored and reused by a cache without explicit freshness information
1613    present): 204, 404, 405, 414, 501.  (Section 6)
1614
1615NEW:
1616
1617    The following status codes are now cacheable (that is, they can be
1618    stored and reused by a cache without explicit freshness information
1619    present): 204, 404, 405, 414, 501 (Section 6).
1620
1621
1622Appendix B., paragraph 14:
1623OLD:
1624
1625    The 201 (Created) status description has been changed to allow for
1626    the possibility that more than one resource has been created.
1627    (Section 6.3.2)
1628
1629NEW:
1630
1631    The 201 (Created) status description has been changed to allow for
1632    the possibility that more than one resource has been created
1633    (Section 6.3.2).
1634
1635
1636Appendix B., paragraph 15:
1637OLD:
1638
1639    The definition of 203 (Non-Authoritative Information) has been
1640    broadened to include cases of payload transformations as well.
1641    (Section 6.3.4)
1642
1643NEW:
1644
1645    The definition of 203 (Non-Authoritative Information) has been
1646    broadened to include cases of payload transformations as well
1647    (Section 6.3.4).
1648
1649
1650Appendix B., paragraph 16:
1651OLD:
1652
1653    The set of request methods that are safe to automatically redirect is
1654    no longer closed; user agents are able to make that determination
1655    based upon the request method semantics.  The redirect status codes
1656    301, 302, and 307 no longer have normative requirements on response
1657    payloads and user interaction.  (Section 6.4)
1658
1659NEW:
1660
1661    The set of request methods that are safe to automatically redirect is
1662    no longer closed; user agents are able to make that determination
1663    based upon the request method semantics.  The redirect status codes
1664    301, 302, and 307 no longer have normative requirements on response
1665    payloads and user interaction (Section 6.4).
1666
1667
1668Appendix B., paragraph 17:
1669OLD:
1670
1671    The status codes 301 and 302 have been changed to allow user agents
1672    to rewrite the method from POST to GET.  (Sections 6.4.2 and 6.4.3)
1673
1674NEW:
1675
1676    The status codes 301 and 302 have been changed to allow user agents
1677    to rewrite the method from POST to GET.  (Sections 6.4.2 and 6.4.3.)
1678
1679
1680Appendix B., paragraph 18:
1681OLD:
1682
1683    The description of 303 (See Other) status code has been changed to
1684    allow it to be cached if explicit freshness information is given, and
1685    a specific definition has been added for a 303 response to GET.
1686    (Section 6.4.4)
1687
1688NEW:
1689
1690    The description of the 303 (See Other) status code has been changed
1691    to allow it to be cached if explicit freshness information is given,
1692    and a specific definition has been added for a 303 response to GET
1693    (Section 6.4.4).
1694
1695
1696Appendix B., paragraph 19:
1697OLD:
1698
1699    The 305 (Use Proxy) status code has been deprecated due to security
1700    concerns regarding in-band configuration of a proxy.  (Section 6.4.5)
1701
1702NEW:
1703
1704    The 305 (Use Proxy) status code has been deprecated due to security
1705    concerns regarding in-band configuration of a proxy (Section 6.4.5).
1706
1707
1708Appendix B., paragraph 20:
1709OLD:
1710
1711    The 400 (Bad Request) status code has been relaxed so that it isn't
1712    limited to syntax errors.  (Section 6.5.1)
1713
1714NEW:
1715
1716    The 400 (Bad Request) status code has been relaxed so that it isn't
1717    limited to syntax errors (Section 6.5.1).
1718
1719
1720Appendix B., paragraph 21:
1721OLD:
1722
1723    The 426 (Upgrade Required) status code has been incorporated from
1724    [RFC2817].  (Section 6.5.15)
1725
1726NEW:
1727
1728    The 426 (Upgrade Required) status code has been incorporated from
1729    [RFC2817] (Section 6.5.15).
1730
1731
1732Appendix B., paragraph 22:
1733OLD:
1734
1735    The target of requirements on HTTP-date and the Date header field
1736    have been reduced to those systems generating the date, rather than
1737    all systems sending a date.  (Section 7.1.1)
1738
1739NEW:
1740
1741    The target of requirements on HTTP-date and the Date header field
1742    have been reduced to those systems generating the date, rather than
1743    all systems sending a date (Section 7.1.1).
1744
1745
1746Appendix B., paragraph 23:
1747OLD:
1748
1749    The syntax of the Location header field has been changed to allow all
1750    URI references, including relative references and fragments, along
1751    with some clarifications as to when use of fragments would not be
1752    appropriate.  (Section 7.1.2)
1753
1754NEW:
1755
1756    The syntax of the Location header field has been changed to allow all
1757    URI references, including relative references and fragments, along
1758    with some clarifications as to when use of fragments would not be
1759    appropriate (Section 7.1.2).
1760
1761
1762Appendix B., paragraph 24:
1763OLD:
1764
1765    Allow has been reclassified as a response header field, removing the
1766    option to specify it in a PUT request.  Requirements relating to the
1767    content of Allow have been relaxed; correspondingly, clients are not
1768    required to always trust its value.  (Section 7.4.1)
1769
1770NEW:
1771
1772    Allow has been reclassified as a response header field, removing the
1773    option to specify it in a PUT request.  Requirements relating to the
1774    content of Allow have been relaxed; correspondingly, clients are not
1775    required to always trust its value (Section 7.4.1).
1776
1777
1778Appendix B., paragraph 25:
1779OLD:
1780
1781    A Method Registry has been defined.  (Section 8.1)
1782
1783NEW:
1784
1785    A Method Registry has been defined (Section 8.1).
1786
1787
1788Appendix B., paragraph 26:
1789OLD:
1790
1791    The Status Code Registry has been redefined by this specification;
1792    previously, it was defined in Section 7.1 of [RFC2817].
1793 
1794    (Section 8.2)
1795
1796NEW:
1797
1798    The Status Code Registry has been redefined by this specification;
1799    previously, it was defined in Section 7.1 of [RFC2817] (Section 8.2).
1800
1801
1802Appendix B., paragraph 27:
1803OLD:
1804
1805    Registration of Content Codings has been changed to require IETF
1806    Review.  (Section 8.4)
1807
1808NEW:
1809
1810    Registration of content codings has been changed to require IETF
1811    Review (Section 8.4).
1812
1813
1814Section 1.2, paragraph 1:
1815OLD:
1816
1817    Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
1818     OWS ( media-range [ accept-params ] ) ] ) ]
1819    Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS
1820     "," [ OWS ( ( charset / "*" ) [ weight ] ) ] )
1821    Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS
1822     ( codings [ weight ] ) ] ) ]
1823    Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS
1824     "," [ OWS ( language-range [ weight ] ) ] )
1825    Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ]
1826    BWS = <BWS, defined in [RFC7230], Section 3.2.3>
1827
1828NEW:
1829
1830    Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
1831     OWS ( media-range [ accept-params ] ) ] ) ]
1832    Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS
1833     "," [ OWS ( ( charset / "*" ) [ weight ] ) ] )
1834    Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS
1835     ( codings [ weight ] ) ] ) ]
1836    Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS
1837     "," [ OWS ( language-range [ weight ] ) ] )
1838    Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ]
1839 
1840    BWS = <BWS, defined in [RFC7230], Section 3.2.3>
1841
1842
1843Section 1.2, paragraph 2:
1844OLD:
1845
1846    Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS
1847     content-coding ] )
1848    Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS
1849     language-tag ] )
1850    Content-Location = absolute-URI / partial-URI
1851    Content-Type = media-type
1852 
1853    Date = HTTP-date
1854
1855NEW:
1856
1857    Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS
1858     content-coding ] )
1859    Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS
1860     language-tag ] )
1861    Content-Location = absolute-URI / partial-URI
1862    Content-Type = media-type
1863    Date = HTTP-date
1864
1865
1866Section 1.2, paragraph 16:
1867OLD:
1868
1869    charset = token
1870    codings = content-coding / "identity" / "*"
1871    comment = <comment, defined in [RFC7230], Section 3.2.6>
1872    content-coding = token
1873    date1 = day SP month SP year
1874    date2 = day "-" month "-" 2DIGIT
1875    date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
1876    day = 2DIGIT
1877    day-name = %x4D.6F.6E ; Mon
1878     / %x54.75.65 ; Tue
1879     / %x57.65.64 ; Wed
1880     / %x54.68.75 ; Thu
1881     / %x46.72.69 ; Fri
1882     / %x53.61.74 ; Sat
1883     / %x53.75.6E ; Sun
1884    day-name-l = %x4D.6F.6E.64.61.79 ; Monday
1885     / %x54.75.65.73.64.61.79 ; Tuesday
1886     / %x57.65.64.6E.65.73.64.61.79 ; Wednesday
1887     / %x54.68.75.72.73.64.61.79 ; Thursday
1888     / %x46.72.69.64.61.79 ; Friday
1889     / %x53.61.74.75.72.64.61.79 ; Saturday
1890     / %x53.75.6E.64.61.79 ; Sunday
1891    delay-seconds = 1*DIGIT
1892
1893NEW:
1894
1895    charset = token
1896    codings = content-coding / "identity" / "*"
1897    comment = <comment, defined in [RFC7230], Section 3.2.6>
1898    content-coding = token
1899 
1900    date1 = day SP month SP year
1901    date2 = day "-" month "-" 2DIGIT
1902    date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
1903    day = 2DIGIT
1904    day-name = %x4D.6F.6E ; Mon
1905     / %x54.75.65 ; Tue
1906     / %x57.65.64 ; Wed
1907     / %x54.68.75 ; Thu
1908     / %x46.72.69 ; Fri
1909     / %x53.61.74 ; Sat
1910     / %x53.75.6E ; Sun
1911    day-name-l = %x4D.6F.6E.64.61.79 ; Monday
1912     / %x54.75.65.73.64.61.79 ; Tuesday
1913     / %x57.65.64.6E.65.73.64.61.79 ; Wednesday
1914     / %x54.68.75.72.73.64.61.79 ; Thursday
1915     / %x46.72.69.64.61.79 ; Friday
1916     / %x53.61.74.75.72.64.61.79 ; Saturday
1917     / %x53.75.6E.64.61.79 ; Sunday
1918    delay-seconds = 1*DIGIT
1919
1920
1921Section 1.2, paragraph 21:
1922OLD:
1923
1924    obs-date = rfc850-date / asctime-date
1925    parameter = token "=" ( token / quoted-string )
1926    partial-URI = <partial-URI, defined in [RFC7230], Section 2.7>
1927    product = token [ "/" product-version ]
1928    product-version = token
1929 
1930    quoted-string = <quoted-string, defined in [RFC7230], Section 3.2.6>
1931    qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
1932
1933NEW:
1934
1935    obs-date = rfc850-date / asctime-date
1936 
1937    parameter = token "=" ( token / quoted-string )
1938    partial-URI = <partial-URI, defined in [RFC7230], Section 2.7>
1939    product = token [ "/" product-version ]
1940    product-version = token
1941    quoted-string = <quoted-string, defined in [RFC7230], Section 3.2.6>
1942    qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
1943
1944
1945Section 1.2, paragraph 47:
1946OLD:
1947
1948    M
1949       Max-Forwards header field  36
1950       MIME-Version header field  89
1951
1952NEW:
1953
1954    M
1955       Max-Forwards header field  36
1956       MIME-Version header field  88
1957
1958
1959Section 345, paragraph 1:
1960OLD:
1961
1962    EMail: fielding@gbiv.com
1963    URI:   http://roy.gbiv.com/
1964    Julian F. Reschke (editor)
1965    greenbytes GmbH
1966    Hafenweg 16
1967    Muenster, NW  48155
1968    Germany
1969
1970NEW:
1971
1972    EMail: fielding@gbiv.com
1973    URI:   http://roy.gbiv.com/
1974 
1975    Julian F. Reschke (editor)
1976    greenbytes GmbH
1977    Hafenweg 16
1978    Muenster, NW  48155
1979    Germany
1980
Note: See TracBrowser for help on using the repository browser.