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

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

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

File size: 71.1 KB
Line 
1
2INTRODUCTION, paragraph 1:
3OLD:
4
5 HTTPbis Working Group                                   R. Fielding, Ed.
6 Internet-Draft                                                     Adobe
7 Obsoletes: 2616 (if approved)                            J. Reschke, Ed.
8 Updates: 2817 (if approved)                                   greenbytes
9 Intended status: Standards Track                             May 8, 2014
10 Expires: November 9, 2014
11
12NEW:
13
14 Internet Engineering Task Force (IETF)                  R. Fielding, Ed.
15 Request for Comments: 7231                                         Adobe
16 Obsoletes: 2616                                          J. Reschke, Ed.
17 Updates: 2817                                                 greenbytes
18 Category: Standards Track                                       May 2014
19 ISSN: 2070-1721
20
21
22INTRODUCTION, paragraph 2:
23OLD:
24
25      Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
26                  draft-ietf-httpbis-p2-semantics-latest
27
28NEW:
29
30      Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
31
32
33INTRODUCTION, paragraph 5:
34OLD:
35
36 Editorial Note (To be removed by RFC Editor)
37 
38    Discussion of this draft takes place on the HTTPBIS working group
39    mailing list (ietf-http-wg@w3.org), which is archived at
40    <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
41 
42    The current issues list is at
43    <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
44    documents (including fancy diffs) can be found at
45    <http://tools.ietf.org/wg/httpbis/>.
46 
47    _This is a temporary document for the purpose of tracking the
48    editorial changes made during the AUTH48 (RFC publication) phase._
49 
50 Status of This Memo
51
52NEW:
53
54 Status of This Memo
55
56
57INTRODUCTION, paragraph 6:
58OLD:
59
60    This Internet-Draft is submitted in full conformance with the
61    provisions of BCP 78 and BCP 79.
62 
63    Internet-Drafts are working documents of the Internet Engineering
64    Task Force (IETF).  Note that other groups may also distribute
65    working documents as Internet-Drafts.  The list of current Internet-
66    Drafts is at http://datatracker.ietf.org/drafts/current/.
67
68NEW:
69
70    This is an Internet Standards Track document.
71
72
73INTRODUCTION, paragraph 7:
74OLD:
75
76    Internet-Drafts are draft documents valid for a maximum of six months
77    and may be updated, replaced, or obsoleted by other documents at any
78    time.  It is inappropriate to use Internet-Drafts as reference
79    material or to cite them other than as "work in progress."
80
81NEW:
82
83    This document is a product of the Internet Engineering Task Force
84    (IETF).  It represents the consensus of the IETF community.  It has
85    received public review and has been approved for publication by the
86    Internet Engineering Steering Group (IESG).  Further information on
87    Internet Standards is available in Section 2 of RFC 5741.
88
89
90INTRODUCTION, paragraph 8:
91OLD:
92
93    This Internet-Draft will expire on November 9, 2014.
94
95NEW:
96
97    Information about the current status of this document, any errata,
98    and how to provide feedback on it may be obtained at
99    http://www.rfc-editor.org/info/rfc7231.
100
101
102Section 11., paragraph 0:
103OLD:
104
105    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  6
106      1.1.  Conformance and Error Handling . . . . . . . . . . . . . .  6
107      1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  6
108    2.  Resources  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
109    3.  Representations  . . . . . . . . . . . . . . . . . . . . . . .  7
110      3.1.  Representation Metadata  . . . . . . . . . . . . . . . . .  8
111        3.1.1.  Processing Representation Data . . . . . . . . . . . .  8
112        3.1.2.  Encoding for Compression or Integrity  . . . . . . . . 11
113        3.1.3.  Audience Language  . . . . . . . . . . . . . . . . . . 13
114        3.1.4.  Identification . . . . . . . . . . . . . . . . . . . . 14
115      3.2.  Representation Data  . . . . . . . . . . . . . . . . . . . 17
116      3.3.  Payload Semantics  . . . . . . . . . . . . . . . . . . . . 17
117      3.4.  Content Negotiation  . . . . . . . . . . . . . . . . . . . 18
118        3.4.1.  Proactive Negotiation  . . . . . . . . . . . . . . . . 19
119        3.4.2.  Reactive Negotiation . . . . . . . . . . . . . . . . . 20
120 
121    4.  Request Methods  . . . . . . . . . . . . . . . . . . . . . . . 21
122      4.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . 21
123      4.2.  Common Method Properties . . . . . . . . . . . . . . . . . 22
124        4.2.1.  Safe Methods . . . . . . . . . . . . . . . . . . . . . 22
125        4.2.2.  Idempotent Methods . . . . . . . . . . . . . . . . . . 23
126        4.2.3.  Cacheable Methods  . . . . . . . . . . . . . . . . . . 24
127      4.3.  Method Definitions . . . . . . . . . . . . . . . . . . . . 24
128        4.3.1.  GET  . . . . . . . . . . . . . . . . . . . . . . . . . 24
129        4.3.2.  HEAD . . . . . . . . . . . . . . . . . . . . . . . . . 25
130        4.3.3.  POST . . . . . . . . . . . . . . . . . . . . . . . . . 25
131        4.3.4.  PUT  . . . . . . . . . . . . . . . . . . . . . . . . . 26
132        4.3.5.  DELETE . . . . . . . . . . . . . . . . . . . . . . . . 29
133        4.3.6.  CONNECT  . . . . . . . . . . . . . . . . . . . . . . . 30
134        4.3.7.  OPTIONS  . . . . . . . . . . . . . . . . . . . . . . . 31
135        4.3.8.  TRACE  . . . . . . . . . . . . . . . . . . . . . . . . 32
136    5.  Request Header Fields  . . . . . . . . . . . . . . . . . . . . 33
137      5.1.  Controls . . . . . . . . . . . . . . . . . . . . . . . . . 33
138        5.1.1.  Expect . . . . . . . . . . . . . . . . . . . . . . . . 34
139        5.1.2.  Max-Forwards . . . . . . . . . . . . . . . . . . . . . 36
140      5.2.  Conditionals . . . . . . . . . . . . . . . . . . . . . . . 36
141      5.3.  Content Negotiation  . . . . . . . . . . . . . . . . . . . 37
142        5.3.1.  Quality Values . . . . . . . . . . . . . . . . . . . . 37
143        5.3.2.  Accept . . . . . . . . . . . . . . . . . . . . . . . . 38
144        5.3.3.  Accept-Charset . . . . . . . . . . . . . . . . . . . . 40
145        5.3.4.  Accept-Encoding  . . . . . . . . . . . . . . . . . . . 41
146        5.3.5.  Accept-Language  . . . . . . . . . . . . . . . . . . . 42
147      5.4.  Authentication Credentials . . . . . . . . . . . . . . . . 43
148      5.5.  Request Context  . . . . . . . . . . . . . . . . . . . . . 44
149        5.5.1.  From . . . . . . . . . . . . . . . . . . . . . . . . . 44
150        5.5.2.  Referer  . . . . . . . . . . . . . . . . . . . . . . . 45
151        5.5.3.  User-Agent . . . . . . . . . . . . . . . . . . . . . . 46
152    6.  Response Status Codes  . . . . . . . . . . . . . . . . . . . . 47
153      6.1.  Overview of Status Codes . . . . . . . . . . . . . . . . . 48
154      6.2.  Informational 1xx  . . . . . . . . . . . . . . . . . . . . 50
155        6.2.1.  100 Continue . . . . . . . . . . . . . . . . . . . . . 50
156        6.2.2.  101 Switching Protocols  . . . . . . . . . . . . . . . 50
157      6.3.  Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 51
158        6.3.1.  200 OK . . . . . . . . . . . . . . . . . . . . . . . . 51
159        6.3.2.  201 Created  . . . . . . . . . . . . . . . . . . . . . 52
160        6.3.3.  202 Accepted . . . . . . . . . . . . . . . . . . . . . 52
161        6.3.4.  203 Non-Authoritative Information  . . . . . . . . . . 52
162        6.3.5.  204 No Content . . . . . . . . . . . . . . . . . . . . 53
163        6.3.6.  205 Reset Content  . . . . . . . . . . . . . . . . . . 53
164      6.4.  Redirection 3xx  . . . . . . . . . . . . . . . . . . . . . 54
165        6.4.1.  300 Multiple Choices . . . . . . . . . . . . . . . . . 55
166        6.4.2.  301 Moved Permanently  . . . . . . . . . . . . . . . . 56
167        6.4.3.  302 Found  . . . . . . . . . . . . . . . . . . . . . . 56
168        6.4.4.  303 See Other  . . . . . . . . . . . . . . . . . . . . 57
169        6.4.5.  305 Use Proxy  . . . . . . . . . . . . . . . . . . . . 57
170        6.4.6.  306 (Unused) . . . . . . . . . . . . . . . . . . . . . 57
171        6.4.7.  307 Temporary Redirect . . . . . . . . . . . . . . . . 58
172      6.5.  Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 58
173        6.5.1.  400 Bad Request  . . . . . . . . . . . . . . . . . . . 58
174        6.5.2.  402 Payment Required . . . . . . . . . . . . . . . . . 58
175        6.5.3.  403 Forbidden  . . . . . . . . . . . . . . . . . . . . 58
176        6.5.4.  404 Not Found  . . . . . . . . . . . . . . . . . . . . 59
177        6.5.5.  405 Method Not Allowed . . . . . . . . . . . . . . . . 59
178        6.5.6.  406 Not Acceptable . . . . . . . . . . . . . . . . . . 59
179        6.5.7.  408 Request Timeout  . . . . . . . . . . . . . . . . . 60
180        6.5.8.  409 Conflict . . . . . . . . . . . . . . . . . . . . . 60
181        6.5.9.  410 Gone . . . . . . . . . . . . . . . . . . . . . . . 60
182        6.5.10. 411 Length Required  . . . . . . . . . . . . . . . . . 61
183        6.5.11. 413 Payload Too Large  . . . . . . . . . . . . . . . . 61
184        6.5.12. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 61
185        6.5.13. 415 Unsupported Media Type . . . . . . . . . . . . . . 61
186        6.5.14. 417 Expectation Failed . . . . . . . . . . . . . . . . 62
187        6.5.15. 426 Upgrade Required . . . . . . . . . . . . . . . . . 62
188      6.6.  Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 62
189        6.6.1.  500 Internal Server Error  . . . . . . . . . . . . . . 62
190        6.6.2.  501 Not Implemented  . . . . . . . . . . . . . . . . . 63
191        6.6.3.  502 Bad Gateway  . . . . . . . . . . . . . . . . . . . 63
192        6.6.4.  503 Service Unavailable  . . . . . . . . . . . . . . . 63
193        6.6.5.  504 Gateway Timeout  . . . . . . . . . . . . . . . . . 63
194        6.6.6.  505 HTTP Version Not Supported . . . . . . . . . . . . 63
195    7.  Response Header Fields . . . . . . . . . . . . . . . . . . . . 64
196      7.1.  Control Data . . . . . . . . . . . . . . . . . . . . . . . 64
197        7.1.1.  Origination Date . . . . . . . . . . . . . . . . . . . 64
198        7.1.2.  Location . . . . . . . . . . . . . . . . . . . . . . . 68
199        7.1.3.  Retry-After  . . . . . . . . . . . . . . . . . . . . . 69
200        7.1.4.  Vary . . . . . . . . . . . . . . . . . . . . . . . . . 70
201      7.2.  Validator Header Fields  . . . . . . . . . . . . . . . . . 71
202      7.3.  Authentication Challenges  . . . . . . . . . . . . . . . . 72
203      7.4.  Response Context . . . . . . . . . . . . . . . . . . . . . 72
204        7.4.1.  Allow  . . . . . . . . . . . . . . . . . . . . . . . . 72
205        7.4.2.  Server . . . . . . . . . . . . . . . . . . . . . . . . 73
206    8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 73
207      8.1.  Method Registry  . . . . . . . . . . . . . . . . . . . . . 74
208        8.1.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 74
209        8.1.2.  Considerations for New Methods . . . . . . . . . . . . 74
210        8.1.3.  Registrations  . . . . . . . . . . . . . . . . . . . . 75
211      8.2.  Status Code Registry . . . . . . . . . . . . . . . . . . . 75
212        8.2.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 75
213        8.2.2.  Considerations for New Status Codes  . . . . . . . . . 76
214        8.2.3.  Registrations  . . . . . . . . . . . . . . . . . . . . 76
215      8.3.  Header Field Registry  . . . . . . . . . . . . . . . . . . 77
216        8.3.1.  Considerations for New Header Fields . . . . . . . . . 78
217        8.3.2.  Registrations  . . . . . . . . . . . . . . . . . . . . 80
218      8.4.  Content Coding Registry  . . . . . . . . . . . . . . . . . 80
219        8.4.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 81
220        8.4.2.  Registrations  . . . . . . . . . . . . . . . . . . . . 81
221    9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 81
222      9.1.  Attacks Based on File and Path Names . . . . . . . . . . . 82
223      9.2.  Attacks Based on Command, Code, or Query Injection . . . . 82
224      9.3.  Disclosure of Personal Information . . . . . . . . . . . . 83
225      9.4.  Disclosure of Sensitive Information in URIs  . . . . . . . 83
226      9.5.  Disclosure of Fragment after Redirects . . . . . . . . . . 83
227      9.6.  Disclosure of Product Information  . . . . . . . . . . . . 84
228      9.7.  Browser Fingerprinting . . . . . . . . . . . . . . . . . . 84
229    10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 85
230    11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 85
231      11.1. Normative References . . . . . . . . . . . . . . . . . . . 85
232      11.2. Informative References . . . . . . . . . . . . . . . . . . 86
233    Appendix A.  Differences between HTTP and MIME . . . . . . . . . . 88
234      A.1.  MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 89
235      A.2.  Conversion to Canonical Form . . . . . . . . . . . . . . . 89
236      A.3.  Conversion of Date Formats . . . . . . . . . . . . . . . . 89
237      A.4.  Conversion of Content-Encoding . . . . . . . . . . . . . . 89
238      A.5.  Conversion of Content-Transfer-Encoding  . . . . . . . . . 90
239      A.6.  MHTML and Line Length Limitations  . . . . . . . . . . . . 90
240    Appendix B.  Changes from RFC 2616 . . . . . . . . . . . . . . . . 90
241    Appendix C.  Imported ABNF . . . . . . . . . . . . . . . . . . . . 93
242    Appendix D.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 93
243    Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
244
245NEW:
246
247    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  6
248      1.1.  Conformance and Error Handling . . . . . . . . . . . . . .  6
249      1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  6
250    2.  Resources  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
251    3.  Representations  . . . . . . . . . . . . . . . . . . . . . . .  7
252      3.1.  Representation Metadata  . . . . . . . . . . . . . . . . .  8
253        3.1.1.  Processing Representation Data . . . . . . . . . . . .  8
254        3.1.2.  Encoding for Compression or Integrity  . . . . . . . . 11
255        3.1.3.  Audience Language  . . . . . . . . . . . . . . . . . . 13
256        3.1.4.  Identification . . . . . . . . . . . . . . . . . . . . 14
257      3.2.  Representation Data  . . . . . . . . . . . . . . . . . . . 17
258      3.3.  Payload Semantics  . . . . . . . . . . . . . . . . . . . . 17
259      3.4.  Content Negotiation  . . . . . . . . . . . . . . . . . . . 18
260        3.4.1.  Proactive Negotiation  . . . . . . . . . . . . . . . . 19
261        3.4.2.  Reactive Negotiation . . . . . . . . . . . . . . . . . 20
262    4.  Request Methods  . . . . . . . . . . . . . . . . . . . . . . . 21
263      4.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . 21
264      4.2.  Common Method Properties . . . . . . . . . . . . . . . . . 22
265        4.2.1.  Safe Methods . . . . . . . . . . . . . . . . . . . . . 22
266        4.2.2.  Idempotent Methods . . . . . . . . . . . . . . . . . . 23
267        4.2.3.  Cacheable Methods  . . . . . . . . . . . . . . . . . . 24
268      4.3.  Method Definitions . . . . . . . . . . . . . . . . . . . . 24
269        4.3.1.  GET  . . . . . . . . . . . . . . . . . . . . . . . . . 24
270        4.3.2.  HEAD . . . . . . . . . . . . . . . . . . . . . . . . . 25
271        4.3.3.  POST . . . . . . . . . . . . . . . . . . . . . . . . . 25
272        4.3.4.  PUT  . . . . . . . . . . . . . . . . . . . . . . . . . 26
273        4.3.5.  DELETE . . . . . . . . . . . . . . . . . . . . . . . . 29
274        4.3.6.  CONNECT  . . . . . . . . . . . . . . . . . . . . . . . 30
275        4.3.7.  OPTIONS  . . . . . . . . . . . . . . . . . . . . . . . 31
276        4.3.8.  TRACE  . . . . . . . . . . . . . . . . . . . . . . . . 32
277    5.  Request Header Fields  . . . . . . . . . . . . . . . . . . . . 33
278      5.1.  Controls . . . . . . . . . . . . . . . . . . . . . . . . . 33
279        5.1.1.  Expect . . . . . . . . . . . . . . . . . . . . . . . . 34
280        5.1.2.  Max-Forwards . . . . . . . . . . . . . . . . . . . . . 36
281 
282      5.2.  Conditionals . . . . . . . . . . . . . . . . . . . . . . . 36
283      5.3.  Content Negotiation  . . . . . . . . . . . . . . . . . . . 37
284        5.3.1.  Quality Values . . . . . . . . . . . . . . . . . . . . 37
285        5.3.2.  Accept . . . . . . . . . . . . . . . . . . . . . . . . 38
286        5.3.3.  Accept-Charset . . . . . . . . . . . . . . . . . . . . 40
287        5.3.4.  Accept-Encoding  . . . . . . . . . . . . . . . . . . . 41
288        5.3.5.  Accept-Language  . . . . . . . . . . . . . . . . . . . 42
289      5.4.  Authentication Credentials . . . . . . . . . . . . . . . . 43
290      5.5.  Request Context  . . . . . . . . . . . . . . . . . . . . . 44
291        5.5.1.  From . . . . . . . . . . . . . . . . . . . . . . . . . 44
292        5.5.2.  Referer  . . . . . . . . . . . . . . . . . . . . . . . 45
293        5.5.3.  User-Agent . . . . . . . . . . . . . . . . . . . . . . 46
294    6.  Response Status Codes  . . . . . . . . . . . . . . . . . . . . 47
295      6.1.  Overview of Status Codes . . . . . . . . . . . . . . . . . 48
296      6.2.  Informational 1xx  . . . . . . . . . . . . . . . . . . . . 50
297        6.2.1.  100 Continue . . . . . . . . . . . . . . . . . . . . . 50
298        6.2.2.  101 Switching Protocols  . . . . . . . . . . . . . . . 50
299      6.3.  Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 51
300        6.3.1.  200 OK . . . . . . . . . . . . . . . . . . . . . . . . 51
301        6.3.2.  201 Created  . . . . . . . . . . . . . . . . . . . . . 52
302        6.3.3.  202 Accepted . . . . . . . . . . . . . . . . . . . . . 52
303        6.3.4.  203 Non-Authoritative Information  . . . . . . . . . . 52
304        6.3.5.  204 No Content . . . . . . . . . . . . . . . . . . . . 53
305        6.3.6.  205 Reset Content  . . . . . . . . . . . . . . . . . . 53
306      6.4.  Redirection 3xx  . . . . . . . . . . . . . . . . . . . . . 54
307        6.4.1.  300 Multiple Choices . . . . . . . . . . . . . . . . . 55
308        6.4.2.  301 Moved Permanently  . . . . . . . . . . . . . . . . 56
309        6.4.3.  302 Found  . . . . . . . . . . . . . . . . . . . . . . 56
310        6.4.4.  303 See Other  . . . . . . . . . . . . . . . . . . . . 57
311        6.4.5.  305 Use Proxy  . . . . . . . . . . . . . . . . . . . . 57
312        6.4.6.  306 (Unused) . . . . . . . . . . . . . . . . . . . . . 57
313        6.4.7.  307 Temporary Redirect . . . . . . . . . . . . . . . . 58
314      6.5.  Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 58
315        6.5.1.  400 Bad Request  . . . . . . . . . . . . . . . . . . . 58
316        6.5.2.  402 Payment Required . . . . . . . . . . . . . . . . . 58
317        6.5.3.  403 Forbidden  . . . . . . . . . . . . . . . . . . . . 58
318        6.5.4.  404 Not Found  . . . . . . . . . . . . . . . . . . . . 59
319        6.5.5.  405 Method Not Allowed . . . . . . . . . . . . . . . . 59
320        6.5.6.  406 Not Acceptable . . . . . . . . . . . . . . . . . . 59
321        6.5.7.  408 Request Timeout  . . . . . . . . . . . . . . . . . 60
322        6.5.8.  409 Conflict . . . . . . . . . . . . . . . . . . . . . 60
323        6.5.9.  410 Gone . . . . . . . . . . . . . . . . . . . . . . . 60
324        6.5.10. 411 Length Required  . . . . . . . . . . . . . . . . . 61
325        6.5.11. 413 Payload Too Large  . . . . . . . . . . . . . . . . 61
326        6.5.12. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 61
327        6.5.13. 415 Unsupported Media Type . . . . . . . . . . . . . . 61
328        6.5.14. 417 Expectation Failed . . . . . . . . . . . . . . . . 62
329        6.5.15. 426 Upgrade Required . . . . . . . . . . . . . . . . . 62
330 
331      6.6.  Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 62
332        6.6.1.  500 Internal Server Error  . . . . . . . . . . . . . . 62
333        6.6.2.  501 Not Implemented  . . . . . . . . . . . . . . . . . 63
334        6.6.3.  502 Bad Gateway  . . . . . . . . . . . . . . . . . . . 63
335        6.6.4.  503 Service Unavailable  . . . . . . . . . . . . . . . 63
336        6.6.5.  504 Gateway Timeout  . . . . . . . . . . . . . . . . . 63
337        6.6.6.  505 HTTP Version Not Supported . . . . . . . . . . . . 63
338    7.  Response Header Fields . . . . . . . . . . . . . . . . . . . . 64
339      7.1.  Control Data . . . . . . . . . . . . . . . . . . . . . . . 64
340        7.1.1.  Origination Date . . . . . . . . . . . . . . . . . . . 64
341        7.1.2.  Location . . . . . . . . . . . . . . . . . . . . . . . 68
342        7.1.3.  Retry-After  . . . . . . . . . . . . . . . . . . . . . 69
343        7.1.4.  Vary . . . . . . . . . . . . . . . . . . . . . . . . . 70
344      7.2.  Validator Header Fields  . . . . . . . . . . . . . . . . . 71
345      7.3.  Authentication Challenges  . . . . . . . . . . . . . . . . 72
346      7.4.  Response Context . . . . . . . . . . . . . . . . . . . . . 72
347        7.4.1.  Allow  . . . . . . . . . . . . . . . . . . . . . . . . 72
348        7.4.2.  Server . . . . . . . . . . . . . . . . . . . . . . . . 73
349    8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 73
350      8.1.  Method Registry  . . . . . . . . . . . . . . . . . . . . . 74
351        8.1.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 74
352        8.1.2.  Considerations for New Methods . . . . . . . . . . . . 74
353        8.1.3.  Registrations  . . . . . . . . . . . . . . . . . . . . 75
354      8.2.  Status Code Registry . . . . . . . . . . . . . . . . . . . 75
355        8.2.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 75
356        8.2.2.  Considerations for New Status Codes  . . . . . . . . . 76
357        8.2.3.  Registrations  . . . . . . . . . . . . . . . . . . . . 76
358      8.3.  Header Field Registry  . . . . . . . . . . . . . . . . . . 77
359        8.3.1.  Considerations for New Header Fields . . . . . . . . . 78
360        8.3.2.  Registrations  . . . . . . . . . . . . . . . . . . . . 80
361      8.4.  Content Coding Registry  . . . . . . . . . . . . . . . . . 80
362        8.4.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 81
363        8.4.2.  Registrations  . . . . . . . . . . . . . . . . . . . . 81
364    9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 81
365      9.1.  Attacks Based on File and Path Names . . . . . . . . . . . 82
366      9.2.  Attacks Based on Command, Code, or Query Injection . . . . 82
367      9.3.  Disclosure of Personal Information . . . . . . . . . . . . 83
368      9.4.  Disclosure of Sensitive Information in URIs  . . . . . . . 83
369      9.5.  Disclosure of Fragment after Redirects . . . . . . . . . . 83
370      9.6.  Disclosure of Product Information  . . . . . . . . . . . . 84
371      9.7.  Browser Fingerprinting . . . . . . . . . . . . . . . . . . 84
372    10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 85
373    11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 85
374      11.1. Normative References . . . . . . . . . . . . . . . . . . . 85
375      11.2. Informative References . . . . . . . . . . . . . . . . . . 86
376    Appendix A.  Differences between HTTP and MIME . . . . . . . . . . 88
377      A.1.  MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 88
378      A.2.  Conversion to Canonical Form . . . . . . . . . . . . . . . 89
379      A.3.  Conversion of Date Formats . . . . . . . . . . . . . . . . 89
380      A.4.  Conversion of Content-Encoding . . . . . . . . . . . . . . 89
381      A.5.  Conversion of Content-Transfer-Encoding  . . . . . . . . . 90
382      A.6.  MHTML and Line-Length Limitations  . . . . . . . . . . . . 90
383    Appendix B.  Changes from RFC 2616 . . . . . . . . . . . . . . . . 90
384    Appendix C.  Imported ABNF . . . . . . . . . . . . . . . . . . . . 93
385    Appendix D.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 93
386    Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
387
388
389Section 2., paragraph 1:
390OLD:
391
392    The target of an HTTP request is called a resource.  HTTP does not
393    limit the nature of a resource; it merely defines an interface that
394    might be used to interact with resources.  Each resource is
395    identified by a Uniform Resource Identifier (URI), as described in
396    Section 2.7 of [RFC7230].
397
398NEW:
399
400    The target of an HTTP request is called a "resource".  HTTP does not
401    limit the nature of a resource; it merely defines an interface that
402    might be used to interact with resources.  Each resource is
403    identified by a Uniform Resource Identifier (URI), as described in
404    Section 2.7 of [RFC7230].
405
406
407Section 3.1.1.1., paragraph 1:
408OLD:
409
410    HTTP uses Internet Media Types [RFC2046] in the Content-Type
411    (Section 3.1.1.5) and Accept (Section 5.3.2) header fields in order
412    to provide open and extensible data typing and type negotiation.
413    Media types define both a data format and various processing models:
414    how to process that data in accordance with each context in which it
415    is received.
416
417NEW:
418
419    HTTP uses Internet media types [RFC2046] in the Content-Type
420    (Section 3.1.1.5) and Accept (Section 5.3.2) header fields in order
421    to provide open and extensible data typing and type negotiation.
422    Media types define both a data format and various processing models:
423    how to process that data in accordance with each context in which it
424    is received.
425
426
427Section 3.1.1.1., paragraph 5:
428OLD:
429
430    The type, subtype, and parameter name tokens are case-insensitive.
431    Parameter values might or might not be case-sensitive, depending on
432    the semantics of the parameter name.  The presence or absence of a
433    parameter might be significant to the processing of a media-type,
434    depending on its definition within the media type registry.
435
436NEW:
437
438    The type, subtype, and parameter name tokens are case insensitive.
439    Parameter values might or might not be case sensitive, depending on
440    the semantics of the parameter name.  The presence or absence of a
441    parameter might be significant to the processing of a media-type,
442    depending on its definition within the media type registry.
443
444
445Section 3.1.1.2., paragraph 3:
446OLD:
447
448    Charset names ought to be registered in the IANA Character Set
449    registry (<http://www.iana.org/assignments/character-sets>) according
450    to the procedures defined in [RFC2978].
451
452NEW:
453
454    Charset names ought to be registered in the IANA "Character Sets"
455    registry <http://www.iana.org/assignments/character-sets> according
456    to the procedures defined in [RFC2978].
457
458
459Section 3.1.1.3., paragraph 2:
460OLD:
461
462    MIME's canonical form requires that media subtypes of the "text" type
463    use CRLF as the text line break.  HTTP allows the transfer of text
464    media with plain CR or LF alone representing a line break, when such
465    line breaks are consistent for an entire representation.  An HTTP
466    sender MAY generate, and a recipient MUST be able to parse, line
467    breaks in text media that consist of CRLF, bare CR, or bare LF.  In
468    addition, text media in HTTP is not limited to charsets that use
469    octets 13 and 10 for CR and LF, respectively.  This flexibility
470    regarding line breaks applies only to text within a representation
471    that has been assigned a "text" media type; it does not apply to
472    "multipart" types or HTTP elements outside the payload body (e.g.,
473    header fields).
474
475NEW:
476
477    MIME's canonical form requires that media subtypes of the "text" type
478    use CRLF as the text line break.  HTTP allows the transfer of text
479    media with plain carriage return (CR) or line feed (LF) alone
480    representing a line break, when such line breaks are consistent for
481    an entire representation.  An HTTP sender MAY generate, and a
482    recipient MUST be able to parse, line breaks in text media that
483    consist of CRLF, bare CR, or bare LF.  In addition, text media in
484    HTTP is not limited to charsets that use octets 13 and 10 for CR and
485    LF, respectively.  This flexibility regarding line breaks applies
486    only to text within a representation that has been assigned a "text"
487    media type; it does not apply to "multipart" types or HTTP elements
488    outside the payload body (e.g., header fields).
489
490
491Section 3.1.2.1., paragraph 3:
492OLD:
493
494    All content-coding values are case-insensitive and ought to be
495    registered within the "HTTP Content Coding Registry", as defined in
496    Section 8.4.  They are used in the Accept-Encoding (Section 5.3.4)
497    and Content-Encoding (Section 3.1.2.2) header fields.
498
499NEW:
500
501    All content-coding values are case insensitive and ought to be
502    registered within the "HTTP Content Coding Registry", as defined in
503    Section 8.4.  They are used in the Accept-Encoding (Section 5.3.4)
504    and Content-Encoding (Section 3.1.2.2) header fields.
505
506
507Section 3.1.3.2., paragraph 5:
508OLD:
509
510    If no Content-Language is specified, the default is that the content
511    is intended for all language audiences.  This might mean that the
512    sender does not consider it to be specific to any natural language,
513    or that the sender does not know for which language it is intended.
514
515NEW:
516
517    If no Content-Language is specified, the default is that the content
518    is intended for all language audiences.  This might mean that the
519    sender does not consider it to be specific to any natural language,
520    or that the sender does not know which language is being used.
521
522
523Section 3.4.1., paragraph 2:
524OLD:
525
526    Proactive negotiation is advantageous when the algorithm for
527    selecting from among the available representations is difficult to
528    describe to a user agent, or when the server desires to send its
529    "best guess" to the user agent along with the first response (hoping
530    to avoid the round trip delay of a subsequent request if the "best
531    guess" is good enough for the user).  In order to improve the
532    server's guess, a user agent MAY send request header fields that
533    describe its preferences.
534
535NEW:
536
537    Proactive negotiation is advantageous when the algorithm for
538    selecting from among the available representations is difficult to
539    describe to a user agent, or when the server desires to send its
540    "best guess" to the user agent along with the first response (hoping
541    to avoid the round-trip delay of a subsequent request if the "best
542    guess" is good enough for the user).  In order to improve the
543    server's guess, a user agent MAY send request header fields that
544    describe its preferences.
545
546
547Section 4.1., paragraph 4:
548OLD:
549
550    HTTP was originally designed to be usable as an interface to
551    distributed object systems.  The request method was envisioned as
552    applying semantics to a target resource in much the same way as
553    invoking a defined method on an identified object would apply
554    semantics.  The method token is case-sensitive because it might be
555    used as a gateway to object-based systems with case-sensitive method
556    names.
557
558NEW:
559
560    HTTP was originally designed to be usable as an interface to
561    distributed object systems.  The request method was envisioned as
562    applying semantics to a target resource in much the same way as
563    invoking a defined method on an identified object would apply
564    semantics.  The method token is case sensitive because it might be
565    used as a gateway to object-based systems with case-sensitive method
566    names.
567
568
569Section 4.1., paragraph 5:
570OLD:
571
572    Unlike distributed objects, the standardized request methods in HTTP
573    are not resource-specific, since uniform interfaces provide for
574    better visibility and reuse in network-based systems [REST].  Once
575    defined, a standardized method ought to have the same semantics when
576    applied to any resource, though each resource determines for itself
577    whether those semantics are implemented or allowed.
578
579NEW:
580
581    Unlike distributed objects, the standardized request methods in HTTP
582    are not resource specific, since uniform interfaces provide for
583    better visibility and reuse in network-based systems [REST].  Once
584    defined, a standardized method ought to have the same semantics when
585    applied to any resource, though each resource determines for itself
586    whether those semantics are implemented or allowed.
587
588
589Section 4.1., paragraph 6:
590OLD:
591
592    This specification defines a number of standardized methods that are
593    commonly used in HTTP, as outlined by the following table.  By
594    convention, standardized methods are defined in all-uppercase US-
595    ASCII letters.
596
597NEW:
598
599    This specification defines a number of standardized methods that are
600    commonly used in HTTP, as outlined by the following table.  By
601    convention, standardized methods are defined in all-uppercase ASCII
602    letters.
603
604
605Section 4.1., paragraph 9:
606OLD:
607
608    Additional methods, outside the scope of this specification, have
609    been standardized for use in HTTP.  All such methods ought to be
610    registered within the "Hypertext Transfer Protocol (HTTP) Method
611    Registry" maintained by IANA, as defined in Section 8.1.
612
613NEW:
614
615    Additional methods, outside the scope of this specification, have
616    been standardized for use in HTTP.  All such methods ought to be
617    registered within the "Hypertext Transfer Protocol (HTTP) Method"
618    registry maintained by IANA, as defined in Section 8.1.
619
620
621Section 4.2.1., paragraph 2:
622OLD:
623
624    This definition of safe methods does not prevent an implementation
625    from including behavior that is potentially harmful, that is not
626    entirely read-only, or that causes side effects while invoking a safe
627    method.  What is important, however, is that the client did not
628    request that additional behavior and cannot be held accountable for
629    it.  For example, most servers append request information to access
630    log files at the completion of every response, regardless of the
631    method, and that is considered safe even though the log storage might
632    become full and crash the server.  Likewise, a safe request initiated
633    by selecting an advertisement on the Web will often have the side
634    effect of charging an advertising account.
635
636NEW:
637
638    This definition of safe method does not prevent an implementation
639    from including behavior that is potentially harmful, that is not
640    entirely read-only, or that causes side effects while invoking a safe
641    method.  What is important, however, is that the client did not
642    request that additional behavior and cannot be held accountable for
643    it.  For example, most servers append request information to access
644    log files at the completion of every response, regardless of the
645    method, and that is considered safe even though the log storage might
646    become full and crash the server.  Likewise, a safe request initiated
647    by selecting an advertisement on the Web will often have the side
648    effect of charging an advertising account.
649
650
651Section 5.1.1., paragraph 3:
652OLD:
653
654    The Expect field-value is case-insensitive.
655
656NEW:
657
658    The Expect field-value is case insensitive.
659
660
661Section 5.5.1., paragraph 1:
662OLD:
663
664    The "From" header field contains an Internet email address for a
665    human user who controls the requesting user agent.  The address ought
666    to be machine-usable, as defined by "mailbox" in Section 3.4 of
667    [RFC5322]:
668
669NEW:
670
671    The "From" header field contains an Internet email address for a
672    human user who controls the requesting user agent.  The address ought
673    to be machine usable, as defined by "mailbox" in Section 3.4 of
674    [RFC5322]:
675
676
677Section 5.5.2., paragraph 6:
678OLD:
679
680    If the target URI was obtained from a source that does not have its
681    own URI (e.g., input from the user keyboard, or an entry within the
682    user's bookmarks/favorites), the user agent MUST either exclude
683    Referer or send it with a value of "about:blank".
684
685NEW:
686
687    If the target URI was obtained from a source that does not have its
688    own URI (e.g., input from the user keyboard, or an entry within the
689    user's bookmarks/favorites), the user agent MUST either exclude the
690    Referer or send it with a value of "about:blank".
691
692
693Section 5.5.3., paragraph 1:
694OLD:
695
696    The "User-Agent" header field contains information about the user
697    agent originating the request, which is often used by servers to help
698    identify the scope of reported interoperability problems, to work
699    around or tailor responses to avoid particular user agent
700    limitations, and for analytics regarding browser or operating system
701    use.  A user agent SHOULD send a User-Agent field in each request
702    unless specifically configured not to do so.
703
704NEW:
705
706    The "User-Agent" header field contains information about the user
707    agent originating the request, which is often used by servers to help
708    identify the scope of reported interoperability problems, to work
709    around or tailor responses to avoid particular user-agent
710    limitations, and for analytics regarding browser or operating system
711    use.  A user agent SHOULD send a User-Agent field in each request
712    unless specifically configured not to do so.
713
714
715Section 5.5.3., paragraph 3:
716OLD:
717
718    The User-Agent field-value consists of one or more product
719    identifiers, each followed by zero or more comments (Section 3.2 of
720    [RFC7230]), which together identify the user agent software and its
721    significant subproducts.  By convention, the product identifiers are
722    listed in decreasing order of their significance for identifying the
723    user agent software.  Each product identifier consists of a name and
724    optional version.
725
726NEW:
727
728    The User-Agent field-value consists of one or more product
729    identifiers, each followed by zero or more comments (Section 3.2 of
730    [RFC7230]), which together identify the user-agent software and its
731    significant subproducts.  By convention, the product identifiers are
732    listed in decreasing order of their significance for identifying the
733    user-agent software.  Each product identifier consists of a name and
734    optional version.
735
736
737Section 5.5.3., paragraph 9:
738OLD:
739
740    Likewise, implementations are encouraged not to use the product
741    tokens of other implementations in order to declare compatibility
742    with them, as this circumvents the purpose of the field.  If a user
743    agent masquerades as a different user agent, recipients can assume
744    that the user intentionally desires to see responses tailored for
745    that identified user agent, even if they might not work as well for
746    the actual user agent being used.
747
748NEW:
749
750    Likewise, implementations are encouraged not to use the product
751    tokens of other implementations in order to declare compatibility
752    with them, as this circumvents the purpose of the field.  If a user
753    agent masquerades as a different user agent, recipients can assume
754    that the user intentionally desires to see responses tailored for
755    that identified user agent, even if they might not work as well for
756    the actual user agent being implemented.
757
758
759Section 6.4.1., paragraph 5:
760OLD:
761
762       Note: The original proposal for the 300 status code defined the
763       URI header field as providing a list of alternative
764       representations, such that it would be usable for 200, 300, and
765       406 responses and be transferred in responses to the HEAD method.
766       However, lack of deployment and disagreement over syntax led to
767       both URI and Alternates (a subsequent proposal) being dropped from
768       this specification.  It is possible to communicate the list using
769       a set of Link header fields [RFC5988], each with a relationship of
770       "alternate", though deployment is a chicken-and-egg problem.
771
772NEW:
773
774       Note: The original proposal for the 300 response defined the URI
775       header field as providing a list of alternative representations,
776       such that it would be usable for 200, 300, and 406 responses and
777       be transferred in responses to the HEAD method.  However, lack of
778       deployment and disagreement over syntax led to both URI and
779       Alternates (a subsequent proposal) being dropped from this
780       specification.  It is possible to communicate the list using a set
781       of Link header fields [RFC5988], each with a relationship of
782       "alternate", though deployment is a chicken-and-egg problem.
783
784
785Section 6.4.7., paragraph 3:
786OLD:
787
788       Note: This status code is similar to 302 (Found), except that it
789       does not allow changing the request method from POST to GET.  This
790       specification defines no equivalent counterpart for 301 (Moved
791       Permanently) ([RFC7238], however, defines the status code 308
792       (Permanent Redirect) for this purpose).
793
794NEW:
795
796       Note: This status code is similar to 302 (Found), except that it
797       does not allow changing the request method from POST to GET.  This
798       specification defines no equivalent counterpart for 301 (Moved
799       Permanently) ([RFC7238]; however, it defines the status code 308
800       (Permanent Redirect) for this purpose).
801
802
803Section 6.5.7., paragraph 1:
804OLD:
805
806    The 408 (Request Timeout) status code indicates that the server did
807    not receive a complete request message within the time that it was
808    prepared to wait.  A server SHOULD send the "close" connection option
809    (Section 6.1 of [RFC7230]) in the response, since 408 implies that
810    the server has decided to close the connection rather than continue
811    waiting.  If the client has an outstanding request in transit, the
812    client MAY repeat that request on a new connection.
813
814NEW:
815
816    The 408 (Request Timeout) status code indicates that the server did
817    not receive a complete request message within the time that it was
818    prepared to wait.  A server SHOULD send the close connection option
819    (Section 6.1 of [RFC7230]) in the response, since 408 implies that
820    the server has decided to close the connection rather than continue
821    waiting.  If the client has an outstanding request in transit, the
822    client MAY repeat that request on a new connection.
823
824
825Section 7.1.1.1., paragraph 11:
826OLD:
827
828      day-name     = %x4D.6F.6E ; "Mon", case-sensitive
829                   / %x54.75.65 ; "Tue", case-sensitive
830                   / %x57.65.64 ; "Wed", case-sensitive
831                   / %x54.68.75 ; "Thu", case-sensitive
832                   / %x46.72.69 ; "Fri", case-sensitive
833                   / %x53.61.74 ; "Sat", case-sensitive
834                   / %x53.75.6E ; "Sun", case-sensitive
835
836NEW:
837
838      day-name     = %x4D.6F.6E ; "Mon", case sensitive
839                   / %x54.75.65 ; "Tue", case sensitive
840                   / %x57.65.64 ; "Wed", case sensitive
841                   / %x54.68.75 ; "Thu", case sensitive
842                   / %x46.72.69 ; "Fri", case sensitive
843                   / %x53.61.74 ; "Sat", case sensitive
844                   / %x53.75.6E ; "Sun", case sensitive
845
846
847Section 7.1.1.1., paragraph 13:
848OLD:
849
850      day          = 2DIGIT
851      month        = %x4A.61.6E ; "Jan", case-sensitive
852                   / %x46.65.62 ; "Feb", case-sensitive
853                   / %x4D.61.72 ; "Mar", case-sensitive
854                   / %x41.70.72 ; "Apr", case-sensitive
855                   / %x4D.61.79 ; "May", case-sensitive
856                   / %x4A.75.6E ; "Jun", case-sensitive
857                   / %x4A.75.6C ; "Jul", case-sensitive
858                   / %x41.75.67 ; "Aug", case-sensitive
859                   / %x53.65.70 ; "Sep", case-sensitive
860                   / %x4F.63.74 ; "Oct", case-sensitive
861                   / %x4E.6F.76 ; "Nov", case-sensitive
862                   / %x44.65.63 ; "Dec", case-sensitive
863      year         = 4DIGIT
864
865NEW:
866
867      day          = 2DIGIT
868      month        = %x4A.61.6E ; "Jan", case sensitive
869                   / %x46.65.62 ; "Feb", case sensitive
870                   / %x4D.61.72 ; "Mar", case sensitive
871                   / %x41.70.72 ; "Apr", case sensitive
872                   / %x4D.61.79 ; "May", case sensitive
873                   / %x4A.75.6E ; "Jun", case sensitive
874                   / %x4A.75.6C ; "Jul", case sensitive
875                   / %x41.75.67 ; "Aug", case sensitive
876                   / %x53.65.70 ; "Sep", case sensitive
877                   / %x4F.63.74 ; "Oct", case sensitive
878                   / %x4E.6F.76 ; "Nov", case sensitive
879                   / %x44.65.63 ; "Dec", case sensitive
880      year         = 4DIGIT
881
882
883Section 7.1.1.1., paragraph 14:
884OLD:
885
886      GMT          = %x47.4D.54 ; "GMT", case-sensitive
887
888NEW:
889
890      GMT          = %x47.4D.54 ; "GMT", case sensitive
891
892
893Section 7.1.1.1., paragraph 19:
894OLD:
895
896      day-name-l   = %x4D.6F.6E.64.61.79    ; "Monday", case-sensitive
897             / %x54.75.65.73.64.61.79       ; "Tuesday", case-sensitive
898             / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive
899             / %x54.68.75.72.73.64.61.79    ; "Thursday", case-sensitive
900             / %x46.72.69.64.61.79          ; "Friday", case-sensitive
901             / %x53.61.74.75.72.64.61.79    ; "Saturday", case-sensitive
902             / %x53.75.6E.64.61.79          ; "Sunday", case-sensitive
903
904NEW:
905
906      day-name-l   = %x4D.6F.6E.64.61.79    ; "Monday", case sensitive
907             / %x54.75.65.73.64.61.79       ; "Tuesday", case sensitive
908             / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case sensitive
909             / %x54.68.75.72.73.64.61.79    ; "Thursday", case sensitive
910             / %x46.72.69.64.61.79          ; "Friday", case sensitive
911             / %x53.61.74.75.72.64.61.79    ; "Saturday", case sensitive
912             / %x53.75.6E.64.61.79          ; "Sunday", case sensitive
913
914
915Section 7.1.4., paragraph 1:
916OLD:
917
918    The "Vary" header field in a response describes what parts of a
919    request message, aside from the method, Host header field, and
920    request target, might influence the origin server's process for
921    selecting and representing this response.  The value consists of
922    either a single asterisk ("*") or a list of header field names (case-
923    insensitive).
924
925NEW:
926
927    The "Vary" header field in a response describes what parts of a
928    request message, aside from the method, Host header field, and
929    request target, might influence the origin server's process for
930    selecting and representing this response.  The value consists of
931    either a single asterisk ("*") or a list of header field names (case
932    insensitive).
933
934
935Section 1., paragraph 1:
936OLD:
937
938    2.  To inform user agent recipients that this response is subject to
939        content negotiation (Section 5.3) and that a different
940        representation might be sent in a subsequent request if
941        additional parameters are provided in the listed header fields
942        (proactive negotiation).
943
944NEW:
945
946    2.  To inform user-agent recipients that this response is subject to
947        content negotiation (Section 5.3) and that a different
948        representation might be sent in a subsequent request if
949        additional parameters are provided in the listed header fields
950        (proactive negotiation).
951
952
953Section 8.1., paragraph 1:
954OLD:
955
956    The "Hypertext Transfer Protocol (HTTP) Method Registry" defines the
957    namespace for the request method token (Section 4).  The method
958    registry has been created and is now maintained at
959    <http://www.iana.org/assignments/http-methods>.
960
961NEW:
962
963    The "Hypertext Transfer Protocol (HTTP) Method Registry" defines the
964    namespace for the request method token (Section 4).  The "HTTP Method
965    Registry" has been created and is now maintained at
966    <http://www.iana.org/assignments/http-methods>.
967
968
969Section 8.1.2., paragraph 3:
970OLD:
971
972    A new method definition needs to indicate whether it is safe
973    (Section 4.2.1), idempotent (Section 4.2.2), cacheable
974    (Section 4.2.3), what semantics are to be associated with the payload
975    body if any is present in the request and what refinements the method
976    makes to header field or status code semantics.  If the new method is
977    cacheable, its definition ought to describe how, and under what
978    conditions, a cache can store a response and use it to satisfy a
979    subsequent request.  The new method ought to describe whether it can
980    be made conditional (Section 5.2) and, if so, how a server responds
981    when the condition is false.  Likewise, if the new method might have
982    some use for partial response semantics ([RFC7233]), it ought to
983    document this, too.
984
985NEW:
986
987    A new method definition needs to indicate whether it is safe
988    (Section 4.2.1), idempotent (Section 4.2.2), or cacheable
989    (Section 4.2.3).  It needs to indicate what semantics are to be
990    associated with the payload body if any is present in the request and
991    what refinements the method makes to header field or status code
992    semantics.  If the new method is cacheable, its definition ought to
993    describe how, and under what conditions, a cache can store a response
994    and use it to satisfy a subsequent request.  The new method ought to
995    describe whether it can be made conditional (Section 5.2) and, if so,
996    how a server responds when the condition is false.  Likewise, if the
997    new method might have some use for partial response semantics
998    ([RFC7233]), it ought to document this, too.
999
1000
1001Section 8.2., paragraph 1:
1002OLD:
1003
1004    The "Hypertext Transfer Protocol (HTTP) Status Code Registry" defines
1005    the namespace for the response status-code token (Section 6).  The
1006    status code registry is maintained at
1007    <http://www.iana.org/assignments/http-status-codes>.
1008
1009NEW:
1010
1011    The "Hypertext Transfer Protocol (HTTP) Status Code Registry" defines
1012    the namespace for the response status-code token (Section 6).  The
1013    "HTTP Status Codes" registry is maintained at
1014    <http://www.iana.org/assignments/http-status-codes>.
1015
1016
1017Section 8.2.3., paragraph 1:
1018OLD:
1019
1020    The status code registry has been updated with the registrations
1021    below:
1022
1023NEW:
1024
1025    The "HTTP Status Codes" registry has been updated with the
1026    registrations below:
1027
1028
1029Section 8.3., paragraph 1:
1030OLD:
1031
1032    HTTP header fields are registered within the "Message Headers"
1033    registry located at
1034    <http://www.iana.org/assignments/message-headers>, as defined by
1035    [BCP90].
1036
1037NEW:
1038
1039    HTTP header fields are registered within the "Message Headers"
1040    registry located at <http://www.iana.org/assignments/message-headers>
1041    as defined by [BCP90].
1042
1043
1044Section 8.3.1., paragraph 4:
1045OLD:
1046
1047    New header field values typically have their syntax defined using
1048    ABNF ([RFC5234]), using the extension defined in Section 7 of
1049    [RFC7230] as necessary, and are usually constrained to the range of
1050    US-ASCII characters.  Header fields needing a greater range of
1051    characters can use an encoding such as the one defined in [RFC5987].
1052
1053NEW:
1054
1055    New header field values typically have their syntax defined using
1056    ABNF ([RFC5234]) (implementing the extension defined in Section 7 of
1057    [RFC7230] as necessary), and they are usually constrained to the
1058    range of ASCII characters.  Header fields needing a greater range of
1059    characters can use an encoding such as the one defined in [RFC5987].
1060
1061
1062Section 8.4., paragraph 1:
1063OLD:
1064
1065    The "HTTP Content Coding Registry" defines the namespace for content
1066    coding names (Section 4.2 of [RFC7230]).  The content coding registry
1067    is maintained at <http://www.iana.org/assignments/http-parameters>.
1068
1069NEW:
1070
1071    The "HTTP Content Coding Registry" defines the namespace for content
1072    coding names (Section 4.2 of [RFC7230]).  The "HTTP Content Coding
1073    Registry" is maintained at
1074    <http://www.iana.org/assignments/http-parameters>.
1075
1076
1077Section 8.4.1., paragraph 1:
1078OLD:
1079
1080    Content Coding registrations MUST include the following fields:
1081
1082NEW:
1083
1084    Content coding registrations MUST include the following fields:
1085
1086
1087Section 8.4.1., paragraph 6:
1088OLD:
1089
1090    Values to be added to this namespace require IETF Review (see Section
1091    4.1 of [RFC5226]), and MUST conform to the purpose of content coding
1092    defined in this section.
1093
1094NEW:
1095
1096    Values to be added to this namespace require IETF Review (see Section
1097    4.1 of [RFC5226]) and MUST conform to the purpose of content coding
1098    defined in this section.
1099
1100
1101Section 8.4.2., paragraph 1:
1102OLD:
1103
1104    The "HTTP Content Coding Registry" has been updated with the
1105    registrations below:
1106
1107NEW:
1108
1109    The "HTTP Content Codings Registry" has been updated with the
1110    registrations below:
1111
1112
1113Section 9., paragraph 2:
1114OLD:
1115
1116    The list of considerations below is not exhaustive.  Most security
1117    concerns related to HTTP semantics are about securing server-side
1118    applications (code behind the HTTP interface), securing user agent
1119    processing of payloads received via HTTP, or secure use of the
1120    Internet in general, rather than security of the protocol.  Various
1121    organizations maintain topical information and links to current
1122    research on Web application security (e.g., [OWASP]).
1123
1124NEW:
1125
1126    The list of considerations below is not exhaustive.  Most security
1127    concerns related to HTTP semantics are about securing server-side
1128    applications (code behind the HTTP interface) or securing user-agent
1129    processing of payloads received via HTTP.  Secure use of the Internet
1130    in general, rather than security of the protocol, might also be
1131    related.  Various organizations maintain topical information and
1132    links to current research on Web application security (e.g.,
1133    [OWASP]).
1134
1135
1136Section 9.1., paragraph 3:
1137OLD:
1138
1139    Attacks based on such special names tend to focus on either denial-
1140    of-service (e.g., telling the server to read from a COM port) or
1141    disclosure of configuration and source files that are not meant to be
1142    served.
1143
1144NEW:
1145
1146    Attacks based on such special names tend to focus on either denial of
1147    service (e.g., telling the server to read from a COM port) or
1148    disclosure of configuration and source files that are not meant to be
1149    served.
1150
1151
1152Section 11.1., paragraph 9:
1153OLD:
1154
1155    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1156               Protocol (HTTP/1.1): Message Syntax and Routing",
1157               draft-ietf-httpbis-p1-messaging-latest (work in progress),
1158               May 2014.
1159
1160NEW:
1161
1162    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1163               Protocol (HTTP/1.1): Message Syntax and Routing",
1164               RFC 7230, May 2014.
1165
1166
1167Section 11.1., paragraph 10:
1168OLD:
1169
1170    [RFC7232]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1171               Protocol (HTTP/1.1): Conditional Requests",
1172               draft-ietf-httpbis-p4-conditional-latest (work in
1173               progress), May 2014.
1174
1175NEW:
1176
1177    [RFC7232]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1178               Protocol (HTTP/1.1): Conditional Requests", RFC 7232,
1179               May 2014.
1180
1181
1182Section 11.1., paragraph 11:
1183OLD:
1184
1185    [RFC7233]  Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
1186               "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
1187               draft-ietf-httpbis-p5-range-latest (work in progress),
1188               May 2014.
1189
1190NEW:
1191
1192    [RFC7233]  Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
1193               "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
1194               RFC 7233, May 2014.
1195
1196
1197Section 11.1., paragraph 12:
1198OLD:
1199
1200    [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1201               Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
1202               draft-ietf-httpbis-p6-cache-latest (work in progress),
1203               May 2014.
1204
1205NEW:
1206
1207    [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1208               Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
1209               RFC 7234, May 2014.
1210
1211
1212Section 11.1., paragraph 13:
1213OLD:
1214
1215    [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1216               Protocol (HTTP/1.1): Authentication",
1217               draft-ietf-httpbis-p7-auth-latest (work in progress),
1218               May 2014.
1219
1220NEW:
1221
1222    [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1223               Protocol (HTTP/1.1): Authentication", RFC 7235, May 2014.
1224
1225
1226Section 11.2., paragraph 25:
1227OLD:
1228
1229    [RFC7238]  Reschke, J., "The Hypertext Transfer Protocol (HTTP)
1230               Status Code 308 (Permanent Redirect)",
1231               draft-reschke-http-status-308-07 (work in progress),
1232               March 2012.
1233
1234NEW:
1235
1236    [RFC7238]  Reschke, J., "The Hypertext Transfer Protocol (HTTP)
1237               Status Code 308 (Permanent Redirect)", RFC 7238, May 2014.
1238
1239
1240Appendix A., paragraph 16:
1241OLD:
1242
1243 A.6.  MHTML and Line Length Limitations
1244
1245NEW:
1246
1247 A.6.  MHTML and Line-Length Limitations
1248
1249
1250Appendix A., paragraph 17:
1251OLD:
1252
1253    HTTP implementations that share code with MHTML [RFC2557]
1254    implementations need to be aware of MIME line length limitations.
1255    Since HTTP does not have this limitation, HTTP does not fold long
1256    lines.  MHTML messages being transported by HTTP follow all
1257    conventions of MHTML, including line length limitations and folding,
1258    canonicalization, etc., since HTTP transfers message-bodies as
1259    payload and, aside from the "multipart/byteranges" type (Appendix A
1260    of [RFC7233]), does not interpret the content or any MIME header
1261    lines that might be contained therein.
1262
1263NEW:
1264
1265    HTTP implementations that share code with MHTML [RFC2557]
1266    implementations need to be aware of MIME line-length limitations.
1267    Since HTTP does not have this limitation, HTTP does not fold long
1268    lines.  MHTML messages being transported by HTTP follow all
1269    conventions of MHTML, including line-length limitations and folding,
1270    canonicalization, etc., since HTTP transfers message-bodies as
1271    payload and, aside from the "multipart/byteranges" type (Appendix A
1272    of [RFC7233]), does not interpret the content or any MIME header
1273    lines that might be contained therein.
1274
1275
1276Appendix B., paragraph 2:
1277OLD:
1278
1279    A new requirement has been added that semantics embedded in a URI be
1280    disabled when those semantics are inconsistent with the request
1281    method, since this is a common cause of interoperability failure.
1282 
1283    (Section 2)
1284
1285NEW:
1286
1287    A new requirement has been added that semantics embedded in a URI be
1288    disabled when those semantics are inconsistent with the request
1289    method, since this is a common cause of interoperability failure
1290    (Section 2).
1291
1292
1293Appendix B., paragraph 3:
1294OLD:
1295
1296    An algorithm has been added for determining if a payload is
1297    associated with a specific identifier.  (Section 3.1.4.1)
1298
1299NEW:
1300
1301    An algorithm has been added for determining if a payload is
1302    associated with a specific identifier (Section 3.1.4.1).
1303
1304
1305Appendix B., paragraph 4:
1306OLD:
1307
1308    The default charset of ISO-8859-1 for text media types has been
1309    removed; the default is now whatever the media type definition says.
1310    Likewise, special treatment of ISO-8859-1 has been removed from the
1311    Accept-Charset header field.  (Section 3.1.1.3 and Section 5.3.3)
1312
1313NEW:
1314
1315    The default charset of ISO-8859-1 for text media types has been
1316    removed; the default is now whatever the media type definition says.
1317    Likewise, special treatment of ISO-8859-1 has been removed from the
1318    Accept-Charset header field.  (Sections 3.1.1.3 and 5.3.3.)
1319
1320
1321Appendix B., paragraph 5:
1322OLD:
1323
1324    The definition of Content-Location has been changed to no longer
1325    affect the base URI for resolving relative URI references, due to
1326    poor implementation support and the undesirable effect of potentially
1327    breaking relative links in content-negotiated resources.
1328    (Section 3.1.4.2)
1329
1330NEW:
1331
1332    The definition of Content-Location has been changed to no longer
1333    affect the base URI for resolving relative URI references, due to
1334    poor implementation support and the undesirable effect of potentially
1335    breaking relative links in content-negotiated resources
1336    (Section 3.1.4.2).
1337
1338
1339Appendix B., paragraph 6:
1340OLD:
1341
1342    To be consistent with the method-neutral parsing algorithm of
1343    [RFC7230], the definition of GET has been relaxed so that requests
1344    can have a body, even though a body has no meaning for GET.
1345    (Section 4.3.1)
1346
1347NEW:
1348
1349    To be consistent with the method-neutral parsing algorithm of
1350    [RFC7230], the definition of GET has been relaxed so that requests
1351    can have a body, even though a body has no meaning for GET
1352    (Section 4.3.1).
1353
1354
1355Appendix B., paragraph 7:
1356OLD:
1357
1358    Servers are no longer required to handle all Content-* header fields
1359    and use of Content-Range has been explicitly banned in PUT requests.
1360    (Section 4.3.4)
1361
1362NEW:
1363
1364    Servers are no longer required to handle all Content-* header fields
1365    and use of Content-Range has been explicitly banned in PUT requests
1366    (Section 4.3.4).
1367
1368
1369Appendix B., paragraph 8:
1370OLD:
1371
1372    Definition of the CONNECT method has been moved from [RFC2817] to
1373    this specification.  (Section 4.3.6)
1374
1375NEW:
1376
1377    Definition of the CONNECT method has been moved from [RFC2817] to
1378    this specification (Section 4.3.6).
1379
1380
1381Appendix B., paragraph 9:
1382OLD:
1383
1384    The OPTIONS and TRACE request methods have been defined as being
1385    safe.  (Section 4.3.7 and Section 4.3.8)
1386
1387NEW:
1388
1389    The OPTIONS and TRACE request methods have been defined as being safe
1390    (Section 4.3.7 and Section 4.3.8).
1391
1392
1393Appendix B., paragraph 10:
1394OLD:
1395
1396    The Expect header field's extension mechanism has been removed due to
1397    widely-deployed broken implementations.  (Section 5.1.1)
1398
1399NEW:
1400
1401    The Expect header field's extension mechanism has been removed due to
1402    widely deployed broken implementations (Section 5.1.1).
1403
1404
1405Appendix B., paragraph 11:
1406OLD:
1407
1408    The Max-Forwards header field has been restricted to the OPTIONS and
1409    TRACE methods; previously, extension methods could have used it as
1410    well.  (Section 5.1.2)
1411
1412NEW:
1413
1414    The Max-Forwards header field has been restricted to the OPTIONS and
1415    TRACE methods; previously, extension methods could have used it as
1416    well (Section 5.1.2).
1417
1418
1419Appendix B., paragraph 12:
1420OLD:
1421
1422    The "about:blank" URI has been suggested as a value for the Referer
1423    header field when no referring URI is applicable, which distinguishes
1424    that case from others where the Referer field is not sent or has been
1425    removed.  (Section 5.5.2)
1426
1427NEW:
1428
1429    The "about:blank" URI has been suggested as a value for the Referer
1430    header field when no referring URI is applicable, which distinguishes
1431    that case from others where the Referer field is not sent or has been
1432    removed (Section 5.5.2).
1433
1434
1435Appendix B., paragraph 13:
1436OLD:
1437
1438    The following status codes are now cacheable (that is, they can be
1439    stored and reused by a cache without explicit freshness information
1440    present): 204, 404, 405, 414, 501.  (Section 6)
1441
1442NEW:
1443
1444    The following status codes are now cacheable (that is, they can be
1445    stored and reused by a cache without explicit freshness information
1446    present): 204, 404, 405, 414, 501 (Section 6).
1447
1448
1449Appendix B., paragraph 14:
1450OLD:
1451
1452    The 201 (Created) status description has been changed to allow for
1453    the possibility that more than one resource has been created.
1454    (Section 6.3.2)
1455
1456NEW:
1457
1458    The 201 (Created) status description has been changed to allow for
1459    the possibility that more than one resource has been created
1460    (Section 6.3.2).
1461
1462
1463Appendix B., paragraph 15:
1464OLD:
1465
1466    The definition of 203 (Non-Authoritative Information) has been
1467    broadened to include cases of payload transformations as well.
1468    (Section 6.3.4)
1469
1470NEW:
1471
1472    The definition of 203 (Non-Authoritative Information) has been
1473    broadened to include cases of payload transformations as well
1474    (Section 6.3.4).
1475
1476
1477Appendix B., paragraph 16:
1478OLD:
1479
1480    The set of request methods that are safe to automatically redirect is
1481    no longer closed; user agents are able to make that determination
1482    based upon the request method semantics.  The redirect status codes
1483    301, 302, and 307 no longer have normative requirements on response
1484    payloads and user interaction.  (Section 6.4)
1485
1486NEW:
1487
1488    The set of request methods that are safe to automatically redirect is
1489    no longer closed; user agents are able to make that determination
1490    based upon the request method semantics.  The redirect status codes
1491    301, 302, and 307 no longer have normative requirements on response
1492    payloads and user interaction (Section 6.4).
1493
1494
1495Appendix B., paragraph 17:
1496OLD:
1497
1498    The status codes 301 and 302 have been changed to allow user agents
1499    to rewrite the method from POST to GET.  (Sections 6.4.2 and 6.4.3)
1500
1501NEW:
1502
1503    The status codes 301 and 302 have been changed to allow user agents
1504    to rewrite the method from POST to GET.  (Sections 6.4.2 and 6.4.3.)
1505
1506
1507Appendix B., paragraph 18:
1508OLD:
1509
1510    The description of 303 (See Other) status code has been changed to
1511    allow it to be cached if explicit freshness information is given, and
1512    a specific definition has been added for a 303 response to GET.
1513    (Section 6.4.4)
1514
1515NEW:
1516
1517    The description of the 303 (See Other) status code has been changed
1518    to allow it to be cached if explicit freshness information is given,
1519    and a specific definition has been added for a 303 response to GET
1520    (Section 6.4.4).
1521
1522
1523Appendix B., paragraph 19:
1524OLD:
1525
1526    The 305 (Use Proxy) status code has been deprecated due to security
1527    concerns regarding in-band configuration of a proxy.  (Section 6.4.5)
1528
1529NEW:
1530
1531    The 305 (Use Proxy) status code has been deprecated due to security
1532    concerns regarding in-band configuration of a proxy (Section 6.4.5).
1533
1534
1535Appendix B., paragraph 20:
1536OLD:
1537
1538    The 400 (Bad Request) status code has been relaxed so that it isn't
1539    limited to syntax errors.  (Section 6.5.1)
1540
1541NEW:
1542
1543    The 400 (Bad Request) status code has been relaxed so that it isn't
1544    limited to syntax errors (Section 6.5.1).
1545
1546
1547Appendix B., paragraph 21:
1548OLD:
1549
1550    The 426 (Upgrade Required) status code has been incorporated from
1551    [RFC2817].  (Section 6.5.15)
1552
1553NEW:
1554
1555    The 426 (Upgrade Required) status code has been incorporated from
1556    [RFC2817] (Section 6.5.15).
1557
1558
1559Appendix B., paragraph 22:
1560OLD:
1561
1562    The target of requirements on HTTP-date and the Date header field
1563    have been reduced to those systems generating the date, rather than
1564    all systems sending a date.  (Section 7.1.1)
1565
1566NEW:
1567
1568    The target of requirements on HTTP-date and the Date header field
1569    have been reduced to those systems generating the date, rather than
1570    all systems sending a date (Section 7.1.1).
1571
1572
1573Appendix B., paragraph 23:
1574OLD:
1575
1576    The syntax of the Location header field has been changed to allow all
1577    URI references, including relative references and fragments, along
1578    with some clarifications as to when use of fragments would not be
1579    appropriate.  (Section 7.1.2)
1580
1581NEW:
1582
1583    The syntax of the Location header field has been changed to allow all
1584    URI references, including relative references and fragments, along
1585    with some clarifications as to when use of fragments would not be
1586    appropriate (Section 7.1.2).
1587
1588
1589Appendix B., paragraph 24:
1590OLD:
1591
1592    Allow has been reclassified as a response header field, removing the
1593    option to specify it in a PUT request.  Requirements relating to the
1594    content of Allow have been relaxed; correspondingly, clients are not
1595    required to always trust its value.  (Section 7.4.1)
1596
1597NEW:
1598
1599    Allow has been reclassified as a response header field, removing the
1600    option to specify it in a PUT request.  Requirements relating to the
1601    content of Allow have been relaxed; correspondingly, clients are not
1602    required to always trust its value (Section 7.4.1).
1603
1604
1605Appendix B., paragraph 25:
1606OLD:
1607
1608    A Method Registry has been defined.  (Section 8.1)
1609
1610NEW:
1611
1612    A Method Registry has been defined (Section 8.1).
1613
1614
1615Appendix B., paragraph 26:
1616OLD:
1617
1618    The Status Code Registry has been redefined by this specification;
1619    previously, it was defined in Section 7.1 of [RFC2817].
1620 
1621    (Section 8.2)
1622
1623NEW:
1624
1625    The Status Code Registry has been redefined by this specification;
1626    previously, it was defined in Section 7.1 of [RFC2817] (Section 8.2).
1627
1628
1629Appendix B., paragraph 27:
1630OLD:
1631
1632    Registration of Content Codings has been changed to require IETF
1633    Review.  (Section 8.4)
1634
1635NEW:
1636
1637    Registration of content codings has been changed to require IETF
1638    Review (Section 8.4).
1639
1640
1641Section 1.2, paragraph 1:
1642OLD:
1643
1644    Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
1645     OWS ( media-range [ accept-params ] ) ] ) ]
1646    Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS
1647     "," [ OWS ( ( charset / "*" ) [ weight ] ) ] )
1648    Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS
1649     ( codings [ weight ] ) ] ) ]
1650    Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS
1651     "," [ OWS ( language-range [ weight ] ) ] )
1652    Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ]
1653    BWS = <BWS, defined in [RFC7230], Section 3.2.3>
1654
1655NEW:
1656
1657    Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
1658     OWS ( media-range [ accept-params ] ) ] ) ]
1659    Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS
1660     "," [ OWS ( ( charset / "*" ) [ weight ] ) ] )
1661    Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS
1662     ( codings [ weight ] ) ] ) ]
1663    Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS
1664     "," [ OWS ( language-range [ weight ] ) ] )
1665    Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ]
1666 
1667    BWS = <BWS, defined in [RFC7230], Section 3.2.3>
1668
1669
1670Section 1.2, paragraph 2:
1671OLD:
1672
1673    Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS
1674     content-coding ] )
1675    Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS
1676     language-tag ] )
1677    Content-Location = absolute-URI / partial-URI
1678    Content-Type = media-type
1679 
1680    Date = HTTP-date
1681
1682NEW:
1683
1684    Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS
1685     content-coding ] )
1686    Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS
1687     language-tag ] )
1688    Content-Location = absolute-URI / partial-URI
1689    Content-Type = media-type
1690    Date = HTTP-date
1691
1692
1693Section 1.2, paragraph 16:
1694OLD:
1695
1696    charset = token
1697    codings = content-coding / "identity" / "*"
1698    comment = <comment, defined in [RFC7230], Section 3.2.6>
1699    content-coding = token
1700    date1 = day SP month SP year
1701    date2 = day "-" month "-" 2DIGIT
1702    date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
1703    day = 2DIGIT
1704    day-name = %x4D.6F.6E ; Mon
1705     / %x54.75.65 ; Tue
1706     / %x57.65.64 ; Wed
1707     / %x54.68.75 ; Thu
1708     / %x46.72.69 ; Fri
1709     / %x53.61.74 ; Sat
1710     / %x53.75.6E ; Sun
1711    day-name-l = %x4D.6F.6E.64.61.79 ; Monday
1712     / %x54.75.65.73.64.61.79 ; Tuesday
1713     / %x57.65.64.6E.65.73.64.61.79 ; Wednesday
1714     / %x54.68.75.72.73.64.61.79 ; Thursday
1715     / %x46.72.69.64.61.79 ; Friday
1716     / %x53.61.74.75.72.64.61.79 ; Saturday
1717     / %x53.75.6E.64.61.79 ; Sunday
1718    delay-seconds = 1*DIGIT
1719
1720NEW:
1721
1722    charset = token
1723    codings = content-coding / "identity" / "*"
1724    comment = <comment, defined in [RFC7230], Section 3.2.6>
1725    content-coding = token
1726 
1727    date1 = day SP month SP year
1728    date2 = day "-" month "-" 2DIGIT
1729    date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
1730    day = 2DIGIT
1731    day-name = %x4D.6F.6E ; Mon
1732     / %x54.75.65 ; Tue
1733     / %x57.65.64 ; Wed
1734     / %x54.68.75 ; Thu
1735     / %x46.72.69 ; Fri
1736     / %x53.61.74 ; Sat
1737     / %x53.75.6E ; Sun
1738    day-name-l = %x4D.6F.6E.64.61.79 ; Monday
1739     / %x54.75.65.73.64.61.79 ; Tuesday
1740     / %x57.65.64.6E.65.73.64.61.79 ; Wednesday
1741     / %x54.68.75.72.73.64.61.79 ; Thursday
1742     / %x46.72.69.64.61.79 ; Friday
1743     / %x53.61.74.75.72.64.61.79 ; Saturday
1744     / %x53.75.6E.64.61.79 ; Sunday
1745    delay-seconds = 1*DIGIT
1746
1747
1748Section 1.2, paragraph 21:
1749OLD:
1750
1751    obs-date = rfc850-date / asctime-date
1752    parameter = token "=" ( token / quoted-string )
1753    partial-URI = <partial-URI, defined in [RFC7230], Section 2.7>
1754    product = token [ "/" product-version ]
1755    product-version = token
1756 
1757    quoted-string = <quoted-string, defined in [RFC7230], Section 3.2.6>
1758    qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
1759
1760NEW:
1761
1762    obs-date = rfc850-date / asctime-date
1763 
1764    parameter = token "=" ( token / quoted-string )
1765    partial-URI = <partial-URI, defined in [RFC7230], Section 2.7>
1766    product = token [ "/" product-version ]
1767    product-version = token
1768    quoted-string = <quoted-string, defined in [RFC7230], Section 3.2.6>
1769    qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
1770
1771
1772Section 1.2, paragraph 47:
1773OLD:
1774
1775    M
1776       Max-Forwards header field  36
1777       MIME-Version header field  89
1778
1779NEW:
1780
1781    M
1782       Max-Forwards header field  36
1783       MIME-Version header field  88
1784
1785
1786Section 345, paragraph 1:
1787OLD:
1788
1789    EMail: fielding@gbiv.com
1790    URI:   http://roy.gbiv.com/
1791    Julian F. Reschke (editor)
1792    greenbytes GmbH
1793    Hafenweg 16
1794    Muenster, NW  48155
1795    Germany
1796
1797NEW:
1798
1799    EMail: fielding@gbiv.com
1800    URI:   http://roy.gbiv.com/
1801 
1802    Julian F. Reschke (editor)
1803    greenbytes GmbH
1804    Hafenweg 16
1805    Muenster, NW  48155
1806    Germany
1807
Note: See TracBrowser for help on using the repository browser.