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

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

header field sorting (#553)

File size: 96.5 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 1:
1108OLD:
1109
1110    The status-code element is a 3-digit integer code giving the result
1111    of the attempt to understand and satisfy the request.
1112
1113NEW:
1114
1115    The status-code element is a three-digit integer code giving the
1116    result of the attempt to understand and satisfy the request.
1117
1118
1119Section 6., paragraph 3:
1120OLD:
1121
1122    For example, if an unrecognized status code of 471 is received by a
1123    client, the client can assume that there was something wrong with its
1124    request and treat the response as if it had received a 400 status
1125    code.  The response message will usually contain a representation
1126    that explains the status.
1127
1128NEW:
1129
1130    For example, if an unrecognized status code of 471 is received by a
1131    client, the client can assume that there was something wrong with its
1132    request and treat the response as if it had received a 400 (Bad
1133    Request) status code.  The response message will usually contain a
1134    representation that explains the status.
1135
1136
1137Section 6., paragraph 4:
1138OLD:
1139
1140    The first digit of the status-code defines the class of response.
1141    The last two digits do not have any categorization role.  There are 5
1142    values for the first digit:
1143
1144NEW:
1145
1146    The first digit of the status-code defines the class of response.
1147    The last two digits do not have any categorization role.  There are
1148    five values for the first digit:
1149
1150
1151Section 6.1., paragraph 2:
1152OLD:
1153
1154    Responses with status codes that are defined as cacheable by default
1155    (e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501 in this
1156    specification) can be reused by a cache with heuristic expiration
1157    unless otherwise indicated by the method definition or explicit cache
1158    controls [RFC7234]; all other status codes are not cacheable by
1159    default.
1160
1161NEW:
1162
1163    Responses with status codes that are defined as cacheable by default
1164    (e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501 in
1165    this specification) can be reused by a cache with heuristic
1166    expiration unless otherwise indicated by the method definition or
1167    explicit cache controls [RFC7234]; all other status codes are not
1168    cacheable by default.
1169
1170
1171Section 6.3.3., paragraph 2:
1172OLD:
1173
1174    The 202 response is intentionally non-committal.  Its purpose is to
1175    allow a server to accept a request for some other process (perhaps a
1176    batch-oriented process that is only run once per day) without
1177    requiring that the user agent's connection to the server persist
1178    until the process is completed.  The representation sent with this
1179    response ought to describe the request's current status and point to
1180    (or embed) a status monitor that can provide the user with an
1181    estimate of when the request will be fulfilled.
1182
1183NEW:
1184
1185    The 202 response is intentionally noncommittal.  Its purpose is to
1186    allow a server to accept a request for some other process (perhaps a
1187    batch-oriented process that is only run once per day) without
1188    requiring that the user agent's connection to the server persist
1189    until the process is completed.  The representation sent with this
1190    response ought to describe the request's current status and point to
1191    (or embed) a status monitor that can provide the user with an
1192    estimate of when the request will be fulfilled.
1193
1194
1195Section 6.4.1., paragraph 5:
1196OLD:
1197
1198       Note: The original proposal for 300 defined the URI header field
1199       as providing a list of alternative representations, such that it
1200       would be usable for 200, 300, and 406 responses and be transferred
1201       in responses to the HEAD method.  However, lack of deployment and
1202       disagreement over syntax led to both URI and Alternates (a
1203       subsequent proposal) being dropped from this specification.  It is
1204       possible to communicate the list using a set of Link header fields
1205       [RFC5988], each with a relationship of "alternate", though
1206       deployment is a chicken-and-egg problem.
1207
1208NEW:
1209
1210       Note: The original proposal for the 300 response defined the URI
1211       header field as providing a list of alternative representations,
1212       such that it would be usable for 200, 300, and 406 responses and
1213       be transferred in responses to the HEAD method.  However, lack of
1214       deployment and disagreement over syntax led to both URI and
1215       Alternates (a subsequent proposal) being dropped from this
1216       specification.  It is possible to communicate the list using a set
1217       of Link header fields [RFC5988], each with a relationship of
1218       "alternate", though deployment is a chicken-and-egg problem.
1219
1220
1221Section 6.4.2., paragraph 1:
1222OLD:
1223
1224    The 301 (Moved Permanently) status code indicates that the target
1225    resource has been assigned a new permanent URI and any future
1226    references to this resource ought to use one of the enclosed URIs.
1227    Clients with link editing capabilities ought to automatically re-link
1228    references to the effective request URI to one or more of the new
1229    references sent by the server, where possible.
1230
1231NEW:
1232
1233    The 301 (Moved Permanently) status code indicates that the target
1234    resource has been assigned a new permanent URI and any future
1235    references to this resource ought to use one of the enclosed URIs.
1236    Clients with link-editing capabilities ought to automatically re-link
1237    references to the effective request URI to one or more of the new
1238    references sent by the server, where possible.
1239
1240
1241Section 6.4.7., paragraph 3:
1242OLD:
1243
1244       Note: This status code is similar to 302 (Found), except that it
1245       does not allow changing the request method from POST to GET.  This
1246       specification defines no equivalent counterpart for 301 (Moved
1247       Permanently) ([RFC7238], however, defines the status code 308
1248       (Permanent Redirect) for this purpose).
1249
1250NEW:
1251
1252       Note: This status code is similar to 302 (Found), except that it
1253       does not allow changing the request method from POST to GET.  This
1254       specification defines no equivalent counterpart for 301 (Moved
1255       Permanently) ([RFC7238]; however, it defines the status code 308
1256       (Permanent Redirect) for this purpose).
1257
1258
1259Section 6.5.1., paragraph 1:
1260OLD:
1261
1262    The 400 (Bad Request) status code indicates that the server cannot or
1263    will not process the request due to something which is perceived to
1264    be a client error (e.g., malformed request syntax, invalid request
1265    message framing, or deceptive request routing).
1266
1267NEW:
1268
1269    The 400 (Bad Request) status code indicates that the server cannot or
1270    will not process the request due to something that is perceived to be
1271    a client error (e.g., malformed request syntax, invalid request
1272    message framing, or deceptive request routing).
1273
1274
1275Section 7.1.1.1., paragraph 11:
1276OLD:
1277
1278      day-name     = %x4D.6F.6E ; "Mon", case-sensitive
1279                   / %x54.75.65 ; "Tue", case-sensitive
1280                   / %x57.65.64 ; "Wed", case-sensitive
1281                   / %x54.68.75 ; "Thu", case-sensitive
1282                   / %x46.72.69 ; "Fri", case-sensitive
1283                   / %x53.61.74 ; "Sat", case-sensitive
1284                   / %x53.75.6E ; "Sun", case-sensitive
1285
1286NEW:
1287
1288      day-name     = %x4D.6F.6E ; "Mon", case sensitive
1289                   / %x54.75.65 ; "Tue", case sensitive
1290                   / %x57.65.64 ; "Wed", case sensitive
1291                   / %x54.68.75 ; "Thu", case sensitive
1292                   / %x46.72.69 ; "Fri", case sensitive
1293                   / %x53.61.74 ; "Sat", case sensitive
1294                   / %x53.75.6E ; "Sun", case sensitive
1295
1296
1297Section 7.1.1.1., paragraph 13:
1298OLD:
1299
1300      day          = 2DIGIT
1301      month        = %x4A.61.6E ; "Jan", case-sensitive
1302                   / %x46.65.62 ; "Feb", case-sensitive
1303                   / %x4D.61.72 ; "Mar", case-sensitive
1304                   / %x41.70.72 ; "Apr", case-sensitive
1305                   / %x4D.61.79 ; "May", case-sensitive
1306                   / %x4A.75.6E ; "Jun", case-sensitive
1307                   / %x4A.75.6C ; "Jul", case-sensitive
1308                   / %x41.75.67 ; "Aug", case-sensitive
1309                   / %x53.65.70 ; "Sep", case-sensitive
1310                   / %x4F.63.74 ; "Oct", case-sensitive
1311                   / %x4E.6F.76 ; "Nov", case-sensitive
1312                   / %x44.65.63 ; "Dec", case-sensitive
1313      year         = 4DIGIT
1314
1315NEW:
1316
1317      day          = 2DIGIT
1318      month        = %x4A.61.6E ; "Jan", case sensitive
1319                   / %x46.65.62 ; "Feb", case sensitive
1320                   / %x4D.61.72 ; "Mar", case sensitive
1321                   / %x41.70.72 ; "Apr", case sensitive
1322                   / %x4D.61.79 ; "May", case sensitive
1323                   / %x4A.75.6E ; "Jun", case sensitive
1324                   / %x4A.75.6C ; "Jul", case sensitive
1325                   / %x41.75.67 ; "Aug", case sensitive
1326                   / %x53.65.70 ; "Sep", case sensitive
1327                   / %x4F.63.74 ; "Oct", case sensitive
1328                   / %x4E.6F.76 ; "Nov", case sensitive
1329                   / %x44.65.63 ; "Dec", case sensitive
1330      year         = 4DIGIT
1331
1332
1333Section 7.1.1.1., paragraph 14:
1334OLD:
1335
1336      GMT          = %x47.4D.54 ; "GMT", case-sensitive
1337
1338NEW:
1339
1340      GMT          = %x47.4D.54 ; "GMT", case sensitive
1341
1342
1343Section 7.1.1.1., paragraph 19:
1344OLD:
1345
1346      day-name-l   = %x4D.6F.6E.64.61.79    ; "Monday", case-sensitive
1347             / %x54.75.65.73.64.61.79       ; "Tuesday", case-sensitive
1348             / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive
1349             / %x54.68.75.72.73.64.61.79    ; "Thursday", case-sensitive
1350             / %x46.72.69.64.61.79          ; "Friday", case-sensitive
1351             / %x53.61.74.75.72.64.61.79    ; "Saturday", case-sensitive
1352             / %x53.75.6E.64.61.79          ; "Sunday", case-sensitive
1353
1354NEW:
1355
1356      day-name-l   = %x4D.6F.6E.64.61.79    ; "Monday", case sensitive
1357             / %x54.75.65.73.64.61.79       ; "Tuesday", case sensitive
1358             / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case sensitive
1359             / %x54.68.75.72.73.64.61.79    ; "Thursday", case sensitive
1360             / %x46.72.69.64.61.79          ; "Friday", case sensitive
1361             / %x53.61.74.75.72.64.61.79    ; "Saturday", case sensitive
1362             / %x53.75.6E.64.61.79          ; "Sunday", case sensitive
1363
1364
1365Section 7.1.2., paragraph 5:
1366OLD:
1367
1368    If the Location value provided in a 3xx (Redirection) does not have a
1369    fragment component, a user agent MUST process the redirection as if
1370    the value inherits the fragment component of the URI reference used
1371    to generate the request target (i.e., the redirection inherits the
1372    original reference's fragment, if any).
1373
1374NEW:
1375
1376    If the Location value provided in a 3xx (Redirection) response does
1377    not have a fragment component, a user agent MUST process the
1378    redirection as if the value inherits the fragment component of the
1379    URI reference used to generate the request target (i.e., the
1380    redirection inherits the original reference's fragment, if any).
1381
1382
1383Section 7.1.4., paragraph 1:
1384OLD:
1385
1386    The "Vary" header field in a response describes what parts of a
1387    request message, aside from the method, Host header field, and
1388    request target, might influence the origin server's process for
1389    selecting and representing this response.  The value consists of
1390    either a single asterisk ("*") or a list of header field names (case-
1391    insensitive).
1392
1393NEW:
1394
1395    The "Vary" header field in a response describes what parts of a
1396    request message, aside from the method, Host header field, and
1397    request target, might influence the origin server's process for
1398    selecting and representing this response.  The value consists of
1399    either a single asterisk ("*") or a list of header field names (case
1400    insensitive).
1401
1402
1403Section 1., paragraph 1:
1404OLD:
1405
1406    2.  To inform user agent recipients that this response is subject to
1407        content negotiation (Section 5.3) and that a different
1408        representation might be sent in a subsequent request if
1409        additional parameters are provided in the listed header fields
1410        (proactive negotiation).
1411
1412NEW:
1413
1414    2.  To inform user-agent recipients that this response is subject to
1415        content negotiation (Section 5.3) and that a different
1416        representation might be sent in a subsequent request if
1417        additional parameters are provided in the listed header fields
1418        (proactive negotiation).
1419
1420
1421Section 7.2., paragraph 3:
1422OLD:
1423
1424    For example, an ETag header field in a 201 response communicates the
1425    entity-tag of the newly created resource's representation, so that it
1426    can be used in later conditional requests to prevent the "lost
1427    update" problem [RFC7232].
1428
1429NEW:
1430
1431    For example, an ETag header field in a 201 (Created) response
1432    communicates the entity-tag of the newly created resource's
1433    representation, so that it can be used in later conditional requests
1434    to prevent the "lost update" problem [RFC7232].
1435
1436
1437Section 8.1., paragraph 1:
1438OLD:
1439
1440    The HTTP Method Registry defines the name space for the request
1441    method token (Section 4).  The method registry will be created and
1442    maintained at (the suggested URI)
1443    <http://www.iana.org/assignments/http-methods>.
1444
1445NEW:
1446
1447    The "Hypertext Transfer Protocol (HTTP) Method Registry" defines the
1448    namespace for the request method token (Section 4).  The "HTTP Method
1449    Registry" has been created and is now maintained at
1450    <http://www.iana.org/assignments/http-methods>.
1451
1452
1453Section 8.1.2., paragraph 3:
1454OLD:
1455
1456    A new method definition needs to indicate whether it is safe
1457    (Section 4.2.1), idempotent (Section 4.2.2), cacheable
1458    (Section 4.2.3), what semantics are to be associated with the payload
1459    body if any is present in the request, and what refinements the
1460    method makes to header field or status code semantics.  If the new
1461    method is cacheable, its definition ought to describe how, and under
1462    what conditions, a cache can store a response and use it to satisfy a
1463    subsequent request.  The new method ought to describe whether it can
1464    be made conditional (Section 5.2) and, if so, how a server responds
1465    when the condition is false.  Likewise, if the new method might have
1466    some use for partial response semantics ([RFC7233]), it ought to
1467    document this, too.
1468
1469NEW:
1470
1471    A new method definition needs to indicate whether it is safe
1472    (Section 4.2.1), idempotent (Section 4.2.2), or cacheable
1473    (Section 4.2.3).  It needs to indicate what semantics are to be
1474    associated with the payload body if any is present in the request and
1475    what refinements the method makes to header field or status code
1476    semantics.  If the new method is cacheable, its definition ought to
1477    describe how, and under what conditions, a cache can store a response
1478    and use it to satisfy a subsequent request.  The new method ought to
1479    describe whether it can be made conditional (Section 5.2) and, if so,
1480    how a server responds when the condition is false.  Likewise, if the
1481    new method might have some use for partial response semantics
1482    ([RFC7233]), it ought to document this, too.
1483
1484
1485Section 8.1.3., paragraph 1:
1486OLD:
1487
1488    The HTTP Method Registry shall be populated with the registrations
1489    below:
1490
1491NEW:
1492
1493    The "Hypertext Transfer Protocol (HTTP) Method Registry" has been
1494    populated with the registrations below:
1495
1496
1497Section 8.2., paragraph 1:
1498OLD:
1499
1500    The HTTP Status Code Registry defines the name space for the response
1501    status-code token (Section 6).  The status code registry is
1502    maintained at <http://www.iana.org/assignments/http-status-codes>.
1503
1504NEW:
1505
1506    The "Hypertext Transfer Protocol (HTTP) Status Code Registry" defines
1507    the namespace for the response status-code token (Section 6).  The
1508    "HTTP Status Codes" registry is maintained at
1509    <http://www.iana.org/assignments/http-status-codes>.
1510
1511
1512Section 8.2., paragraph 2:
1513OLD:
1514
1515    This Section replaces the registration procedure for HTTP Status
1516    Codes previously defined in Section 7.1 of [RFC2817].
1517
1518NEW:
1519
1520    This section replaces the registration procedure for HTTP Status
1521    Codes previously defined in Section 7.1 of [RFC2817].
1522
1523
1524Section 8.2.3., paragraph 1:
1525OLD:
1526
1527    The HTTP Status Code Registry shall be updated with the registrations
1528    below:
1529
1530NEW:
1531
1532    The "HTTP Status Codes" registry has been updated with the
1533    registrations below:
1534
1535
1536Section 8.3., paragraph 1:
1537OLD:
1538
1539    HTTP header fields are registered within the Message Header Field
1540    Registry located at <http://www.iana.org/assignments/message-headers/
1541    message-header-index.html>, as defined by [BCP90].
1542
1543NEW:
1544
1545    HTTP header fields are registered within the "Message Headers"
1546    registry located at <http://www.iana.org/assignments/message-headers>
1547    as defined by [BCP90].
1548
1549
1550Section 8.3.1., paragraph 3:
1551OLD:
1552
1553    Authors of specifications defining new fields are advised to keep the
1554    name as short as practical and to not prefix the name with "X-"
1555    unless the header field will never be used on the Internet.  (The
1556    "x-" prefix idiom has been extensively misused in practice; it was
1557    intended to only be used as a mechanism for avoiding name collisions
1558    inside proprietary software or intranet processing, since the prefix
1559    would ensure that private names never collide with a newly registered
1560    Internet name; see [BCP178] for further information)
1561
1562NEW:
1563
1564    Authors of specifications defining new fields are advised to keep the
1565    name as short as practical and not to prefix the name with "X-"
1566    unless the header field will never be used on the Internet.  (The
1567    "X-" prefix idiom has been extensively misused in practice; it was
1568    intended to only be used as a mechanism for avoiding name collisions
1569    inside proprietary software or intranet processing, since the prefix
1570    would ensure that private names never collide with a newly registered
1571    Internet name; see [BCP178] for further information).
1572
1573
1574Section 8.3.1., paragraph 4:
1575OLD:
1576
1577    New header field values typically have their syntax defined using
1578    ABNF ([RFC5234]), using the extension defined in Section 7 of
1579    [RFC7230] as necessary, and are usually constrained to the range of
1580    ASCII characters.  Header fields needing a greater range of
1581    characters can use an encoding such as the one defined in [RFC5987].
1582
1583NEW:
1584
1585    New header field values typically have their syntax defined using
1586    ABNF ([RFC5234]) (implementing the extension defined in Section 7 of
1587    [RFC7230] as necessary), and they are usually constrained to the
1588    range of ASCII characters.  Header fields needing a greater range of
1589    characters can use an encoding such as the one defined in [RFC5987].
1590
1591
1592Section 8.3.2., paragraph 1:
1593OLD:
1594
1595    The Message Header Field Registry shall be updated with the following
1596    permanent registrations:
1597
1598NEW:
1599
1600    The "Message Headers" registry has been updated with the following
1601    permanent registrations:
1602
1603
1604Section 8.4., paragraph 1:
1605OLD:
1606
1607    The HTTP Content Coding Registry defines the name space for content
1608    coding names (Section 4.2 of [RFC7230]).  The content coding registry
1609    is maintained at <http://www.iana.org/assignments/http-parameters>.
1610
1611NEW:
1612
1613    The "HTTP Content Coding Registry" defines the namespace for content
1614    coding names (Section 4.2 of [RFC7230]).  The "HTTP Content Coding
1615    Registry" is maintained at
1616    <http://www.iana.org/assignments/http-parameters>.
1617
1618
1619Section 8.4.1., paragraph 1:
1620OLD:
1621
1622    Content Coding registrations MUST include the following fields:
1623
1624NEW:
1625
1626    Content coding registrations MUST include the following fields:
1627
1628
1629Section 8.4.1., paragraph 6:
1630OLD:
1631
1632    Values to be added to this name space require IETF Review (see
1633    Section 4.1 of [RFC5226]), and MUST conform to the purpose of content
1634    coding defined in this section.
1635
1636NEW:
1637
1638    Values to be added to this namespace require IETF Review (see Section
1639    4.1 of [RFC5226]) and MUST conform to the purpose of content coding
1640    defined in this section.
1641
1642
1643Section 8.4.2., paragraph 1:
1644OLD:
1645
1646    The HTTP Content Codings Registry shall be updated with the
1647    registrations below:
1648
1649NEW:
1650
1651    The "HTTP Content Codings Registry" has been updated with the
1652    registrations below:
1653
1654
1655Section 9., paragraph 2:
1656OLD:
1657
1658    The list of considerations below is not exhaustive.  Most security
1659    concerns related to HTTP semantics are about securing server-side
1660    applications (code behind the HTTP interface), securing user agent
1661    processing of payloads received via HTTP, or secure use of the
1662    Internet in general, rather than security of the protocol.  Various
1663    organizations maintain topical information and links to current
1664    research on Web application security (e.g., [OWASP]).
1665
1666NEW:
1667
1668    The list of considerations below is not exhaustive.  Most security
1669    concerns related to HTTP semantics are about securing server-side
1670    applications (code behind the HTTP interface) or securing user-agent
1671    processing of payloads received via HTTP.  Secure use of the Internet
1672    in general, rather than security of the protocol, might also be
1673    related.  Various organizations maintain topical information and
1674    links to current research on Web application security (e.g.,
1675    [OWASP]).
1676
1677
1678Section 9.1., paragraph 2:
1679OLD:
1680
1681    For example, UNIX, Microsoft Windows, and other operating systems use
1682    ".." as a path component to indicate a directory level above the
1683    current one, and use specially named paths or file names to send data
1684    to system devices.  Similar naming conventions might exist within
1685    other types of storage systems.  Likewise, local storage systems have
1686    an annoying tendency to prefer user-friendliness over security when
1687    handling invalid or unexpected characters, recomposition of
1688    decomposed characters, and case-normalization of case-insensitive
1689    names.
1690
1691NEW:
1692
1693    For example, UNIX, Microsoft Windows, and other operating systems use
1694    ".." as a path component to indicate a directory level above the
1695    current one, and they use specially named paths or file names to send
1696    data to system devices.  Similar naming conventions might exist
1697    within other types of storage systems.  Likewise, local storage
1698    systems have an annoying tendency to prefer user-friendliness over
1699    security when handling invalid or unexpected characters,
1700    recomposition of decomposed characters, and case-normalization of
1701    case-insensitive names.
1702
1703
1704Section 9.1., paragraph 3:
1705OLD:
1706
1707    Attacks based on such special names tend to focus on either denial-
1708    of-service (e.g., telling the server to read from a COM port) or
1709    disclosure of configuration and source files that are not meant to be
1710    served.
1711
1712NEW:
1713
1714    Attacks based on such special names tend to focus on either denial of
1715    service (e.g., telling the server to read from a COM port) or
1716    disclosure of configuration and source files that are not meant to be
1717    served.
1718
1719
1720Section 9.4., paragraph 3:
1721OLD:
1722
1723    Since the Referer header field tells a target site about the context
1724    that resulted in a request, it has the potential to reveal
1725    information about the user's immediate browsing history and any
1726    personal information that might be found in the referring resource's
1727    URI.  Limitations on Referer are described in Section 5.5.2 to
1728    address some of its security considerations.
1729
1730NEW:
1731
1732    Since the Referer header field tells a target site about the context
1733    that resulted in a request, it has the potential to reveal
1734    information about the user's immediate browsing history and any
1735    personal information that might be found in the referring resource's
1736    URI.  Limitations on the Referer header field are described in
1737    Section 5.5.2 to address some of its security considerations.
1738
1739
1740Section 11.1., paragraph 9:
1741OLD:
1742
1743    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1744               Protocol (HTTP/1.1): Message Syntax and Routing",
1745               draft-ietf-httpbis-p1-messaging-latest (work in progress),
1746               May 2014.
1747
1748NEW:
1749
1750    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1751               Protocol (HTTP/1.1): Message Syntax and Routing",
1752               RFC 7230, May 2014.
1753
1754
1755Section 11.1., paragraph 10:
1756OLD:
1757
1758    [RFC7232]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1759               Protocol (HTTP/1.1): Conditional Requests",
1760               draft-ietf-httpbis-p4-conditional-latest (work in
1761               progress), May 2014.
1762
1763NEW:
1764
1765    [RFC7232]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1766               Protocol (HTTP/1.1): Conditional Requests", RFC 7232,
1767               May 2014.
1768
1769
1770Section 11.1., paragraph 11:
1771OLD:
1772
1773    [RFC7233]  Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
1774               "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
1775               draft-ietf-httpbis-p5-range-latest (work in progress),
1776               May 2014.
1777
1778NEW:
1779
1780    [RFC7233]  Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
1781               "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
1782               RFC 7233, May 2014.
1783
1784
1785Section 11.1., paragraph 12:
1786OLD:
1787
1788    [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1789               Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
1790               draft-ietf-httpbis-p6-cache-latest (work in progress),
1791               May 2014.
1792
1793NEW:
1794
1795    [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1796               Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
1797               RFC 7234, May 2014.
1798
1799
1800Section 11.1., paragraph 13:
1801OLD:
1802
1803    [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1804               Protocol (HTTP/1.1): Authentication",
1805               draft-ietf-httpbis-p7-auth-latest (work in progress),
1806               May 2014.
1807
1808NEW:
1809
1810    [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1811               Protocol (HTTP/1.1): Authentication", RFC 7235, May 2014.
1812
1813
1814Section 11.2., paragraph 25:
1815OLD:
1816
1817    [RFC7238]  Reschke, J., "The Hypertext Transfer Protocol (HTTP)
1818               Status Code 308 (Permanent Redirect)",
1819               draft-reschke-http-status-308-07 (work in progress),
1820               March 2012.
1821
1822NEW:
1823
1824    [RFC7238]  Reschke, J., "The Hypertext Transfer Protocol (HTTP)
1825               Status Code 308 (Permanent Redirect)", RFC 7238, May 2014.
1826
1827
1828Appendix A., paragraph 1:
1829OLD:
1830
1831    HTTP/1.1 uses many of the constructs defined for the Internet Message
1832    Format [RFC5322] and the Multipurpose Internet Mail Extensions (MIME)
1833    [RFC2045] to allow a message body to be transmitted in an open
1834    variety of representations and with extensible header fields.
1835    However, RFC 2045 is focused only on email; applications of HTTP have
1836    many characteristics that differ from email, and hence HTTP has
1837    features that differ from MIME.  These differences were carefully
1838    chosen to optimize performance over binary connections, to allow
1839    greater freedom in the use of new media types, to make date
1840    comparisons easier, and to acknowledge the practice of some early
1841    HTTP servers and clients.
1842
1843NEW:
1844
1845    HTTP/1.1 uses many of the constructs defined for the Internet Message
1846    Format [RFC5322] and the Multipurpose Internet Mail Extensions (MIME)
1847    [RFC2045] to allow a message body to be transmitted in an open
1848    variety of representations and with extensible header fields.
1849    However, RFC 2045 is focused only on email; applications of HTTP have
1850    many characteristics that differ from email; hence, HTTP has features
1851    that differ from MIME.  These differences were carefully chosen to
1852    optimize performance over binary connections, to allow greater
1853    freedom in the use of new media types, to make date comparisons
1854    easier, and to acknowledge the practice of some early HTTP servers
1855    and clients.
1856
1857
1858Appendix A., paragraph 16:
1859OLD:
1860
1861 A.6.  MHTML and Line Length Limitations
1862
1863NEW:
1864
1865 A.6.  MHTML and Line-Length Limitations
1866
1867
1868Appendix A., paragraph 17:
1869OLD:
1870
1871    HTTP implementations that share code with MHTML [RFC2557]
1872    implementations need to be aware of MIME line length limitations.
1873    Since HTTP does not have this limitation, HTTP does not fold long
1874    lines.  MHTML messages being transported by HTTP follow all
1875    conventions of MHTML, including line length limitations and folding,
1876    canonicalization, etc., since HTTP transfers message-bodies as
1877    payload and, aside from the "multipart/byteranges" type (Appendix A
1878    of [RFC7233]), does not interpret the content or any MIME header
1879    lines that might be contained therein.
1880
1881NEW:
1882
1883    HTTP implementations that share code with MHTML [RFC2557]
1884    implementations need to be aware of MIME line-length limitations.
1885    Since HTTP does not have this limitation, HTTP does not fold long
1886    lines.  MHTML messages being transported by HTTP follow all
1887    conventions of MHTML, including line-length limitations and folding,
1888    canonicalization, etc., since HTTP transfers message-bodies as
1889    payload and, aside from the "multipart/byteranges" type (Appendix A
1890    of [RFC7233]), does not interpret the content or any MIME header
1891    lines that might be contained therein.
1892
1893
1894Appendix B., paragraph 2:
1895OLD:
1896
1897    A new requirement has been added that semantics embedded in a URI
1898    should be disabled when those semantics are inconsistent with the
1899    request method, since this is a common cause of interoperability
1900    failure.  (Section 2)
1901
1902NEW:
1903
1904    A new requirement has been added that semantics embedded in a URI be
1905    disabled when those semantics are inconsistent with the request
1906    method, since this is a common cause of interoperability failure
1907    (Section 2).
1908
1909
1910Appendix B., paragraph 3:
1911OLD:
1912
1913    An algorithm has been added for determining if a payload is
1914    associated with a specific identifier.  (Section 3.1.4.1)
1915
1916NEW:
1917
1918    An algorithm has been added for determining if a payload is
1919    associated with a specific identifier (Section 3.1.4.1).
1920
1921
1922Appendix B., paragraph 4:
1923OLD:
1924
1925    The default charset of ISO-8859-1 for text media types has been
1926    removed; the default is now whatever the media type definition says.
1927    Likewise, special treatment of ISO-8859-1 has been removed from the
1928    Accept-Charset header field.  (Section 3.1.1.3 and Section 5.3.3)
1929
1930NEW:
1931
1932    The default charset of ISO-8859-1 for text media types has been
1933    removed; the default is now whatever the media type definition says.
1934    Likewise, special treatment of ISO-8859-1 has been removed from the
1935    Accept-Charset header field.  (Sections 3.1.1.3 and 5.3.3.)
1936
1937
1938Appendix B., paragraph 5:
1939OLD:
1940
1941    The definition of Content-Location has been changed to no longer
1942    affect the base URI for resolving relative URI references, due to
1943    poor implementation support and the undesirable effect of potentially
1944    breaking relative links in content-negotiated resources.
1945    (Section 3.1.4.2)
1946
1947NEW:
1948
1949    The definition of Content-Location has been changed to no longer
1950    affect the base URI for resolving relative URI references, due to
1951    poor implementation support and the undesirable effect of potentially
1952    breaking relative links in content-negotiated resources
1953    (Section 3.1.4.2).
1954
1955
1956Appendix B., paragraph 6:
1957OLD:
1958
1959    To be consistent with the method-neutral parsing algorithm of
1960    [RFC7230], the definition of GET has been relaxed so that requests
1961    can have a body, even though a body has no meaning for GET.
1962    (Section 4.3.1)
1963
1964NEW:
1965
1966    To be consistent with the method-neutral parsing algorithm of
1967    [RFC7230], the definition of GET has been relaxed so that requests
1968    can have a body, even though a body has no meaning for GET
1969    (Section 4.3.1).
1970
1971
1972Appendix B., paragraph 7:
1973OLD:
1974
1975    Servers are no longer required to handle all Content-* header fields
1976    and use of Content-Range has been explicitly banned in PUT requests.
1977    (Section 4.3.4)
1978
1979NEW:
1980
1981    Servers are no longer required to handle all Content-* header fields
1982    and use of Content-Range has been explicitly banned in PUT requests
1983    (Section 4.3.4).
1984
1985
1986Appendix B., paragraph 8:
1987OLD:
1988
1989    Definition of the CONNECT method has been moved from [RFC2817] to
1990    this specification.  (Section 4.3.6)
1991
1992NEW:
1993
1994    Definition of the CONNECT method has been moved from [RFC2817] to
1995    this specification (Section 4.3.6).
1996
1997
1998Appendix B., paragraph 9:
1999OLD:
2000
2001    The OPTIONS and TRACE request methods have been defined as being
2002    safe.  (Section 4.3.7 and Section 4.3.8)
2003
2004NEW:
2005
2006    The OPTIONS and TRACE request methods have been defined as being safe
2007    (Section 4.3.7 and Section 4.3.8).
2008
2009
2010Appendix B., paragraph 10:
2011OLD:
2012
2013    The Expect header field's extension mechanism has been removed due to
2014    widely-deployed broken implementations.  (Section 5.1.1)
2015
2016NEW:
2017
2018    The Expect header field's extension mechanism has been removed due to
2019    widely deployed broken implementations (Section 5.1.1).
2020
2021
2022Appendix B., paragraph 11:
2023OLD:
2024
2025    The Max-Forwards header field has been restricted to the OPTIONS and
2026    TRACE methods; previously, extension methods could have used it as
2027    well.  (Section 5.1.2)
2028
2029NEW:
2030
2031    The Max-Forwards header field has been restricted to the OPTIONS and
2032    TRACE methods; previously, extension methods could have used it as
2033    well (Section 5.1.2).
2034
2035
2036Appendix B., paragraph 12:
2037OLD:
2038
2039    The "about:blank" URI has been suggested as a value for the Referer
2040    header field when no referring URI is applicable, which distinguishes
2041    that case from others where the Referer field is not sent or has been
2042    removed.  (Section 5.5.2)
2043
2044NEW:
2045
2046    The "about:blank" URI has been suggested as a value for the Referer
2047    header field when no referring URI is applicable, which distinguishes
2048    that case from others where the Referer field is not sent or has been
2049    removed (Section 5.5.2).
2050
2051
2052Appendix B., paragraph 13:
2053OLD:
2054
2055    The following status codes are now cacheable (that is, they can be
2056    stored and reused by a cache without explicit freshness information
2057    present): 204, 404, 405, 414, 501.  (Section 6)
2058
2059NEW:
2060
2061    The following status codes are now cacheable (that is, they can be
2062    stored and reused by a cache without explicit freshness information
2063    present): 204, 404, 405, 414, 501 (Section 6).
2064
2065
2066Appendix B., paragraph 14:
2067OLD:
2068
2069    The 201 (Created) status description has been changed to allow for
2070    the possibility that more than one resource has been created.
2071    (Section 6.3.2)
2072
2073NEW:
2074
2075    The 201 (Created) status description has been changed to allow for
2076    the possibility that more than one resource has been created
2077    (Section 6.3.2).
2078
2079
2080Appendix B., paragraph 15:
2081OLD:
2082
2083    The definition of 203 (Non-Authoritative Information) has been
2084    broadened to include cases of payload transformations as well.
2085    (Section 6.3.4)
2086
2087NEW:
2088
2089    The definition of 203 (Non-Authoritative Information) has been
2090    broadened to include cases of payload transformations as well
2091    (Section 6.3.4).
2092
2093
2094Appendix B., paragraph 16:
2095OLD:
2096
2097    The set of request methods that are safe to automatically redirect is
2098    no longer closed; user agents are able to make that determination
2099    based upon the request method semantics.  The redirect status codes
2100    301, 302, and 307 no longer have normative requirements on response
2101    payloads and user interaction.  (Section 6.4)
2102
2103NEW:
2104
2105    The set of request methods that are safe to automatically redirect is
2106    no longer closed; user agents are able to make that determination
2107    based upon the request method semantics.  The redirect status codes
2108    301, 302, and 307 no longer have normative requirements on response
2109    payloads and user interaction (Section 6.4).
2110
2111
2112Appendix B., paragraph 17:
2113OLD:
2114
2115    The status codes 301 and 302 have been changed to allow user agents
2116    to rewrite the method from POST to GET.  (Sections 6.4.2 and 6.4.3)
2117
2118NEW:
2119
2120    The status codes 301 and 302 have been changed to allow user agents
2121    to rewrite the method from POST to GET.  (Sections 6.4.2 and 6.4.3.)
2122
2123
2124Appendix B., paragraph 18:
2125OLD:
2126
2127    The description of 303 (See Other) status code has been changed to
2128    allow it to be cached if explicit freshness information is given, and
2129    a specific definition has been added for a 303 response to GET.
2130    (Section 6.4.4)
2131
2132NEW:
2133
2134    The description of the 303 (See Other) status code has been changed
2135    to allow it to be cached if explicit freshness information is given,
2136    and a specific definition has been added for a 303 response to GET
2137    (Section 6.4.4).
2138
2139
2140Appendix B., paragraph 19:
2141OLD:
2142
2143    The 305 (Use Proxy) status code has been deprecated due to security
2144    concerns regarding in-band configuration of a proxy.  (Section 6.4.5)
2145
2146NEW:
2147
2148    The 305 (Use Proxy) status code has been deprecated due to security
2149    concerns regarding in-band configuration of a proxy (Section 6.4.5).
2150
2151
2152Appendix B., paragraph 20:
2153OLD:
2154
2155    The 400 (Bad Request) status code has been relaxed so that it isn't
2156    limited to syntax errors.  (Section 6.5.1)
2157
2158NEW:
2159
2160    The 400 (Bad Request) status code has been relaxed so that it isn't
2161    limited to syntax errors (Section 6.5.1).
2162
2163
2164Appendix B., paragraph 21:
2165OLD:
2166
2167    The 426 (Upgrade Required) status code has been incorporated from
2168    [RFC2817].  (Section 6.5.15)
2169
2170NEW:
2171
2172    The 426 (Upgrade Required) status code has been incorporated from
2173    [RFC2817] (Section 6.5.15).
2174
2175
2176Appendix B., paragraph 22:
2177OLD:
2178
2179    The target of requirements on HTTP-date and the Date header field
2180    have been reduced to those systems generating the date, rather than
2181    all systems sending a date.  (Section 7.1.1)
2182
2183NEW:
2184
2185    The target of requirements on HTTP-date and the Date header field
2186    have been reduced to those systems generating the date, rather than
2187    all systems sending a date (Section 7.1.1).
2188
2189
2190Appendix B., paragraph 23:
2191OLD:
2192
2193    The syntax of the Location header field has been changed to allow all
2194    URI references, including relative references and fragments, along
2195    with some clarifications as to when use of fragments would not be
2196    appropriate.  (Section 7.1.2)
2197
2198NEW:
2199
2200    The syntax of the Location header field has been changed to allow all
2201    URI references, including relative references and fragments, along
2202    with some clarifications as to when use of fragments would not be
2203    appropriate (Section 7.1.2).
2204
2205
2206Appendix B., paragraph 24:
2207OLD:
2208
2209    Allow has been reclassified as a response header field, removing the
2210    option to specify it in a PUT request.  Requirements relating to the
2211    content of Allow have been relaxed; correspondingly, clients are not
2212    required to always trust its value.  (Section 7.4.1)
2213
2214NEW:
2215
2216    Allow has been reclassified as a response header field, removing the
2217    option to specify it in a PUT request.  Requirements relating to the
2218    content of Allow have been relaxed; correspondingly, clients are not
2219    required to always trust its value (Section 7.4.1).
2220
2221
2222Appendix B., paragraph 25:
2223OLD:
2224
2225    A Method Registry has been defined.  (Section 8.1)
2226
2227NEW:
2228
2229    A Method Registry has been defined (Section 8.1).
2230
2231
2232Appendix B., paragraph 26:
2233OLD:
2234
2235    The Status Code Registry has been redefined by this specification;
2236    previously, it was defined in Section 7.1 of [RFC2817].
2237 
2238    (Section 8.2)
2239
2240NEW:
2241
2242    The Status Code Registry has been redefined by this specification;
2243    previously, it was defined in Section 7.1 of [RFC2817] (Section 8.2).
2244
2245
2246Appendix B., paragraph 27:
2247OLD:
2248
2249    Registration of Content Codings has been changed to require IETF
2250    Review.  (Section 8.4)
2251
2252NEW:
2253
2254    Registration of content codings has been changed to require IETF
2255    Review (Section 8.4).
2256
2257
2258Section 1.2, paragraph 1:
2259OLD:
2260
2261    Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
2262     OWS ( media-range [ accept-params ] ) ] ) ]
2263    Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS
2264     "," [ OWS ( ( charset / "*" ) [ weight ] ) ] )
2265    Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS
2266     ( codings [ weight ] ) ] ) ]
2267    Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS
2268     "," [ OWS ( language-range [ weight ] ) ] )
2269    Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ]
2270    BWS = <BWS, defined in [RFC7230], Section 3.2.3>
2271
2272NEW:
2273
2274    Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
2275     OWS ( media-range [ accept-params ] ) ] ) ]
2276    Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS
2277     "," [ OWS ( ( charset / "*" ) [ weight ] ) ] )
2278    Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS
2279     ( codings [ weight ] ) ] ) ]
2280    Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS
2281     "," [ OWS ( language-range [ weight ] ) ] )
2282    Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ]
2283 
2284    BWS = <BWS, defined in [RFC7230], Section 3.2.3>
2285
2286
2287Section 1.2, paragraph 2:
2288OLD:
2289
2290    Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS
2291     content-coding ] )
2292    Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS
2293     language-tag ] )
2294    Content-Location = absolute-URI / partial-URI
2295    Content-Type = media-type
2296 
2297    Date = HTTP-date
2298
2299NEW:
2300
2301    Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS
2302     content-coding ] )
2303    Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS
2304     language-tag ] )
2305    Content-Location = absolute-URI / partial-URI
2306    Content-Type = media-type
2307    Date = HTTP-date
2308
2309
2310Section 1.2, paragraph 16:
2311OLD:
2312
2313    charset = token
2314    codings = content-coding / "identity" / "*"
2315    comment = <comment, defined in [RFC7230], Section 3.2.6>
2316    content-coding = token
2317    date1 = day SP month SP year
2318    date2 = day "-" month "-" 2DIGIT
2319    date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
2320    day = 2DIGIT
2321    day-name = %x4D.6F.6E ; Mon
2322     / %x54.75.65 ; Tue
2323     / %x57.65.64 ; Wed
2324     / %x54.68.75 ; Thu
2325     / %x46.72.69 ; Fri
2326     / %x53.61.74 ; Sat
2327     / %x53.75.6E ; Sun
2328    day-name-l = %x4D.6F.6E.64.61.79 ; Monday
2329     / %x54.75.65.73.64.61.79 ; Tuesday
2330     / %x57.65.64.6E.65.73.64.61.79 ; Wednesday
2331     / %x54.68.75.72.73.64.61.79 ; Thursday
2332     / %x46.72.69.64.61.79 ; Friday
2333     / %x53.61.74.75.72.64.61.79 ; Saturday
2334     / %x53.75.6E.64.61.79 ; Sunday
2335    delay-seconds = 1*DIGIT
2336
2337NEW:
2338
2339    charset = token
2340    codings = content-coding / "identity" / "*"
2341    comment = <comment, defined in [RFC7230], Section 3.2.6>
2342    content-coding = token
2343 
2344    date1 = day SP month SP year
2345    date2 = day "-" month "-" 2DIGIT
2346    date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
2347    day = 2DIGIT
2348    day-name = %x4D.6F.6E ; Mon
2349     / %x54.75.65 ; Tue
2350     / %x57.65.64 ; Wed
2351     / %x54.68.75 ; Thu
2352     / %x46.72.69 ; Fri
2353     / %x53.61.74 ; Sat
2354     / %x53.75.6E ; Sun
2355    day-name-l = %x4D.6F.6E.64.61.79 ; Monday
2356     / %x54.75.65.73.64.61.79 ; Tuesday
2357     / %x57.65.64.6E.65.73.64.61.79 ; Wednesday
2358     / %x54.68.75.72.73.64.61.79 ; Thursday
2359     / %x46.72.69.64.61.79 ; Friday
2360     / %x53.61.74.75.72.64.61.79 ; Saturday
2361     / %x53.75.6E.64.61.79 ; Sunday
2362    delay-seconds = 1*DIGIT
2363
2364
2365Section 1.2, paragraph 21:
2366OLD:
2367
2368    obs-date = rfc850-date / asctime-date
2369    parameter = token "=" ( token / quoted-string )
2370    partial-URI = <partial-URI, defined in [RFC7230], Section 2.7>
2371    product = token [ "/" product-version ]
2372    product-version = token
2373 
2374    quoted-string = <quoted-string, defined in [RFC7230], Section 3.2.6>
2375    qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
2376
2377NEW:
2378
2379    obs-date = rfc850-date / asctime-date
2380 
2381    parameter = token "=" ( token / quoted-string )
2382    partial-URI = <partial-URI, defined in [RFC7230], Section 2.7>
2383    product = token [ "/" product-version ]
2384    product-version = token
2385    quoted-string = <quoted-string, defined in [RFC7230], Section 3.2.6>
2386    qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
2387
2388
2389Section 1.2, paragraph 47:
2390OLD:
2391
2392    M
2393       Max-Forwards header field  36
2394       MIME-Version header field  89
2395
2396NEW:
2397
2398    M
2399       Max-Forwards header field  36
2400       MIME-Version header field  88
2401
2402
2403Section 345, paragraph 1:
2404OLD:
2405
2406    EMail: fielding@gbiv.com
2407    URI:   http://roy.gbiv.com/
2408    Julian F. Reschke (editor)
2409    greenbytes GmbH
2410    Hafenweg 16
2411    Muenster, NW  48155
2412    Germany
2413
2414NEW:
2415
2416    EMail: fielding@gbiv.com
2417    URI:   http://roy.gbiv.com/
2418 
2419    Julian F. Reschke (editor)
2420    greenbytes GmbH
2421    Hafenweg 16
2422    Muenster, NW  48155
2423    Germany
2424
Note: See TracBrowser for help on using the repository browser.