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

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

consistently say "US-ASCII" (#553)

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