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

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

"3" -> "three", "5" -> "five" (#553)

File size: 95.8 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 6, 2014
10 Expires: November 7, 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 7, 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 1., paragraph 1:
390OLD:
391
392    Each Hypertext Transfer Protocol (HTTP) message is either a request
393    or a response.  A server listens on a connection for a request,
394    parses each message received, interprets the message semantics in
395    relation to the identified request target, and responds to that
396    request with one or more response messages.  A client constructs
397    request messages to communicate specific intentions, and examines
398    received responses to see if the intentions were carried out, and
399    determine how to interpret the results.  This document defines
400    HTTP/1.1 request and response semantics in terms of the architecture
401    defined in [RFC7230].
402
403NEW:
404
405    Each Hypertext Transfer Protocol (HTTP) message is either a request
406    or a response.  A server listens on a connection for a request,
407    parses each message received, interprets the message semantics in
408    relation to the identified request target, and responds to that
409    request with one or more response messages.  A client constructs
410    request messages to communicate specific intentions, examines
411    received responses to see if the intentions were carried out, and
412    determines how to interpret the results.  This document defines
413    HTTP/1.1 request and response semantics in terms of the architecture
414    defined in [RFC7230].
415
416
417Section 2., paragraph 1:
418OLD:
419
420    The target of an HTTP request is called a resource.  HTTP does not
421    limit the nature of a resource; it merely defines an interface that
422    might be used to interact with resources.  Each resource is
423    identified by a Uniform Resource Identifier (URI), as described in
424    Section 2.7 of [RFC7230].
425
426NEW:
427
428    The target of an HTTP request is called a "resource".  HTTP does not
429    limit the nature of a resource; it merely defines an interface that
430    might be used to interact with resources.  Each resource is
431    identified by a Uniform Resource Identifier (URI), as described in
432    Section 2.7 of [RFC7230].
433
434
435Section 3., paragraph 3:
436OLD:
437
438    An origin server might be provided with, or capable of generating,
439    multiple representations that are each intended to reflect the
440    current state of a target resource.  In such cases, some algorithm is
441    used by the origin server to select one of those representations as
442    most applicable to a given request, usually based on content
443    negotiation.  This "selected representation" is used to provide the
444    data and metadata for evaluating conditional requests [RFC7232] and
445    constructing the payload for 200 (OK) and 304 (Not Modified)
446    responses to GET (Section 4.3.1).
447
448NEW:
449
450    An origin server might be provided with, or be capable of generating,
451    multiple representations that are each intended to reflect the
452    current state of a target resource.  In such cases, some algorithm is
453    used by the origin server to select one of those representations as
454    most applicable to a given request, usually based on content
455    negotiation.  This "selected representation" is used to provide the
456    data and metadata for evaluating conditional requests [RFC7232] and
457    constructing the payload for 200 (OK) and 304 (Not Modified)
458    responses to GET (Section 4.3.1).
459
460
461Section 3.1.1.1., paragraph 1:
462OLD:
463
464    HTTP uses Internet Media Types [RFC2046] in the Content-Type
465    (Section 3.1.1.5) and Accept (Section 5.3.2) header fields in order
466    to provide open and extensible data typing and type negotiation.
467    Media types define both a data format and various processing models:
468    how to process that data in accordance with each context in which it
469    is received.
470
471NEW:
472
473    HTTP uses Internet media types [RFC2046] in the Content-Type
474    (Section 3.1.1.5) and Accept (Section 5.3.2) header fields in order
475    to provide open and extensible data typing and type negotiation.
476    Media types define both a data format and various processing models:
477    how to process that data in accordance with each context in which it
478    is received.
479
480
481Section 3.1.1.1., paragraph 5:
482OLD:
483
484    The type, subtype, and parameter name tokens are case-insensitive.
485    Parameter values might or might not be case-sensitive, depending on
486    the semantics of the parameter name.  The presence or absence of a
487    parameter might be significant to the processing of a media-type,
488    depending on its definition within the media type registry.
489
490NEW:
491
492    The type, subtype, and parameter name tokens are case insensitive.
493    Parameter values might or might not be case sensitive, depending on
494    the semantics of the parameter name.  The presence or absence of a
495    parameter might be significant to the processing of a media-type,
496    depending on its definition within the media type registry.
497
498
499Section 3.1.1.1., paragraph 6:
500OLD:
501
502    A parameter value that matches the token production can be
503    transmitted as either a token or within a quoted-string.  The quoted
504    and unquoted values are equivalent.  For example, the following
505    examples are all equivalent, but the first is preferred for
506    consistency:
507
508NEW:
509
510    A parameter value that matches the token production can be
511    transmitted either as a token or within a quoted-string.  The quoted
512    and unquoted values are equivalent.  For example, the following
513    examples are all equivalent, but the first is preferred for
514    consistency:
515
516
517Section 3.1.1.2., paragraph 3:
518OLD:
519
520    Charset names ought to be registered in IANA Character Set registry
521    (<http://www.iana.org/assignments/character-sets>) according to the
522    procedures defined in [RFC2978].
523
524NEW:
525
526    Charset names ought to be registered in the IANA "Character Sets"
527    registry <http://www.iana.org/assignments/character-sets> according
528    to the procedures defined in [RFC2978].
529
530
531Section 3.1.1.3., paragraph 2:
532OLD:
533
534    MIME's canonical form requires that media subtypes of the "text" type
535    use CRLF as the text line break.  HTTP allows the transfer of text
536    media with plain CR or LF alone representing a line break, when such
537    line breaks are consistent for an entire representation.  An HTTP
538    sender MAY generate, and a recipient MUST be able to parse, line
539    breaks in text media that consist of CRLF, bare CR, or bare LF.  In
540    addition, text media in HTTP is not limited to charsets that use
541    octets 13 and 10 for CR and LF, respectively.  This flexibility
542    regarding line breaks applies only to text within a representation
543    that has been assigned a "text" media type; it does not apply to
544    "multipart" types or HTTP elements outside the payload body (e.g.,
545    header fields).
546
547NEW:
548
549    MIME's canonical form requires that media subtypes of the "text" type
550    use CRLF as the text line break.  HTTP allows the transfer of text
551    media with plain carriage return (CR) or line feed (LF) alone
552    representing a line break, when such line breaks are consistent for
553    an entire representation.  An HTTP sender MAY generate, and a
554    recipient MUST be able to parse, line breaks in text media that
555    consist of CRLF, bare CR, or bare LF.  In addition, text media in
556    HTTP is not limited to charsets that use octets 13 and 10 for CR and
557    LF, respectively.  This flexibility regarding line breaks applies
558    only to text within a representation that has been assigned a "text"
559    media type; it does not apply to "multipart" types or HTTP elements
560    outside the payload body (e.g., header fields).
561
562
563Section 3.1.2.1., paragraph 3:
564OLD:
565
566    All content-coding values are case-insensitive and ought to be
567    registered within the HTTP Content Coding registry, as defined in
568    Section 8.4.  They are used in the Accept-Encoding (Section 5.3.4)
569    and Content-Encoding (Section 3.1.2.2) header fields.
570
571NEW:
572
573    All content-coding values are case insensitive and ought to be
574    registered within the "HTTP Content Coding Registry", as defined in
575    Section 8.4.  They are used in the Accept-Encoding (Section 5.3.4)
576    and Content-Encoding (Section 3.1.2.2) header fields.
577
578
579Section 3.1.3.2., paragraph 5:
580OLD:
581
582    If no Content-Language is specified, the default is that the content
583    is intended for all language audiences.  This might mean that the
584    sender does not consider it to be specific to any natural language,
585    or that the sender does not know for which language it is intended.
586
587NEW:
588
589    If no Content-Language is specified, the default is that the content
590    is intended for all language audiences.  This might mean that the
591    sender does not consider it to be specific to any natural language,
592    or that the sender does not know which language is being used.
593
594
595Section 3.4.1., paragraph 2:
596OLD:
597
598    Proactive negotiation is advantageous when the algorithm for
599    selecting from among the available representations is difficult to
600    describe to a user agent, or when the server desires to send its
601    "best guess" to the user agent along with the first response (hoping
602    to avoid the round trip delay of a subsequent request if the "best
603    guess" is good enough for the user).  In order to improve the
604    server's guess, a user agent MAY send request header fields that
605    describe its preferences.
606
607NEW:
608
609    Proactive negotiation is advantageous when the algorithm for
610    selecting from among the available representations is difficult to
611    describe to a user agent, or when the server desires to send its
612    "best guess" to the user agent along with the first response (hoping
613    to avoid the round-trip delay of a subsequent request if the "best
614    guess" is good enough for the user).  In order to improve the
615    server's guess, a user agent MAY send request header fields that
616    describe its preferences.
617
618
619Section 406, paragraph 1:
620OLD:
621
622    Reactive negotiation is advantageous when the response would vary
623    over commonly-used dimensions (such as type, language, or encoding),
624    when the origin server is unable to determine a user agent's
625    capabilities from examining the request, and generally when public
626    caches are used to distribute server load and reduce network usage.
627
628NEW:
629
630    Reactive negotiation is advantageous when the response would vary
631    over commonly used dimensions (such as type, language, or encoding),
632    when the origin server is unable to determine a user agent's
633    capabilities from examining the request, and generally when public
634    caches are used to distribute server load and reduce network usage.
635
636
637Section 4.1., paragraph 4:
638OLD:
639
640    HTTP was originally designed to be usable as an interface to
641    distributed object systems.  The request method was envisioned as
642    applying semantics to a target resource in much the same way as
643    invoking a defined method on an identified object would apply
644    semantics.  The method token is case-sensitive because it might be
645    used as a gateway to object-based systems with case-sensitive method
646    names.
647
648NEW:
649
650    HTTP was originally designed to be usable as an interface to
651    distributed object systems.  The request method was envisioned as
652    applying semantics to a target resource in much the same way as
653    invoking a defined method on an identified object would apply
654    semantics.  The method token is case sensitive because it might be
655    used as a gateway to object-based systems with case-sensitive method
656    names.
657
658
659Section 4.1., paragraph 5:
660OLD:
661
662    Unlike distributed objects, the standardized request methods in HTTP
663    are not resource-specific, since uniform interfaces provide for
664    better visibility and reuse in network-based systems [REST].  Once
665    defined, a standardized method ought to have the same semantics when
666    applied to any resource, though each resource determines for itself
667    whether those semantics are implemented or allowed.
668
669NEW:
670
671    Unlike distributed objects, the standardized request methods in HTTP
672    are not resource specific, since uniform interfaces provide for
673    better visibility and reuse in network-based systems [REST].  Once
674    defined, a standardized method ought to have the same semantics when
675    applied to any resource, though each resource determines for itself
676    whether those semantics are implemented or allowed.
677
678
679Section 4.1., paragraph 9:
680OLD:
681
682    Additional methods, outside the scope of this specification, have
683    been standardized for use in HTTP.  All such methods ought to be
684    registered within the HTTP Method Registry maintained by IANA, as
685    defined in Section 8.1.
686
687NEW:
688
689    Additional methods, outside the scope of this specification, have
690    been standardized for use in HTTP.  All such methods ought to be
691    registered within the "Hypertext Transfer Protocol (HTTP) Method"
692    registry maintained by IANA, as defined in Section 8.1.
693
694
695Section 4.2.1., paragraph 2:
696OLD:
697
698    This definition of safe methods does not prevent an implementation
699    from including behavior that is potentially harmful, not entirely
700    read-only, or which causes side-effects while invoking a safe method.
701    What is important, however, is that the client did not request that
702    additional behavior and cannot be held accountable for it.  For
703    example, most servers append request information to access log files
704    at the completion of every response, regardless of the method, and
705    that is considered safe even though the log storage might become full
706    and crash the server.  Likewise, a safe request initiated by
707    selecting an advertisement on the Web will often have the side-effect
708    of charging an advertising account.
709
710NEW:
711
712    This definition of safe method does not prevent an implementation
713    from including behavior that is potentially harmful, that is not
714    entirely read-only, or that causes side effects while invoking a safe
715    method.  What is important, however, is that the client did not
716    request that additional behavior and cannot be held accountable for
717    it.  For example, most servers append request information to access
718    log files at the completion of every response, regardless of the
719    method, and that is considered safe even though the log storage might
720    become full and crash the server.  Likewise, a safe request initiated
721    by selecting an advertisement on the Web will often have the side
722    effect of charging an advertising account.
723
724
725Section 4.2.1., paragraph 6:
726OLD:
727
728    When a resource is constructed such that parameters within the
729    effective request URI have the effect of selecting an action, it is
730    the resource owner's responsibility to ensure that the action is
731    consistent with the request method semantics.  For example, it is
732    common for Web-based content editing software to use actions within
733    query parameters, such as "page?do=delete".  If the purpose of such a
734    resource is to perform an unsafe action, then the resource owner MUST
735    disable or disallow that action when it is accessed using a safe
736    request method.  Failure to do so will result in unfortunate side-
737    effects when automated processes perform a GET on every URI reference
738    for the sake of link maintenance, pre-fetching, building a search
739    index, etc.
740
741NEW:
742
743    When a resource is constructed such that parameters within the
744    effective request URI have the effect of selecting an action, it is
745    the resource owner's responsibility to ensure that the action is
746    consistent with the request method semantics.  For example, it is
747    common for Web-based content editing software to use actions within
748    query parameters, such as "page?do=delete".  If the purpose of such a
749    resource is to perform an unsafe action, then the resource owner MUST
750    disable or disallow that action when it is accessed using a safe
751    request method.  Failure to do so will result in unfortunate side
752    effects when automated processes perform a GET on every URI reference
753    for the sake of link maintenance, pre-fetching, building a search
754    index, etc.
755
756
757Section 4.2.2., paragraph 2:
758OLD:
759
760    Like the definition of safe, the idempotent property only applies to
761    what has been requested by the user; a server is free to log each
762    request separately, retain a revision control history, or implement
763    other non-idempotent side-effects for each idempotent request.
764
765NEW:
766
767    Like the definition of safe, the idempotent property only applies to
768    what has been requested by the user; a server is free to log each
769    request separately, retain a revision control history, or implement
770    other non-idempotent side effects for each idempotent request.
771
772
773Section 4.3.3., paragraph 6:
774OLD:
775
776    An origin server indicates response semantics by choosing an
777    appropriate status code depending on the result of processing the
778    POST request; almost all of the status codes defined by this
779    specification might be received in a response to POST (the exceptions
780    being 206, 304, and 416).
781
782NEW:
783
784    An origin server indicates response semantics by choosing an
785    appropriate status code depending on the result of processing the
786    POST request; almost all of the status codes defined by this
787    specification might be received in a response to POST (the exceptions
788    being 206 (Partial Content), 304 (Not Modified), and 416 (Range Not
789    Satisfiable)).
790
791
792Section 4.3.4., paragraph 10:
793OLD:
794
795    An origin server MUST NOT send a validator header field
796    (Section 7.2), such as an ETag or Last-Modified field, in a
797    successful response to PUT unless the request's representation data
798    was saved without any transformation applied to the body (i.e., the
799    resource's new representation data is identical to the representation
800    data received in the PUT request) and the validator field value
801    reflects the new representation.  This requirement allows a user
802    agent to know when the representation body it has in memory remains
803    current as a result of the PUT, thus not in need of retrieving again
804    from the origin server, and that the new validator(s) received in the
805    response can be used for future conditional requests in order to
806    prevent accidental overwrites (Section 5.2).
807
808NEW:
809
810    An origin server MUST NOT send a validator header field
811    (Section 7.2), such as an ETag or Last-Modified field, in a
812    successful response to PUT unless the request's representation data
813    was saved without any transformation applied to the body (i.e., the
814    resource's new representation data is identical to the representation
815    data received in the PUT request) and the validator field value
816    reflects the new representation.  This requirement allows a user
817    agent to know when the representation body it has in memory remains
818    current as a result of the PUT, thus not in need of being retrieved
819    again from the origin server, and that the new validator(s) received
820    in the response can be used for future conditional requests in order
821    to prevent accidental overwrites (Section 5.2).
822
823
824Section 4.3.4., paragraph 13:
825OLD:
826
827    A PUT request applied to the target resource can have side-effects on
828    other resources.  For example, an article might have a URI for
829    identifying "the current version" (a resource) that is separate from
830    the URIs identifying each particular version (different resources
831    that at one point shared the same state as the current version
832    resource).  A successful PUT request on "the current version" URI
833    might therefore create a new version resource in addition to changing
834    the state of the target resource, and might also cause links to be
835    added between the related resources.
836
837NEW:
838
839    A PUT request applied to the target resource can have side effects on
840    other resources.  For example, an article might have a URI for
841    identifying "the current version" (a resource) that is separate from
842    the URIs identifying each particular version (different resources
843    that at one point shared the same state as the current version
844    resource).  A successful PUT request on "the current version" URI
845    might therefore create a new version resource in addition to changing
846    the state of the target resource, and might also cause links to be
847    added between the related resources.
848
849
850Section 4.3.6., paragraph 2:
851OLD:
852
853    CONNECT is intended only for use in requests to a proxy.  An origin
854    server that receives a CONNECT request for itself MAY respond with a
855    2xx status code to indicate that a connection is established.
856    However, most origin servers do not implement CONNECT.
857
858NEW:
859
860    CONNECT is intended only for use in requests to a proxy.  An origin
861    server that receives a CONNECT request for itself MAY respond with a
862    2xx (Successful) status code to indicate that a connection is
863    established.  However, most origin servers do not implement CONNECT.
864
865
866Section 4.3.7., paragraph 1:
867OLD:
868
869    The OPTIONS method requests information about the communication
870    options available for the target resource, either at the origin
871    server or an intervening intermediary.  This method allows a client
872    to determine the options and/or requirements associated with a
873    resource, or the capabilities of a server, without implying a
874    resource action.
875
876NEW:
877
878    The OPTIONS method requests information about the communication
879    options available for the target resource, at either the origin
880    server or an intervening intermediary.  This method allows a client
881    to determine the options and/or requirements associated with a
882    resource, or the capabilities of a server, without implying a
883    resource action.
884
885
886Section 4.3.8., paragraph 2:
887OLD:
888
889    A client MUST NOT generate header fields in a TRACE request
890    containing sensitive data that might be disclosed by the response.
891 
892    For example, it would be foolish for a user agent to send stored user
893    credentials [RFC7235] or cookies [RFC6265] in a TRACE request.  The
894    final recipient of the request SHOULD exclude any request header
895    fields that are likely to contain sensitive data when that recipient
896    generates the response body.
897
898NEW:
899
900    A client MUST NOT generate header fields in a TRACE request
901    containing sensitive data that might be disclosed by the response.
902    For example, it would be foolish for a user agent to send stored user
903    credentials [RFC7235] or cookies [RFC6265] in a TRACE request.  The
904    final recipient of the request SHOULD exclude any request header
905    fields that are likely to contain sensitive data when that recipient
906    generates the response body.
907
908
909Section 5.1.1., paragraph 3:
910OLD:
911
912    The Expect field-value is case-insensitive.
913
914NEW:
915
916    The Expect field-value is case insensitive.
917
918
919Section 5.1.1., paragraph 21:
920OLD:
921
922       Note: The Expect header field was added after the original
923       publication of HTTP/1.1 [RFC2068] as both the means to request an
924       interim 100 response and the general mechanism for indicating
925       must-understand extensions.  However, the extension mechanism has
926       not been used by clients and the must-understand requirements have
927       not been implemented by many servers, rendering the extension
928       mechanism useless.  This specification has removed the extension
929       mechanism in order to simplify the definition and processing of
930       100-continue.
931
932NEW:
933
934       Note: The Expect header field was added after the original
935       publication of HTTP/1.1 [RFC2068] as both the means to request an
936       interim 100 (Continue) response and the general mechanism for
937       indicating must-understand extensions.  However, the extension
938       mechanism has not been used by clients and the must-understand
939       requirements have not been implemented by many servers, rendering
940       the extension mechanism useless.  This specification has removed
941       the extension mechanism in order to simplify the definition and
942       processing of 100-continue.
943
944
945Section 5.3.2., paragraph 9:
946OLD:
947
948    is interpreted as "I prefer audio/basic, but send me any audio type
949    if it is the best available after an 80% mark-down in quality".
950
951NEW:
952
953    is interpreted as "I prefer audio/basic, but send me any audio type
954    if it is the best available after an 80% markdown in quality".
955
956
957Section 5.5.1., paragraph 1:
958OLD:
959
960    The "From" header field contains an Internet email address for a
961    human user who controls the requesting user agent.  The address ought
962    to be machine-usable, as defined by "mailbox" in Section 3.4 of
963    [RFC5322]:
964
965NEW:
966
967    The "From" header field contains an Internet email address for a
968    human user who controls the requesting user agent.  The address ought
969    to be machine usable, as defined by "mailbox" in Section 3.4 of
970    [RFC5322]:
971
972
973Section 5.5.2., paragraph 6:
974OLD:
975
976    If the target URI was obtained from a source that does not have its
977    own URI (e.g., input from the user keyboard, or an entry within the
978    user's bookmarks/favorites), the user agent MUST either exclude
979    Referer or send it with a value of "about:blank".
980
981NEW:
982
983    If the target URI was obtained from a source that does not have its
984    own URI (e.g., input from the user keyboard, or an entry within the
985    user's bookmarks/favorites), the user agent MUST either exclude the
986    Referer or send it with a value of "about:blank".
987
988
989Section 5.5.2., paragraph 8:
990OLD:
991
992    Some intermediaries have been known to indiscriminately remove
993    Referer header fields from outgoing requests.  This has the
994    unfortunate side-effect of interfering with protection against CSRF
995    attacks, which can be far more harmful to their users.
996    Intermediaries and user agent extensions that wish to limit
997    information disclosure in Referer ought to restrict their changes to
998    specific edits, such as replacing internal domain names with
999    pseudonyms or truncating the query and/or path components.  An
1000    intermediary SHOULD NOT modify or delete the Referer header field
1001    when the field value shares the same scheme and host as the request
1002    target.
1003
1004NEW:
1005
1006    Some intermediaries have been known to indiscriminately remove
1007    Referer header fields from outgoing requests.  This has the
1008    unfortunate side effect of interfering with protection against CSRF
1009    attacks, which can be far more harmful to their users.
1010    Intermediaries and user agent extensions that wish to limit
1011    information disclosure in Referer ought to restrict their changes to
1012    specific edits, such as replacing internal domain names with
1013    pseudonyms or truncating the query and/or path components.  An
1014    intermediary SHOULD NOT modify or delete the Referer header field
1015    when the field value shares the same scheme and host as the request
1016    target.
1017
1018
1019Section 5.5.3., paragraph 1:
1020OLD:
1021
1022    The "User-Agent" header field contains information about the user
1023    agent originating the request, which is often used by servers to help
1024    identify the scope of reported interoperability problems, to work
1025    around or tailor responses to avoid particular user agent
1026    limitations, and for analytics regarding browser or operating system
1027    use.  A user agent SHOULD send a User-Agent field in each request
1028    unless specifically configured not to do so.
1029
1030NEW:
1031
1032    The "User-Agent" header field contains information about the user
1033    agent originating the request, which is often used by servers to help
1034    identify the scope of reported interoperability problems, to work
1035    around or tailor responses to avoid particular user-agent
1036    limitations, and for analytics regarding browser or operating system
1037    use.  A user agent SHOULD send a User-Agent field in each request
1038    unless specifically configured not to do so.
1039
1040
1041Section 5.5.3., paragraph 3:
1042OLD:
1043
1044    The User-Agent field-value consists of one or more product
1045    identifiers, each followed by zero or more comments (Section 3.2 of
1046    [RFC7230]), which together identify the user agent software and its
1047    significant subproducts.  By convention, the product identifiers are
1048    listed in decreasing order of their significance for identifying the
1049    user agent software.  Each product identifier consists of a name and
1050    optional version.
1051
1052NEW:
1053
1054    The User-Agent field-value consists of one or more product
1055    identifiers, each followed by zero or more comments (Section 3.2 of
1056    [RFC7230]), which together identify the user-agent software and its
1057    significant subproducts.  By convention, the product identifiers are
1058    listed in decreasing order of their significance for identifying the
1059    user-agent software.  Each product identifier consists of a name and
1060    optional version.
1061
1062
1063Section 5.5.3., paragraph 5:
1064OLD:
1065
1066    A sender SHOULD limit generated product identifiers to what is
1067    necessary to identify the product; a sender MUST NOT generate
1068    advertising or other non-essential information within the product
1069    identifier.  A sender SHOULD NOT generate information in product-
1070    version that is not a version identifier (i.e., successive versions
1071    of the same product name ought to only differ in the product-version
1072    portion of the product identifier).
1073
1074NEW:
1075
1076    A sender SHOULD limit generated product identifiers to what is
1077    necessary to identify the product; a sender MUST NOT generate
1078    advertising or other nonessential information within the product
1079    identifier.  A sender SHOULD NOT generate information in product-
1080    version that is not a version identifier (i.e., successive versions
1081    of the same product name ought only to differ in the product-version
1082    portion of the product identifier).
1083
1084
1085Section 5.5.3., paragraph 9:
1086OLD:
1087
1088    Likewise, implementations are encouraged not to use the product
1089    tokens of other implementations in order to declare compatibility
1090    with them, as this circumvents the purpose of the field.  If a user
1091    agent masquerades as a different user agent, recipients can assume
1092    that the user intentionally desires to see responses tailored for
1093    that identified user agent, even if they might not work as well for
1094    the actual user agent being used.
1095
1096NEW:
1097
1098    Likewise, implementations are encouraged not to use the product
1099    tokens of other implementations in order to declare compatibility
1100    with them, as this circumvents the purpose of the field.  If a user
1101    agent masquerades as a different user agent, recipients can assume
1102    that the user intentionally desires to see responses tailored for
1103    that identified user agent, even if they might not work as well for
1104    the actual user agent being implemented.
1105
1106
1107Section 6., paragraph 3:
1108OLD:
1109
1110    For example, if an unrecognized status code of 471 is received by a
1111    client, the client can assume that there was something wrong with its
1112    request and treat the response as if it had received a 400 status
1113    code.  The response message will usually contain a representation
1114    that explains the status.
1115
1116NEW:
1117
1118    For example, if an unrecognized status code of 471 is received by a
1119    client, the client can assume that there was something wrong with its
1120    request and treat the response as if it had received a 400 (Bad
1121    Request) status code.  The response message will usually contain a
1122    representation that explains the status.
1123
1124
1125Section 6.1., paragraph 2:
1126OLD:
1127
1128    Responses with status codes that are defined as cacheable by default
1129    (e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501 in this
1130    specification) can be reused by a cache with heuristic expiration
1131    unless otherwise indicated by the method definition or explicit cache
1132    controls [RFC7234]; all other status codes are not cacheable by
1133    default.
1134
1135NEW:
1136
1137    Responses with status codes that are defined as cacheable by default
1138    (e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501 in
1139    this specification) can be reused by a cache with heuristic
1140    expiration unless otherwise indicated by the method definition or
1141    explicit cache controls [RFC7234]; all other status codes are not
1142    cacheable by default.
1143
1144
1145Section 6.3.3., paragraph 2:
1146OLD:
1147
1148    The 202 response is intentionally non-committal.  Its purpose is to
1149    allow a server to accept a request for some other process (perhaps a
1150    batch-oriented process that is only run once per day) without
1151    requiring that the user agent's connection to the server persist
1152    until the process is completed.  The representation sent with this
1153    response ought to describe the request's current status and point to
1154    (or embed) a status monitor that can provide the user with an
1155    estimate of when the request will be fulfilled.
1156
1157NEW:
1158
1159    The 202 response is intentionally noncommittal.  Its purpose is to
1160    allow a server to accept a request for some other process (perhaps a
1161    batch-oriented process that is only run once per day) without
1162    requiring that the user agent's connection to the server persist
1163    until the process is completed.  The representation sent with this
1164    response ought to describe the request's current status and point to
1165    (or embed) a status monitor that can provide the user with an
1166    estimate of when the request will be fulfilled.
1167
1168
1169Section 6.4.1., paragraph 5:
1170OLD:
1171
1172       Note: The original proposal for 300 defined the URI header field
1173       as providing a list of alternative representations, such that it
1174       would be usable for 200, 300, and 406 responses and be transferred
1175       in responses to the HEAD method.  However, lack of deployment and
1176       disagreement over syntax led to both URI and Alternates (a
1177       subsequent proposal) being dropped from this specification.  It is
1178       possible to communicate the list using a set of Link header fields
1179       [RFC5988], each with a relationship of "alternate", though
1180       deployment is a chicken-and-egg problem.
1181
1182NEW:
1183
1184       Note: The original proposal for the 300 response defined the URI
1185       header field as providing a list of alternative representations,
1186       such that it would be usable for 200, 300, and 406 responses and
1187       be transferred in responses to the HEAD method.  However, lack of
1188       deployment and disagreement over syntax led to both URI and
1189       Alternates (a subsequent proposal) being dropped from this
1190       specification.  It is possible to communicate the list using a set
1191       of Link header fields [RFC5988], each with a relationship of
1192       "alternate", though deployment is a chicken-and-egg problem.
1193
1194
1195Section 6.4.2., paragraph 1:
1196OLD:
1197
1198    The 301 (Moved Permanently) status code indicates that the target
1199    resource has been assigned a new permanent URI and any future
1200    references to this resource ought to use one of the enclosed URIs.
1201    Clients with link editing capabilities ought to automatically re-link
1202    references to the effective request URI to one or more of the new
1203    references sent by the server, where possible.
1204
1205NEW:
1206
1207    The 301 (Moved Permanently) status code indicates that the target
1208    resource has been assigned a new permanent URI and any future
1209    references to this resource ought to use one of the enclosed URIs.
1210    Clients with link-editing capabilities ought to automatically re-link
1211    references to the effective request URI to one or more of the new
1212    references sent by the server, where possible.
1213
1214
1215Section 6.4.7., paragraph 3:
1216OLD:
1217
1218       Note: This status code is similar to 302 (Found), except that it
1219       does not allow changing the request method from POST to GET.  This
1220       specification defines no equivalent counterpart for 301 (Moved
1221       Permanently) ([RFC7238], however, defines the status code 308
1222       (Permanent Redirect) for this purpose).
1223
1224NEW:
1225
1226       Note: This status code is similar to 302 (Found), except that it
1227       does not allow changing the request method from POST to GET.  This
1228       specification defines no equivalent counterpart for 301 (Moved
1229       Permanently) ([RFC7238]; however, it defines the status code 308
1230       (Permanent Redirect) for this purpose).
1231
1232
1233Section 6.5.1., paragraph 1:
1234OLD:
1235
1236    The 400 (Bad Request) status code indicates that the server cannot or
1237    will not process the request due to something which is perceived to
1238    be a client error (e.g., malformed request syntax, invalid request
1239    message framing, or deceptive request routing).
1240
1241NEW:
1242
1243    The 400 (Bad Request) status code indicates that the server cannot or
1244    will not process the request due to something that is perceived to be
1245    a client error (e.g., malformed request syntax, invalid request
1246    message framing, or deceptive request routing).
1247
1248
1249Section 7.1.1.1., paragraph 11:
1250OLD:
1251
1252      day-name     = %x4D.6F.6E ; "Mon", case-sensitive
1253                   / %x54.75.65 ; "Tue", case-sensitive
1254                   / %x57.65.64 ; "Wed", case-sensitive
1255                   / %x54.68.75 ; "Thu", case-sensitive
1256                   / %x46.72.69 ; "Fri", case-sensitive
1257                   / %x53.61.74 ; "Sat", case-sensitive
1258                   / %x53.75.6E ; "Sun", case-sensitive
1259
1260NEW:
1261
1262      day-name     = %x4D.6F.6E ; "Mon", case sensitive
1263                   / %x54.75.65 ; "Tue", case sensitive
1264                   / %x57.65.64 ; "Wed", case sensitive
1265                   / %x54.68.75 ; "Thu", case sensitive
1266                   / %x46.72.69 ; "Fri", case sensitive
1267                   / %x53.61.74 ; "Sat", case sensitive
1268                   / %x53.75.6E ; "Sun", case sensitive
1269
1270
1271Section 7.1.1.1., paragraph 13:
1272OLD:
1273
1274      day          = 2DIGIT
1275      month        = %x4A.61.6E ; "Jan", case-sensitive
1276                   / %x46.65.62 ; "Feb", case-sensitive
1277                   / %x4D.61.72 ; "Mar", case-sensitive
1278                   / %x41.70.72 ; "Apr", case-sensitive
1279                   / %x4D.61.79 ; "May", case-sensitive
1280                   / %x4A.75.6E ; "Jun", case-sensitive
1281                   / %x4A.75.6C ; "Jul", case-sensitive
1282                   / %x41.75.67 ; "Aug", case-sensitive
1283                   / %x53.65.70 ; "Sep", case-sensitive
1284                   / %x4F.63.74 ; "Oct", case-sensitive
1285                   / %x4E.6F.76 ; "Nov", case-sensitive
1286                   / %x44.65.63 ; "Dec", case-sensitive
1287      year         = 4DIGIT
1288
1289NEW:
1290
1291      day          = 2DIGIT
1292      month        = %x4A.61.6E ; "Jan", case sensitive
1293                   / %x46.65.62 ; "Feb", case sensitive
1294                   / %x4D.61.72 ; "Mar", case sensitive
1295                   / %x41.70.72 ; "Apr", case sensitive
1296                   / %x4D.61.79 ; "May", case sensitive
1297                   / %x4A.75.6E ; "Jun", case sensitive
1298                   / %x4A.75.6C ; "Jul", case sensitive
1299                   / %x41.75.67 ; "Aug", case sensitive
1300                   / %x53.65.70 ; "Sep", case sensitive
1301                   / %x4F.63.74 ; "Oct", case sensitive
1302                   / %x4E.6F.76 ; "Nov", case sensitive
1303                   / %x44.65.63 ; "Dec", case sensitive
1304      year         = 4DIGIT
1305
1306
1307Section 7.1.1.1., paragraph 14:
1308OLD:
1309
1310      GMT          = %x47.4D.54 ; "GMT", case-sensitive
1311
1312NEW:
1313
1314      GMT          = %x47.4D.54 ; "GMT", case sensitive
1315
1316
1317Section 7.1.1.1., paragraph 19:
1318OLD:
1319
1320      day-name-l   = %x4D.6F.6E.64.61.79    ; "Monday", case-sensitive
1321             / %x54.75.65.73.64.61.79       ; "Tuesday", case-sensitive
1322             / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive
1323             / %x54.68.75.72.73.64.61.79    ; "Thursday", case-sensitive
1324             / %x46.72.69.64.61.79          ; "Friday", case-sensitive
1325             / %x53.61.74.75.72.64.61.79    ; "Saturday", case-sensitive
1326             / %x53.75.6E.64.61.79          ; "Sunday", case-sensitive
1327
1328NEW:
1329
1330      day-name-l   = %x4D.6F.6E.64.61.79    ; "Monday", case sensitive
1331             / %x54.75.65.73.64.61.79       ; "Tuesday", case sensitive
1332             / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case sensitive
1333             / %x54.68.75.72.73.64.61.79    ; "Thursday", case sensitive
1334             / %x46.72.69.64.61.79          ; "Friday", case sensitive
1335             / %x53.61.74.75.72.64.61.79    ; "Saturday", case sensitive
1336             / %x53.75.6E.64.61.79          ; "Sunday", case sensitive
1337
1338
1339Section 7.1.2., paragraph 5:
1340OLD:
1341
1342    If the Location value provided in a 3xx (Redirection) does not have a
1343    fragment component, a user agent MUST process the redirection as if
1344    the value inherits the fragment component of the URI reference used
1345    to generate the request target (i.e., the redirection inherits the
1346    original reference's fragment, if any).
1347
1348NEW:
1349
1350    If the Location value provided in a 3xx (Redirection) response does
1351    not have a fragment component, a user agent MUST process the
1352    redirection as if the value inherits the fragment component of the
1353    URI reference used to generate the request target (i.e., the
1354    redirection inherits the original reference's fragment, if any).
1355
1356
1357Section 7.1.4., paragraph 1:
1358OLD:
1359
1360    The "Vary" header field in a response describes what parts of a
1361    request message, aside from the method, Host header field, and
1362    request target, might influence the origin server's process for
1363    selecting and representing this response.  The value consists of
1364    either a single asterisk ("*") or a list of header field names (case-
1365    insensitive).
1366
1367NEW:
1368
1369    The "Vary" header field in a response describes what parts of a
1370    request message, aside from the method, Host header field, and
1371    request target, might influence the origin server's process for
1372    selecting and representing this response.  The value consists of
1373    either a single asterisk ("*") or a list of header field names (case
1374    insensitive).
1375
1376
1377Section 1., paragraph 1:
1378OLD:
1379
1380    2.  To inform user agent recipients that this response is subject to
1381        content negotiation (Section 5.3) and that a different
1382        representation might be sent in a subsequent request if
1383        additional parameters are provided in the listed header fields
1384        (proactive negotiation).
1385
1386NEW:
1387
1388    2.  To inform user-agent recipients that this response is subject to
1389        content negotiation (Section 5.3) and that a different
1390        representation might be sent in a subsequent request if
1391        additional parameters are provided in the listed header fields
1392        (proactive negotiation).
1393
1394
1395Section 7.2., paragraph 3:
1396OLD:
1397
1398    For example, an ETag header field in a 201 response communicates the
1399    entity-tag of the newly created resource's representation, so that it
1400    can be used in later conditional requests to prevent the "lost
1401    update" problem [RFC7232].
1402
1403NEW:
1404
1405    For example, an ETag header field in a 201 (Created) response
1406    communicates the entity-tag of the newly created resource's
1407    representation, so that it can be used in later conditional requests
1408    to prevent the "lost update" problem [RFC7232].
1409
1410
1411Section 8.1., paragraph 1:
1412OLD:
1413
1414    The HTTP Method Registry defines the name space for the request
1415    method token (Section 4).  The method registry will be created and
1416    maintained at (the suggested URI)
1417    <http://www.iana.org/assignments/http-methods>.
1418
1419NEW:
1420
1421    The "Hypertext Transfer Protocol (HTTP) Method Registry" defines the
1422    namespace for the request method token (Section 4).  The "HTTP Method
1423    Registry" has been created and is now maintained at
1424    <http://www.iana.org/assignments/http-methods>.
1425
1426
1427Section 8.1.2., paragraph 3:
1428OLD:
1429
1430    A new method definition needs to indicate whether it is safe
1431    (Section 4.2.1), idempotent (Section 4.2.2), cacheable
1432    (Section 4.2.3), what semantics are to be associated with the payload
1433    body if any is present in the request, and what refinements the
1434    method makes to header field or status code semantics.  If the new
1435    method is cacheable, its definition ought to describe how, and under
1436    what conditions, a cache can store a response and use it to satisfy a
1437    subsequent request.  The new method ought to describe whether it can
1438    be made conditional (Section 5.2) and, if so, how a server responds
1439    when the condition is false.  Likewise, if the new method might have
1440    some use for partial response semantics ([RFC7233]), it ought to
1441    document this, too.
1442
1443NEW:
1444
1445    A new method definition needs to indicate whether it is safe
1446    (Section 4.2.1), idempotent (Section 4.2.2), or cacheable
1447    (Section 4.2.3).  It needs to indicate what semantics are to be
1448    associated with the payload body if any is present in the request and
1449    what refinements the method makes to header field or status code
1450    semantics.  If the new method is cacheable, its definition ought to
1451    describe how, and under what conditions, a cache can store a response
1452    and use it to satisfy a subsequent request.  The new method ought to
1453    describe whether it can be made conditional (Section 5.2) and, if so,
1454    how a server responds when the condition is false.  Likewise, if the
1455    new method might have some use for partial response semantics
1456    ([RFC7233]), it ought to document this, too.
1457
1458
1459Section 8.1.3., paragraph 1:
1460OLD:
1461
1462    The HTTP Method Registry shall be populated with the registrations
1463    below:
1464
1465NEW:
1466
1467    The "Hypertext Transfer Protocol (HTTP) Method Registry" has been
1468    populated with the registrations below:
1469
1470
1471Section 8.2., paragraph 1:
1472OLD:
1473
1474    The HTTP Status Code Registry defines the name space for the response
1475    status-code token (Section 6).  The status code registry is
1476    maintained at <http://www.iana.org/assignments/http-status-codes>.
1477
1478NEW:
1479
1480    The "Hypertext Transfer Protocol (HTTP) Status Code Registry" defines
1481    the namespace for the response status-code token (Section 6).  The
1482    "HTTP Status Codes" registry is maintained at
1483    <http://www.iana.org/assignments/http-status-codes>.
1484
1485
1486Section 8.2., paragraph 2:
1487OLD:
1488
1489    This Section replaces the registration procedure for HTTP Status
1490    Codes previously defined in Section 7.1 of [RFC2817].
1491
1492NEW:
1493
1494    This section replaces the registration procedure for HTTP Status
1495    Codes previously defined in Section 7.1 of [RFC2817].
1496
1497
1498Section 8.2.3., paragraph 1:
1499OLD:
1500
1501    The HTTP Status Code Registry shall be updated with the registrations
1502    below:
1503
1504NEW:
1505
1506    The "HTTP Status Codes" registry has been updated with the
1507    registrations below:
1508
1509
1510Section 8.3., paragraph 1:
1511OLD:
1512
1513    HTTP header fields are registered within the Message Header Field
1514    Registry located at <http://www.iana.org/assignments/message-headers/
1515    message-header-index.html>, as defined by [BCP90].
1516
1517NEW:
1518
1519    HTTP header fields are registered within the "Message Headers"
1520    registry located at <http://www.iana.org/assignments/message-headers>
1521    as defined by [BCP90].
1522
1523
1524Section 8.3.1., paragraph 3:
1525OLD:
1526
1527    Authors of specifications defining new fields are advised to keep the
1528    name as short as practical and to not prefix the name with "X-"
1529    unless the header field will never be used on the Internet.  (The
1530    "x-" prefix idiom has been extensively misused in practice; it was
1531    intended to only be used as a mechanism for avoiding name collisions
1532    inside proprietary software or intranet processing, since the prefix
1533    would ensure that private names never collide with a newly registered
1534    Internet name; see [BCP178] for further information)
1535
1536NEW:
1537
1538    Authors of specifications defining new fields are advised to keep the
1539    name as short as practical and not to prefix the name with "X-"
1540    unless the header field will never be used on the Internet.  (The
1541    "X-" prefix idiom has been extensively misused in practice; it was
1542    intended to only be used as a mechanism for avoiding name collisions
1543    inside proprietary software or intranet processing, since the prefix
1544    would ensure that private names never collide with a newly registered
1545    Internet name; see [BCP178] for further information).
1546
1547
1548Section 8.3.1., paragraph 4:
1549OLD:
1550
1551    New header field values typically have their syntax defined using
1552    ABNF ([RFC5234]), using the extension defined in Section 7 of
1553    [RFC7230] as necessary, and are usually constrained to the range of
1554    ASCII characters.  Header fields needing a greater range of
1555    characters can use an encoding such as the one defined in [RFC5987].
1556
1557NEW:
1558
1559    New header field values typically have their syntax defined using
1560    ABNF ([RFC5234]) (implementing the extension defined in Section 7 of
1561    [RFC7230] as necessary), and they are usually constrained to the
1562    range of ASCII characters.  Header fields needing a greater range of
1563    characters can use an encoding such as the one defined in [RFC5987].
1564
1565
1566Section 8.3.2., paragraph 1:
1567OLD:
1568
1569    The Message Header Field Registry shall be updated with the following
1570    permanent registrations:
1571
1572NEW:
1573
1574    The "Message Headers" registry has been updated with the following
1575    permanent registrations:
1576
1577
1578Section 8.4., paragraph 1:
1579OLD:
1580
1581    The HTTP Content Coding Registry defines the name space for content
1582    coding names (Section 4.2 of [RFC7230]).  The content coding registry
1583    is maintained at <http://www.iana.org/assignments/http-parameters>.
1584
1585NEW:
1586
1587    The "HTTP Content Coding Registry" defines the namespace for content
1588    coding names (Section 4.2 of [RFC7230]).  The "HTTP Content Coding
1589    Registry" is maintained at
1590    <http://www.iana.org/assignments/http-parameters>.
1591
1592
1593Section 8.4.1., paragraph 1:
1594OLD:
1595
1596    Content Coding registrations MUST include the following fields:
1597
1598NEW:
1599
1600    Content coding registrations MUST include the following fields:
1601
1602
1603Section 8.4.1., paragraph 6:
1604OLD:
1605
1606    Values to be added to this name space require IETF Review (see
1607    Section 4.1 of [RFC5226]), and MUST conform to the purpose of content
1608    coding defined in this section.
1609
1610NEW:
1611
1612    Values to be added to this namespace require IETF Review (see Section
1613    4.1 of [RFC5226]) and MUST conform to the purpose of content coding
1614    defined in this section.
1615
1616
1617Section 8.4.2., paragraph 1:
1618OLD:
1619
1620    The HTTP Content Codings Registry shall be updated with the
1621    registrations below:
1622
1623NEW:
1624
1625    The "HTTP Content Codings Registry" has been updated with the
1626    registrations below:
1627
1628
1629Section 9., paragraph 2:
1630OLD:
1631
1632    The list of considerations below is not exhaustive.  Most security
1633    concerns related to HTTP semantics are about securing server-side
1634    applications (code behind the HTTP interface), securing user agent
1635    processing of payloads received via HTTP, or secure use of the
1636    Internet in general, rather than security of the protocol.  Various
1637    organizations maintain topical information and links to current
1638    research on Web application security (e.g., [OWASP]).
1639
1640NEW:
1641
1642    The list of considerations below is not exhaustive.  Most security
1643    concerns related to HTTP semantics are about securing server-side
1644    applications (code behind the HTTP interface) or securing user-agent
1645    processing of payloads received via HTTP.  Secure use of the Internet
1646    in general, rather than security of the protocol, might also be
1647    related.  Various organizations maintain topical information and
1648    links to current research on Web application security (e.g.,
1649    [OWASP]).
1650
1651
1652Section 9.1., paragraph 2:
1653OLD:
1654
1655    For example, UNIX, Microsoft Windows, and other operating systems use
1656    ".." as a path component to indicate a directory level above the
1657    current one, and use specially named paths or file names to send data
1658    to system devices.  Similar naming conventions might exist within
1659    other types of storage systems.  Likewise, local storage systems have
1660    an annoying tendency to prefer user-friendliness over security when
1661    handling invalid or unexpected characters, recomposition of
1662    decomposed characters, and case-normalization of case-insensitive
1663    names.
1664
1665NEW:
1666
1667    For example, UNIX, Microsoft Windows, and other operating systems use
1668    ".." as a path component to indicate a directory level above the
1669    current one, and they use specially named paths or file names to send
1670    data to system devices.  Similar naming conventions might exist
1671    within other types of storage systems.  Likewise, local storage
1672    systems have an annoying tendency to prefer user-friendliness over
1673    security when handling invalid or unexpected characters,
1674    recomposition of decomposed characters, and case-normalization of
1675    case-insensitive names.
1676
1677
1678Section 9.1., paragraph 3:
1679OLD:
1680
1681    Attacks based on such special names tend to focus on either denial-
1682    of-service (e.g., telling the server to read from a COM port) or
1683    disclosure of configuration and source files that are not meant to be
1684    served.
1685
1686NEW:
1687
1688    Attacks based on such special names tend to focus on either denial of
1689    service (e.g., telling the server to read from a COM port) or
1690    disclosure of configuration and source files that are not meant to be
1691    served.
1692
1693
1694Section 9.4., paragraph 3:
1695OLD:
1696
1697    Since the Referer header field tells a target site about the context
1698    that resulted in a request, it has the potential to reveal
1699    information about the user's immediate browsing history and any
1700    personal information that might be found in the referring resource's
1701    URI.  Limitations on Referer are described in Section 5.5.2 to
1702    address some of its security considerations.
1703
1704NEW:
1705
1706    Since the Referer header field tells a target site about the context
1707    that resulted in a request, it has the potential to reveal
1708    information about the user's immediate browsing history and any
1709    personal information that might be found in the referring resource's
1710    URI.  Limitations on the Referer header field are described in
1711    Section 5.5.2 to address some of its security considerations.
1712
1713
1714Section 11.1., paragraph 9:
1715OLD:
1716
1717    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1718               Protocol (HTTP/1.1): Message Syntax and Routing",
1719               draft-ietf-httpbis-p1-messaging-latest (work in progress),
1720               May 2014.
1721
1722NEW:
1723
1724    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1725               Protocol (HTTP/1.1): Message Syntax and Routing",
1726               RFC 7230, May 2014.
1727
1728
1729Section 11.1., paragraph 10:
1730OLD:
1731
1732    [RFC7232]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1733               Protocol (HTTP/1.1): Conditional Requests",
1734               draft-ietf-httpbis-p4-conditional-latest (work in
1735               progress), May 2014.
1736
1737NEW:
1738
1739    [RFC7232]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1740               Protocol (HTTP/1.1): Conditional Requests", RFC 7232,
1741               May 2014.
1742
1743
1744Section 11.1., paragraph 11:
1745OLD:
1746
1747    [RFC7233]  Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
1748               "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
1749               draft-ietf-httpbis-p5-range-latest (work in progress),
1750               May 2014.
1751
1752NEW:
1753
1754    [RFC7233]  Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
1755               "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
1756               RFC 7233, May 2014.
1757
1758
1759Section 11.1., paragraph 12:
1760OLD:
1761
1762    [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1763               Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
1764               draft-ietf-httpbis-p6-cache-latest (work in progress),
1765               May 2014.
1766
1767NEW:
1768
1769    [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1770               Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
1771               RFC 7234, May 2014.
1772
1773
1774Section 11.1., paragraph 13:
1775OLD:
1776
1777    [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1778               Protocol (HTTP/1.1): Authentication",
1779               draft-ietf-httpbis-p7-auth-latest (work in progress),
1780               May 2014.
1781
1782NEW:
1783
1784    [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1785               Protocol (HTTP/1.1): Authentication", RFC 7235, May 2014.
1786
1787
1788Section 11.2., paragraph 25:
1789OLD:
1790
1791    [RFC7238]  Reschke, J., "The Hypertext Transfer Protocol (HTTP)
1792               Status Code 308 (Permanent Redirect)",
1793               draft-reschke-http-status-308-07 (work in progress),
1794               March 2012.
1795
1796NEW:
1797
1798    [RFC7238]  Reschke, J., "The Hypertext Transfer Protocol (HTTP)
1799               Status Code 308 (Permanent Redirect)", RFC 7238, May 2014.
1800
1801
1802Appendix A., paragraph 1:
1803OLD:
1804
1805    HTTP/1.1 uses many of the constructs defined for the Internet Message
1806    Format [RFC5322] and the Multipurpose Internet Mail Extensions (MIME)
1807    [RFC2045] to allow a message body to be transmitted in an open
1808    variety of representations and with extensible header fields.
1809    However, RFC 2045 is focused only on email; applications of HTTP have
1810    many characteristics that differ from email, and hence HTTP has
1811    features that differ from MIME.  These differences were carefully
1812    chosen to optimize performance over binary connections, to allow
1813    greater freedom in the use of new media types, to make date
1814    comparisons easier, and to acknowledge the practice of some early
1815    HTTP servers and clients.
1816
1817NEW:
1818
1819    HTTP/1.1 uses many of the constructs defined for the Internet Message
1820    Format [RFC5322] and the Multipurpose Internet Mail Extensions (MIME)
1821    [RFC2045] to allow a message body to be transmitted in an open
1822    variety of representations and with extensible header fields.
1823    However, RFC 2045 is focused only on email; applications of HTTP have
1824    many characteristics that differ from email; hence, HTTP has features
1825    that differ from MIME.  These differences were carefully chosen to
1826    optimize performance over binary connections, to allow greater
1827    freedom in the use of new media types, to make date comparisons
1828    easier, and to acknowledge the practice of some early HTTP servers
1829    and clients.
1830
1831
1832Appendix A., paragraph 16:
1833OLD:
1834
1835 A.6.  MHTML and Line Length Limitations
1836
1837NEW:
1838
1839 A.6.  MHTML and Line-Length Limitations
1840
1841
1842Appendix A., paragraph 17:
1843OLD:
1844
1845    HTTP implementations that share code with MHTML [RFC2557]
1846    implementations need to be aware of MIME line length limitations.
1847    Since HTTP does not have this limitation, HTTP does not fold long
1848    lines.  MHTML messages being transported by HTTP follow all
1849    conventions of MHTML, including line length limitations and folding,
1850    canonicalization, etc., since HTTP transfers message-bodies as
1851    payload and, aside from the "multipart/byteranges" type (Appendix A
1852    of [RFC7233]), does not interpret the content or any MIME header
1853    lines that might be contained therein.
1854
1855NEW:
1856
1857    HTTP implementations that share code with MHTML [RFC2557]
1858    implementations need to be aware of MIME line-length limitations.
1859    Since HTTP does not have this limitation, HTTP does not fold long
1860    lines.  MHTML messages being transported by HTTP follow all
1861    conventions of MHTML, including line-length limitations and folding,
1862    canonicalization, etc., since HTTP transfers message-bodies as
1863    payload and, aside from the "multipart/byteranges" type (Appendix A
1864    of [RFC7233]), does not interpret the content or any MIME header
1865    lines that might be contained therein.
1866
1867
1868Appendix B., paragraph 2:
1869OLD:
1870
1871    A new requirement has been added that semantics embedded in a URI
1872    should be disabled when those semantics are inconsistent with the
1873    request method, since this is a common cause of interoperability
1874    failure.  (Section 2)
1875
1876NEW:
1877
1878    A new requirement has been added that semantics embedded in a URI be
1879    disabled when those semantics are inconsistent with the request
1880    method, since this is a common cause of interoperability failure
1881    (Section 2).
1882
1883
1884Appendix B., paragraph 3:
1885OLD:
1886
1887    An algorithm has been added for determining if a payload is
1888    associated with a specific identifier.  (Section 3.1.4.1)
1889
1890NEW:
1891
1892    An algorithm has been added for determining if a payload is
1893    associated with a specific identifier (Section 3.1.4.1).
1894
1895
1896Appendix B., paragraph 4:
1897OLD:
1898
1899    The default charset of ISO-8859-1 for text media types has been
1900    removed; the default is now whatever the media type definition says.
1901    Likewise, special treatment of ISO-8859-1 has been removed from the
1902    Accept-Charset header field.  (Section 3.1.1.3 and Section 5.3.3)
1903
1904NEW:
1905
1906    The default charset of ISO-8859-1 for text media types has been
1907    removed; the default is now whatever the media type definition says.
1908    Likewise, special treatment of ISO-8859-1 has been removed from the
1909    Accept-Charset header field.  (Sections 3.1.1.3 and 5.3.3.)
1910
1911
1912Appendix B., paragraph 5:
1913OLD:
1914
1915    The definition of Content-Location has been changed to no longer
1916    affect the base URI for resolving relative URI references, due to
1917    poor implementation support and the undesirable effect of potentially
1918    breaking relative links in content-negotiated resources.
1919    (Section 3.1.4.2)
1920
1921NEW:
1922
1923    The definition of Content-Location has been changed to no longer
1924    affect the base URI for resolving relative URI references, due to
1925    poor implementation support and the undesirable effect of potentially
1926    breaking relative links in content-negotiated resources
1927    (Section 3.1.4.2).
1928
1929
1930Appendix B., paragraph 6:
1931OLD:
1932
1933    To be consistent with the method-neutral parsing algorithm of
1934    [RFC7230], the definition of GET has been relaxed so that requests
1935    can have a body, even though a body has no meaning for GET.
1936    (Section 4.3.1)
1937
1938NEW:
1939
1940    To be consistent with the method-neutral parsing algorithm of
1941    [RFC7230], the definition of GET has been relaxed so that requests
1942    can have a body, even though a body has no meaning for GET
1943    (Section 4.3.1).
1944
1945
1946Appendix B., paragraph 7:
1947OLD:
1948
1949    Servers are no longer required to handle all Content-* header fields
1950    and use of Content-Range has been explicitly banned in PUT requests.
1951    (Section 4.3.4)
1952
1953NEW:
1954
1955    Servers are no longer required to handle all Content-* header fields
1956    and use of Content-Range has been explicitly banned in PUT requests
1957    (Section 4.3.4).
1958
1959
1960Appendix B., paragraph 8:
1961OLD:
1962
1963    Definition of the CONNECT method has been moved from [RFC2817] to
1964    this specification.  (Section 4.3.6)
1965
1966NEW:
1967
1968    Definition of the CONNECT method has been moved from [RFC2817] to
1969    this specification (Section 4.3.6).
1970
1971
1972Appendix B., paragraph 9:
1973OLD:
1974
1975    The OPTIONS and TRACE request methods have been defined as being
1976    safe.  (Section 4.3.7 and Section 4.3.8)
1977
1978NEW:
1979
1980    The OPTIONS and TRACE request methods have been defined as being safe
1981    (Section 4.3.7 and Section 4.3.8).
1982
1983
1984Appendix B., paragraph 10:
1985OLD:
1986
1987    The Expect header field's extension mechanism has been removed due to
1988    widely-deployed broken implementations.  (Section 5.1.1)
1989
1990NEW:
1991
1992    The Expect header field's extension mechanism has been removed due to
1993    widely deployed broken implementations (Section 5.1.1).
1994
1995
1996Appendix B., paragraph 11:
1997OLD:
1998
1999    The Max-Forwards header field has been restricted to the OPTIONS and
2000    TRACE methods; previously, extension methods could have used it as
2001    well.  (Section 5.1.2)
2002
2003NEW:
2004
2005    The Max-Forwards header field has been restricted to the OPTIONS and
2006    TRACE methods; previously, extension methods could have used it as
2007    well (Section 5.1.2).
2008
2009
2010Appendix B., paragraph 12:
2011OLD:
2012
2013    The "about:blank" URI has been suggested as a value for the Referer
2014    header field when no referring URI is applicable, which distinguishes
2015    that case from others where the Referer field is not sent or has been
2016    removed.  (Section 5.5.2)
2017
2018NEW:
2019
2020    The "about:blank" URI has been suggested as a value for the Referer
2021    header field when no referring URI is applicable, which distinguishes
2022    that case from others where the Referer field is not sent or has been
2023    removed (Section 5.5.2).
2024
2025
2026Appendix B., paragraph 13:
2027OLD:
2028
2029    The following status codes are now cacheable (that is, they can be
2030    stored and reused by a cache without explicit freshness information
2031    present): 204, 404, 405, 414, 501.  (Section 6)
2032
2033NEW:
2034
2035    The following status codes are now cacheable (that is, they can be
2036    stored and reused by a cache without explicit freshness information
2037    present): 204, 404, 405, 414, 501 (Section 6).
2038
2039
2040Appendix B., paragraph 14:
2041OLD:
2042
2043    The 201 (Created) status description has been changed to allow for
2044    the possibility that more than one resource has been created.
2045    (Section 6.3.2)
2046
2047NEW:
2048
2049    The 201 (Created) status description has been changed to allow for
2050    the possibility that more than one resource has been created
2051    (Section 6.3.2).
2052
2053
2054Appendix B., paragraph 15:
2055OLD:
2056
2057    The definition of 203 (Non-Authoritative Information) has been
2058    broadened to include cases of payload transformations as well.
2059    (Section 6.3.4)
2060
2061NEW:
2062
2063    The definition of 203 (Non-Authoritative Information) has been
2064    broadened to include cases of payload transformations as well
2065    (Section 6.3.4).
2066
2067
2068Appendix B., paragraph 16:
2069OLD:
2070
2071    The set of request methods that are safe to automatically redirect is
2072    no longer closed; user agents are able to make that determination
2073    based upon the request method semantics.  The redirect status codes
2074    301, 302, and 307 no longer have normative requirements on response
2075    payloads and user interaction.  (Section 6.4)
2076
2077NEW:
2078
2079    The set of request methods that are safe to automatically redirect is
2080    no longer closed; user agents are able to make that determination
2081    based upon the request method semantics.  The redirect status codes
2082    301, 302, and 307 no longer have normative requirements on response
2083    payloads and user interaction (Section 6.4).
2084
2085
2086Appendix B., paragraph 17:
2087OLD:
2088
2089    The status codes 301 and 302 have been changed to allow user agents
2090    to rewrite the method from POST to GET.  (Sections 6.4.2 and 6.4.3)
2091
2092NEW:
2093
2094    The status codes 301 and 302 have been changed to allow user agents
2095    to rewrite the method from POST to GET.  (Sections 6.4.2 and 6.4.3.)
2096
2097
2098Appendix B., paragraph 18:
2099OLD:
2100
2101    The description of 303 (See Other) status code has been changed to
2102    allow it to be cached if explicit freshness information is given, and
2103    a specific definition has been added for a 303 response to GET.
2104    (Section 6.4.4)
2105
2106NEW:
2107
2108    The description of the 303 (See Other) status code has been changed
2109    to allow it to be cached if explicit freshness information is given,
2110    and a specific definition has been added for a 303 response to GET
2111    (Section 6.4.4).
2112
2113
2114Appendix B., paragraph 19:
2115OLD:
2116
2117    The 305 (Use Proxy) status code has been deprecated due to security
2118    concerns regarding in-band configuration of a proxy.  (Section 6.4.5)
2119
2120NEW:
2121
2122    The 305 (Use Proxy) status code has been deprecated due to security
2123    concerns regarding in-band configuration of a proxy (Section 6.4.5).
2124
2125
2126Appendix B., paragraph 20:
2127OLD:
2128
2129    The 400 (Bad Request) status code has been relaxed so that it isn't
2130    limited to syntax errors.  (Section 6.5.1)
2131
2132NEW:
2133
2134    The 400 (Bad Request) status code has been relaxed so that it isn't
2135    limited to syntax errors (Section 6.5.1).
2136
2137
2138Appendix B., paragraph 21:
2139OLD:
2140
2141    The 426 (Upgrade Required) status code has been incorporated from
2142    [RFC2817].  (Section 6.5.15)
2143
2144NEW:
2145
2146    The 426 (Upgrade Required) status code has been incorporated from
2147    [RFC2817] (Section 6.5.15).
2148
2149
2150Appendix B., paragraph 22:
2151OLD:
2152
2153    The target of requirements on HTTP-date and the Date header field
2154    have been reduced to those systems generating the date, rather than
2155    all systems sending a date.  (Section 7.1.1)
2156
2157NEW:
2158
2159    The target of requirements on HTTP-date and the Date header field
2160    have been reduced to those systems generating the date, rather than
2161    all systems sending a date (Section 7.1.1).
2162
2163
2164Appendix B., paragraph 23:
2165OLD:
2166
2167    The syntax of the Location header field has been changed to allow all
2168    URI references, including relative references and fragments, along
2169    with some clarifications as to when use of fragments would not be
2170    appropriate.  (Section 7.1.2)
2171
2172NEW:
2173
2174    The syntax of the Location header field has been changed to allow all
2175    URI references, including relative references and fragments, along
2176    with some clarifications as to when use of fragments would not be
2177    appropriate (Section 7.1.2).
2178
2179
2180Appendix B., paragraph 24:
2181OLD:
2182
2183    Allow has been reclassified as a response header field, removing the
2184    option to specify it in a PUT request.  Requirements relating to the
2185    content of Allow have been relaxed; correspondingly, clients are not
2186    required to always trust its value.  (Section 7.4.1)
2187
2188NEW:
2189
2190    Allow has been reclassified as a response header field, removing the
2191    option to specify it in a PUT request.  Requirements relating to the
2192    content of Allow have been relaxed; correspondingly, clients are not
2193    required to always trust its value (Section 7.4.1).
2194
2195
2196Appendix B., paragraph 25:
2197OLD:
2198
2199    A Method Registry has been defined.  (Section 8.1)
2200
2201NEW:
2202
2203    A Method Registry has been defined (Section 8.1).
2204
2205
2206Appendix B., paragraph 26:
2207OLD:
2208
2209    The Status Code Registry has been redefined by this specification;
2210    previously, it was defined in Section 7.1 of [RFC2817].
2211 
2212    (Section 8.2)
2213
2214NEW:
2215
2216    The Status Code Registry has been redefined by this specification;
2217    previously, it was defined in Section 7.1 of [RFC2817] (Section 8.2).
2218
2219
2220Appendix B., paragraph 27:
2221OLD:
2222
2223    Registration of Content Codings has been changed to require IETF
2224    Review.  (Section 8.4)
2225
2226NEW:
2227
2228    Registration of content codings has been changed to require IETF
2229    Review (Section 8.4).
2230
2231
2232Section 1.2, paragraph 1:
2233OLD:
2234
2235    Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
2236     OWS ( media-range [ accept-params ] ) ] ) ]
2237    Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS
2238     "," [ OWS ( ( charset / "*" ) [ weight ] ) ] )
2239    Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS
2240     ( codings [ weight ] ) ] ) ]
2241    Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS
2242     "," [ OWS ( language-range [ weight ] ) ] )
2243    Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ]
2244    BWS = <BWS, defined in [RFC7230], Section 3.2.3>
2245
2246NEW:
2247
2248    Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
2249     OWS ( media-range [ accept-params ] ) ] ) ]
2250    Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS
2251     "," [ OWS ( ( charset / "*" ) [ weight ] ) ] )
2252    Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS
2253     ( codings [ weight ] ) ] ) ]
2254    Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS
2255     "," [ OWS ( language-range [ weight ] ) ] )
2256    Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ]
2257 
2258    BWS = <BWS, defined in [RFC7230], Section 3.2.3>
2259
2260
2261Section 1.2, paragraph 2:
2262OLD:
2263
2264    Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS
2265     content-coding ] )
2266    Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS
2267     language-tag ] )
2268    Content-Location = absolute-URI / partial-URI
2269    Content-Type = media-type
2270 
2271    Date = HTTP-date
2272
2273NEW:
2274
2275    Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS
2276     content-coding ] )
2277    Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS
2278     language-tag ] )
2279    Content-Location = absolute-URI / partial-URI
2280    Content-Type = media-type
2281    Date = HTTP-date
2282
2283
2284Section 1.2, paragraph 16:
2285OLD:
2286
2287    charset = token
2288    codings = content-coding / "identity" / "*"
2289    comment = <comment, defined in [RFC7230], Section 3.2.6>
2290    content-coding = token
2291    date1 = day SP month SP year
2292    date2 = day "-" month "-" 2DIGIT
2293    date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
2294    day = 2DIGIT
2295    day-name = %x4D.6F.6E ; Mon
2296     / %x54.75.65 ; Tue
2297     / %x57.65.64 ; Wed
2298     / %x54.68.75 ; Thu
2299     / %x46.72.69 ; Fri
2300     / %x53.61.74 ; Sat
2301     / %x53.75.6E ; Sun
2302    day-name-l = %x4D.6F.6E.64.61.79 ; Monday
2303     / %x54.75.65.73.64.61.79 ; Tuesday
2304     / %x57.65.64.6E.65.73.64.61.79 ; Wednesday
2305     / %x54.68.75.72.73.64.61.79 ; Thursday
2306     / %x46.72.69.64.61.79 ; Friday
2307     / %x53.61.74.75.72.64.61.79 ; Saturday
2308     / %x53.75.6E.64.61.79 ; Sunday
2309    delay-seconds = 1*DIGIT
2310
2311NEW:
2312
2313    charset = token
2314    codings = content-coding / "identity" / "*"
2315    comment = <comment, defined in [RFC7230], Section 3.2.6>
2316    content-coding = token
2317 
2318    date1 = day SP month SP year
2319    date2 = day "-" month "-" 2DIGIT
2320    date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
2321    day = 2DIGIT
2322    day-name = %x4D.6F.6E ; Mon
2323     / %x54.75.65 ; Tue
2324     / %x57.65.64 ; Wed
2325     / %x54.68.75 ; Thu
2326     / %x46.72.69 ; Fri
2327     / %x53.61.74 ; Sat
2328     / %x53.75.6E ; Sun
2329    day-name-l = %x4D.6F.6E.64.61.79 ; Monday
2330     / %x54.75.65.73.64.61.79 ; Tuesday
2331     / %x57.65.64.6E.65.73.64.61.79 ; Wednesday
2332     / %x54.68.75.72.73.64.61.79 ; Thursday
2333     / %x46.72.69.64.61.79 ; Friday
2334     / %x53.61.74.75.72.64.61.79 ; Saturday
2335     / %x53.75.6E.64.61.79 ; Sunday
2336    delay-seconds = 1*DIGIT
2337
2338
2339Section 1.2, paragraph 21:
2340OLD:
2341
2342    obs-date = rfc850-date / asctime-date
2343    parameter = token "=" ( token / quoted-string )
2344    partial-URI = <partial-URI, defined in [RFC7230], Section 2.7>
2345    product = token [ "/" product-version ]
2346    product-version = token
2347 
2348    quoted-string = <quoted-string, defined in [RFC7230], Section 3.2.6>
2349    qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
2350
2351NEW:
2352
2353    obs-date = rfc850-date / asctime-date
2354 
2355    parameter = token "=" ( token / quoted-string )
2356    partial-URI = <partial-URI, defined in [RFC7230], Section 2.7>
2357    product = token [ "/" product-version ]
2358    product-version = token
2359    quoted-string = <quoted-string, defined in [RFC7230], Section 3.2.6>
2360    qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
2361
2362
2363Section 1.2, paragraph 47:
2364OLD:
2365
2366    M
2367       Max-Forwards header field  36
2368       MIME-Version header field  89
2369
2370NEW:
2371
2372    M
2373       Max-Forwards header field  36
2374       MIME-Version header field  88
2375
2376
2377Section 345, paragraph 1:
2378OLD:
2379
2380    EMail: fielding@gbiv.com
2381    URI:   http://roy.gbiv.com/
2382    Julian F. Reschke (editor)
2383    greenbytes GmbH
2384    Hafenweg 16
2385    Muenster, NW  48155
2386    Germany
2387
2388NEW:
2389
2390    EMail: fielding@gbiv.com
2391    URI:   http://roy.gbiv.com/
2392 
2393    Julian F. Reschke (editor)
2394    greenbytes GmbH
2395    Hafenweg 16
2396    Muenster, NW  48155
2397    Germany
2398
Note: See TracBrowser for help on using the repository browser.