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

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

expand a few status code mentions (#553)

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