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

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

min. fixes (reg names, punctuation, etc) (see #553)

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