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

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

registry names (see #553)

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