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

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

revert changes for auth48 boilerplate checks (#553)

  • Property svn:eol-style set to native
File size: 69.8 KB
Line 
1
2INTRODUCTION, paragraph 1:
3OLD:
4
5 HTTPbis Working Group                                   R. Fielding, Ed.
6 Internet-Draft                                                     Adobe
7 Obsoletes: 2616 (if approved)                            J. Reschke, Ed.
8 Updates: 2817 (if approved)                                   greenbytes
9 Intended status: Standards Track                            June 6, 2014
10 Expires: December 8, 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                                      June 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 December 8, 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
102INTRODUCTION, paragraph 14:
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
121NEW:
122
123    1. Introduction ....................................................6
124       1.1. Conformance and Error Handling .............................6
125       1.2. Syntax Notation ............................................6
126    2. Resources .......................................................7
127    3. Representations .................................................7
128       3.1. Representation Metadata ....................................8
129            3.1.1. Processing Representation Data ......................8
130            3.1.2. Encoding for Compression or Integrity ..............11
131            3.1.3. Audience Language ..................................13
132            3.1.4. Identification .....................................14
133       3.2. Representation Data .......................................17
134       3.3. Payload Semantics .........................................17
135       3.4. Content Negotiation .......................................18
136            3.4.1. Proactive Negotiation ..............................19
137            3.4.2. Reactive Negotiation ...............................20
138    4. Request Methods ................................................21
139       4.1. Overview ..................................................21
140       4.2. Common Method Properties ..................................22
141            4.2.1. Safe Methods .......................................22
142            4.2.2. Idempotent Methods .................................23
143            4.2.3. Cacheable Methods ..................................24
144       4.3. Method Definitions ........................................24
145            4.3.1. GET ................................................24
146            4.3.2. HEAD ...............................................25
147            4.3.3. POST ...............................................25
148            4.3.4. PUT ................................................26
149            4.3.5. DELETE .............................................29
150            4.3.6. CONNECT ............................................30
151            4.3.7. OPTIONS ............................................31
152            4.3.8. TRACE ..............................................32
153    5. Request Header Fields ..........................................33
154       5.1. Controls ..................................................33
155            5.1.1. Expect .............................................34
156            5.1.2. Max-Forwards .......................................36
157       5.2. Conditionals ..............................................36
158       5.3. Content Negotiation .......................................37
159            5.3.1. Quality Values .....................................37
160            5.3.2. Accept .............................................38
161            5.3.3. Accept-Charset .....................................40
162            5.3.4. Accept-Encoding ....................................41
163            5.3.5. Accept-Language ....................................42
164       5.4. Authentication Credentials ................................44
165       5.5. Request Context ...........................................44
166            5.5.1. From ...............................................44
167            5.5.2. Referer ............................................45
168            5.5.3. User-Agent .........................................46
169
170
171INTRODUCTION, paragraph 15:
172OLD:
173
174    4.  Request Methods  . . . . . . . . . . . . . . . . . . . . . . . 21
175      4.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . 21
176      4.2.  Common Method Properties . . . . . . . . . . . . . . . . . 22
177        4.2.1.  Safe Methods . . . . . . . . . . . . . . . . . . . . . 22
178        4.2.2.  Idempotent Methods . . . . . . . . . . . . . . . . . . 23
179        4.2.3.  Cacheable Methods  . . . . . . . . . . . . . . . . . . 24
180      4.3.  Method Definitions . . . . . . . . . . . . . . . . . . . . 24
181        4.3.1.  GET  . . . . . . . . . . . . . . . . . . . . . . . . . 24
182        4.3.2.  HEAD . . . . . . . . . . . . . . . . . . . . . . . . . 25
183        4.3.3.  POST . . . . . . . . . . . . . . . . . . . . . . . . . 25
184        4.3.4.  PUT  . . . . . . . . . . . . . . . . . . . . . . . . . 26
185        4.3.5.  DELETE . . . . . . . . . . . . . . . . . . . . . . . . 29
186        4.3.6.  CONNECT  . . . . . . . . . . . . . . . . . . . . . . . 30
187        4.3.7.  OPTIONS  . . . . . . . . . . . . . . . . . . . . . . . 31
188        4.3.8.  TRACE  . . . . . . . . . . . . . . . . . . . . . . . . 32
189    5.  Request Header Fields  . . . . . . . . . . . . . . . . . . . . 33
190      5.1.  Controls . . . . . . . . . . . . . . . . . . . . . . . . . 33
191        5.1.1.  Expect . . . . . . . . . . . . . . . . . . . . . . . . 34
192        5.1.2.  Max-Forwards . . . . . . . . . . . . . . . . . . . . . 36
193      5.2.  Conditionals . . . . . . . . . . . . . . . . . . . . . . . 36
194      5.3.  Content Negotiation  . . . . . . . . . . . . . . . . . . . 37
195        5.3.1.  Quality Values . . . . . . . . . . . . . . . . . . . . 37
196        5.3.2.  Accept . . . . . . . . . . . . . . . . . . . . . . . . 38
197        5.3.3.  Accept-Charset . . . . . . . . . . . . . . . . . . . . 40
198        5.3.4.  Accept-Encoding  . . . . . . . . . . . . . . . . . . . 41
199        5.3.5.  Accept-Language  . . . . . . . . . . . . . . . . . . . 42
200      5.4.  Authentication Credentials . . . . . . . . . . . . . . . . 43
201      5.5.  Request Context  . . . . . . . . . . . . . . . . . . . . . 44
202        5.5.1.  From . . . . . . . . . . . . . . . . . . . . . . . . . 44
203        5.5.2.  Referer  . . . . . . . . . . . . . . . . . . . . . . . 45
204        5.5.3.  User-Agent . . . . . . . . . . . . . . . . . . . . . . 46
205    6.  Response Status Codes  . . . . . . . . . . . . . . . . . . . . 47
206      6.1.  Overview of Status Codes . . . . . . . . . . . . . . . . . 48
207      6.2.  Informational 1xx  . . . . . . . . . . . . . . . . . . . . 50
208        6.2.1.  100 Continue . . . . . . . . . . . . . . . . . . . . . 50
209        6.2.2.  101 Switching Protocols  . . . . . . . . . . . . . . . 50
210      6.3.  Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 51
211        6.3.1.  200 OK . . . . . . . . . . . . . . . . . . . . . . . . 51
212        6.3.2.  201 Created  . . . . . . . . . . . . . . . . . . . . . 51
213        6.3.3.  202 Accepted . . . . . . . . . . . . . . . . . . . . . 52
214        6.3.4.  203 Non-Authoritative Information  . . . . . . . . . . 52
215        6.3.5.  204 No Content . . . . . . . . . . . . . . . . . . . . 53
216        6.3.6.  205 Reset Content  . . . . . . . . . . . . . . . . . . 53
217      6.4.  Redirection 3xx  . . . . . . . . . . . . . . . . . . . . . 54
218        6.4.1.  300 Multiple Choices . . . . . . . . . . . . . . . . . 55
219        6.4.2.  301 Moved Permanently  . . . . . . . . . . . . . . . . 56
220        6.4.3.  302 Found  . . . . . . . . . . . . . . . . . . . . . . 56
221        6.4.4.  303 See Other  . . . . . . . . . . . . . . . . . . . . 57
222        6.4.5.  305 Use Proxy  . . . . . . . . . . . . . . . . . . . . 57
223        6.4.6.  306 (Unused) . . . . . . . . . . . . . . . . . . . . . 57
224        6.4.7.  307 Temporary Redirect . . . . . . . . . . . . . . . . 58
225      6.5.  Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 58
226        6.5.1.  400 Bad Request  . . . . . . . . . . . . . . . . . . . 58
227        6.5.2.  402 Payment Required . . . . . . . . . . . . . . . . . 58
228        6.5.3.  403 Forbidden  . . . . . . . . . . . . . . . . . . . . 58
229        6.5.4.  404 Not Found  . . . . . . . . . . . . . . . . . . . . 59
230        6.5.5.  405 Method Not Allowed . . . . . . . . . . . . . . . . 59
231        6.5.6.  406 Not Acceptable . . . . . . . . . . . . . . . . . . 59
232        6.5.7.  408 Request Timeout  . . . . . . . . . . . . . . . . . 60
233        6.5.8.  409 Conflict . . . . . . . . . . . . . . . . . . . . . 60
234        6.5.9.  410 Gone . . . . . . . . . . . . . . . . . . . . . . . 60
235        6.5.10. 411 Length Required  . . . . . . . . . . . . . . . . . 61
236        6.5.11. 413 Payload Too Large  . . . . . . . . . . . . . . . . 61
237        6.5.12. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 61
238        6.5.13. 415 Unsupported Media Type . . . . . . . . . . . . . . 61
239        6.5.14. 417 Expectation Failed . . . . . . . . . . . . . . . . 62
240        6.5.15. 426 Upgrade Required . . . . . . . . . . . . . . . . . 62
241      6.6.  Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 62
242        6.6.1.  500 Internal Server Error  . . . . . . . . . . . . . . 62
243        6.6.2.  501 Not Implemented  . . . . . . . . . . . . . . . . . 63
244        6.6.3.  502 Bad Gateway  . . . . . . . . . . . . . . . . . . . 63
245        6.6.4.  503 Service Unavailable  . . . . . . . . . . . . . . . 63
246        6.6.5.  504 Gateway Timeout  . . . . . . . . . . . . . . . . . 63
247        6.6.6.  505 HTTP Version Not Supported . . . . . . . . . . . . 63
248    7.  Response Header Fields . . . . . . . . . . . . . . . . . . . . 64
249      7.1.  Control Data . . . . . . . . . . . . . . . . . . . . . . . 64
250        7.1.1.  Origination Date . . . . . . . . . . . . . . . . . . . 64
251        7.1.2.  Location . . . . . . . . . . . . . . . . . . . . . . . 68
252        7.1.3.  Retry-After  . . . . . . . . . . . . . . . . . . . . . 69
253        7.1.4.  Vary . . . . . . . . . . . . . . . . . . . . . . . . . 70
254      7.2.  Validator Header Fields  . . . . . . . . . . . . . . . . . 71
255      7.3.  Authentication Challenges  . . . . . . . . . . . . . . . . 72
256      7.4.  Response Context . . . . . . . . . . . . . . . . . . . . . 72
257        7.4.1.  Allow  . . . . . . . . . . . . . . . . . . . . . . . . 72
258        7.4.2.  Server . . . . . . . . . . . . . . . . . . . . . . . . 73
259    8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 73
260      8.1.  Method Registry  . . . . . . . . . . . . . . . . . . . . . 74
261        8.1.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 74
262        8.1.2.  Considerations for New Methods . . . . . . . . . . . . 74
263        8.1.3.  Registrations  . . . . . . . . . . . . . . . . . . . . 75
264      8.2.  Status Code Registry . . . . . . . . . . . . . . . . . . . 75
265        8.2.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 75
266        8.2.2.  Considerations for New Status Codes  . . . . . . . . . 76
267        8.2.3.  Registrations  . . . . . . . . . . . . . . . . . . . . 76
268      8.3.  Header Field Registry  . . . . . . . . . . . . . . . . . . 77
269        8.3.1.  Considerations for New Header Fields . . . . . . . . . 78
270        8.3.2.  Registrations  . . . . . . . . . . . . . . . . . . . . 80
271      8.4.  Content Coding Registry  . . . . . . . . . . . . . . . . . 80
272        8.4.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 81
273        8.4.2.  Registrations  . . . . . . . . . . . . . . . . . . . . 81
274    9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 81
275      9.1.  Attacks Based on File and Path Names . . . . . . . . . . . 82
276      9.2.  Attacks Based on Command, Code, or Query Injection . . . . 82
277      9.3.  Disclosure of Personal Information . . . . . . . . . . . . 83
278      9.4.  Disclosure of Sensitive Information in URIs  . . . . . . . 83
279      9.5.  Disclosure of Fragment after Redirects . . . . . . . . . . 83
280      9.6.  Disclosure of Product Information  . . . . . . . . . . . . 84
281      9.7.  Browser Fingerprinting . . . . . . . . . . . . . . . . . . 84
282    10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 85
283    11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 85
284      11.1. Normative References . . . . . . . . . . . . . . . . . . . 85
285      11.2. Informative References . . . . . . . . . . . . . . . . . . 86
286    Appendix A.  Differences between HTTP and MIME . . . . . . . . . . 88
287      A.1.  MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 89
288      A.2.  Conversion to Canonical Form . . . . . . . . . . . . . . . 89
289      A.3.  Conversion of Date Formats . . . . . . . . . . . . . . . . 89
290      A.4.  Conversion of Content-Encoding . . . . . . . . . . . . . . 89
291      A.5.  Conversion of Content-Transfer-Encoding  . . . . . . . . . 90
292      A.6.  MHTML and Line Length Limitations  . . . . . . . . . . . . 90
293    Appendix B.  Changes from RFC 2616 . . . . . . . . . . . . . . . . 90
294    Appendix C.  Imported ABNF . . . . . . . . . . . . . . . . . . . . 93
295    Appendix D.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 93
296    Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
297
298NEW:
299
300    6. Response Status Codes ..........................................47
301       6.1. Overview of Status Codes ..................................48
302       6.2. Informational 1xx .........................................50
303            6.2.1. 100 Continue .......................................50
304            6.2.2. 101 Switching Protocols ............................50
305       6.3. Successful 2xx ............................................51
306            6.3.1. 200 OK .............................................51
307            6.3.2. 201 Created ........................................52
308            6.3.3. 202 Accepted .......................................52
309            6.3.4. 203 Non-Authoritative Information ..................52
310            6.3.5. 204 No Content .....................................53
311            6.3.6. 205 Reset Content ..................................53
312       6.4. Redirection 3xx ...........................................54
313            6.4.1. 300 Multiple Choices ...............................55
314            6.4.2. 301 Moved Permanently ..............................56
315            6.4.3. 302 Found ..........................................56
316            6.4.4. 303 See Other ......................................57
317            6.4.5. 305 Use Proxy ......................................58
318            6.4.6. 306 (Unused) .......................................58
319            6.4.7. 307 Temporary Redirect .............................58
320       6.5. Client Error 4xx ..........................................58
321            6.5.1. 400 Bad Request ....................................58
322            6.5.2. 402 Payment Required ...............................59
323            6.5.3. 403 Forbidden ......................................59
324            6.5.4. 404 Not Found ......................................59
325            6.5.5. 405 Method Not Allowed .............................59
326            6.5.6. 406 Not Acceptable .................................60
327            6.5.7. 408 Request Timeout ................................60
328            6.5.8. 409 Conflict .......................................60
329            6.5.9. 410 Gone ...........................................60
330            6.5.10. 411 Length Required ...............................61
331            6.5.11. 413 Payload Too Large .............................61
332            6.5.12. 414 URI Too Long ..................................61
333            6.5.13. 415 Unsupported Media Type ........................62
334            6.5.14. 417 Expectation Failed ............................62
335            6.5.15. 426 Upgrade Required ..............................62
336       6.6. Server Error 5xx ..........................................62
337            6.6.1. 500 Internal Server Error ..........................63
338            6.6.2. 501 Not Implemented ................................63
339            6.6.3. 502 Bad Gateway ....................................63
340            6.6.4. 503 Service Unavailable ............................63
341            6.6.5. 504 Gateway Timeout ................................63
342            6.6.6. 505 HTTP Version Not Supported .....................64
343    7. Response Header Fields .........................................64
344       7.1. Control Data ..............................................64
345            7.1.1. Origination Date ...................................65
346            7.1.2. Location ...........................................68
347            7.1.3. Retry-After ........................................69
348            7.1.4. Vary ...............................................70
349       7.2. Validator Header Fields ...................................71
350       7.3. Authentication Challenges .................................72
351       7.4. Response Context ..........................................72
352            7.4.1. Allow ..............................................72
353            7.4.2. Server .............................................73
354    8. IANA Considerations ............................................73
355       8.1. Method Registry ...........................................73
356            8.1.1. Procedure ..........................................74
357            8.1.2. Considerations for New Methods .....................74
358            8.1.3. Registrations ......................................75
359       8.2. Status Code Registry ......................................75
360            8.2.1. Procedure ..........................................75
361            8.2.2. Considerations for New Status Codes ................76
362            8.2.3. Registrations ......................................76
363       8.3. Header Field Registry .....................................77
364            8.3.1. Considerations for New Header Fields ...............78
365            8.3.2. Registrations ......................................80
366       8.4. Content Coding Registry ...................................81
367            8.4.1. Procedure ..........................................81
368            8.4.2. Registrations ......................................81
369    9. Security Considerations ........................................81
370       9.1. Attacks Based on File and Path Names ......................82
371       9.2. Attacks Based on Command, Code, or Query Injection ........82
372       9.3. Disclosure of Personal Information ........................83
373       9.4. Disclosure of Sensitive Information in URIs ...............83
374       9.5. Disclosure of Fragment after Redirects ....................84
375       9.6. Disclosure of Product Information .........................84
376       9.7. Browser Fingerprinting ....................................84
377    10. Acknowledgments ...............................................85
378    11. References ....................................................85
379       11.1. Normative References .....................................85
380       11.2. Informative References ...................................86
381    Appendix A. Differences between HTTP and MIME .....................89
382       A.1. MIME-Version ..............................................89
383       A.2. Conversion to Canonical Form ..............................89
384       A.3. Conversion of Date Formats ................................90
385       A.4. Conversion of Content-Encoding ..........................90
386       A.5. Conversion of Content-Transfer-Encoding .................90
387       A.6. MHTML and Line Length Limitations .........................90
388    Appendix B. Changes from RFC 2616 .................................91
389    Appendix C. Imported ABNF .........................................93
390    Appendix D. Collected ABNF ........................................94
391    Index .............................................................97
392
393
394Section 2., paragraph 3:
395OLD:
396
397    One design goal of HTTP is to separate resource identification from
398    request semantics, which is made possible by vesting the request
399    semantics in the request method (Section 4) and a few request-
400    modifying header fields (Section 5).  If there is a conflict between
401    the method semantics and any semantic implied by the URI itself, as
402    described in Section 4.2.1, the method semantics take precedence.
403
404NEW:
405
406    One design goal of HTTP is to separate resource identification from
407    request semantics, which is made possible by vesting the request
408    semantics in the request method (Section 4) and a few
409    request-modifying header fields (Section 5).  If there is a conflict
410    between the method semantics and any semantic implied by the URI
411    itself, as described in Section 4.2.1, the method semantics take
412    precedence.
413
414
415Section 3.1.3.1., paragraph 2:
416OLD:
417
418    HTTP uses language tags within the Accept-Language and Content-
419    Language header fields.  Accept-Language uses the broader language-
420    range production defined in Section 5.3.5, whereas Content-Language
421    uses the language-tag production defined below.
422
423NEW:
424
425    HTTP uses language tags within the Accept-Language and
426    Content-Language header fields.  Accept-Language uses the broader
427    language-range production defined in Section 5.3.5, whereas
428    Content-Language uses the language-tag production defined below.
429
430
431Section 3.1.4.2., paragraph 6:
432OLD:
433
434    o  For a response to a GET or HEAD request, this is an indication
435       that the effective request URI refers to a resource that is
436       subject to content negotiation and the Content-Location field-
437       value is a more specific identifier for the selected
438       representation.
439
440NEW:
441
442    o  For a response to a GET or HEAD request, this is an indication
443       that the effective request URI refers to a resource that is
444       subject to content negotiation and the Content-Location
445       field-value is a more specific identifier for the selected
446       representation.
447
448
449Section 4.1., paragraph 6:
450OLD:
451
452    This specification defines a number of standardized methods that are
453    commonly used in HTTP, as outlined by the following table.  By
454    convention, standardized methods are defined in all-uppercase US-
455    ASCII letters.
456
457NEW:
458
459    This specification defines a number of standardized methods that are
460    commonly used in HTTP, as outlined by the following table.  By
461    convention, standardized methods are defined in all-uppercase
462    US-ASCII letters.
463
464
465Section 4.3.3., paragraph 8:
466OLD:
467
468    Responses to POST requests are only cacheable when they include
469    explicit freshness information (see Section 4.2.1 of [RFC7234]).
470    However, POST caching is not widely implemented.  For cases where an
471    origin server wishes the client to be able to cache the result of a
472    POST in a way that can be reused by a later GET, the origin server
473    MAY send a 200 (OK) response containing the result and a Content-
474    Location header field that has the same value as the POST's effective
475    request URI (Section 3.1.4.2).
476
477NEW:
478
479    Responses to POST requests are only cacheable when they include
480    explicit freshness information (see Section 4.2.1 of [RFC7234]).
481    However, POST caching is not widely implemented.  For cases where an
482    origin server wishes the client to be able to cache the result of a
483    POST in a way that can be reused by a later GET, the origin server
484    MAY send a 200 (OK) response containing the result and a
485    Content-Location header field that has the same value as the POST's
486    effective request URI (Section 3.1.4.2).
487
488
489Section 5.1.1., paragraph 5:
490OLD:
491
492    A 100-continue expectation informs recipients that the client is
493    about to send a (presumably large) message body in this request and
494    wishes to receive a 100 (Continue) interim response if the request-
495    line and header fields are not sufficient to cause an immediate
496    success, redirect, or error response.  This allows the client to wait
497    for an indication that it is worthwhile to send the message body
498    before actually doing so, which can improve efficiency when the
499    message body is huge or when the client anticipates that an error is
500    likely (e.g., when sending a state-changing method, for the first
501    time, without previously verified authentication credentials).
502
503NEW:
504
505    A 100-continue expectation informs recipients that the client is
506    about to send a (presumably large) message body in this request and
507    wishes to receive a 100 (Continue) interim response if the
508    request-line and header fields are not sufficient to cause an
509    immediate success, redirect, or error response.  This allows the
510    client to wait for an indication that it is worthwhile to send the
511    message body before actually doing so, which can improve efficiency
512    when the message body is huge or when the client anticipates that an
513    error is likely (e.g., when sending a state-changing method, for the
514    first time, without previously verified authentication credentials).
515
516
517Section 5.1.1., paragraph 19:
518OLD:
519
520    An origin server MUST, upon receiving an HTTP/1.1 (or later) request-
521    line and a complete header section that contains a 100-continue
522    expectation and indicates a request message body will follow, either
523    send an immediate response with a final status code, if that status
524    can be determined by examining just the request-line and header
525    fields, or send an immediate 100 (Continue) response to encourage the
526    client to send the request's message body.  The origin server MUST
527    NOT wait for the message body before sending the 100 (Continue)
528    response.
529
530NEW:
531
532    An origin server MUST, upon receiving an HTTP/1.1 (or later)
533    request-line and a complete header section that contains a
534    100-continue expectation and indicates a request message body will
535    follow, either send an immediate response with a final status code,
536    if that status can be determined by examining just the request-line
537    and header fields, or send an immediate 100 (Continue) response to
538    encourage the client to send the request's message body.  The origin
539    server MUST NOT wait for the message body before sending the 100
540    (Continue) response.
541
542
543Section 5.3.2., paragraph 1:
544OLD:
545
546    The "Accept" header field can be used by user agents to specify
547    response media types that are acceptable.  Accept header fields can
548    be used to indicate that the request is specifically limited to a
549    small set of desired types, as in the case of a request for an in-
550    line image.
551
552NEW:
553
554    The "Accept" header field can be used by user agents to specify
555    response media types that are acceptable.  Accept header fields can
556    be used to indicate that the request is specifically limited to a
557    small set of desired types, as in the case of a request for an
558    in-line image.
559
560
561Section 5.3.3., paragraph 5:
562OLD:
563
564    The special value "*", if present in the Accept-Charset field,
565    matches every charset that is not mentioned elsewhere in the Accept-
566    Charset field.  If no "*" is present in an Accept-Charset field, then
567    any charsets not explicitly mentioned in the field are considered
568    "not acceptable" to the client.
569
570NEW:
571
572    The special value "*", if present in the Accept-Charset field,
573    matches every charset that is not mentioned elsewhere in the
574    Accept-Charset field.  If no "*" is present in an Accept-Charset
575    field, then any charsets not explicitly mentioned in the field are
576    considered "not acceptable" to the client.
577
578
579Section 2., paragraph 0:
580OLD:
581
582    2.  If the representation has no content-coding, then it is
583        acceptable by default unless specifically excluded by the Accept-
584        Encoding field stating either "identity;q=0" or "*;q=0" without a
585        more specific entry for "identity".
586
587NEW:
588
589    2.  If the representation has no content-coding, then it is
590        acceptable by default unless specifically excluded by the
591        Accept-Encoding field stating either "identity;q=0" or "*;q=0"
592        without a more specific entry for "identity".
593
594
595Section 2., paragraph 1:
596OLD:
597
598    3.  If the representation's content-coding is one of the content-
599        codings listed in the Accept-Encoding field, then it is
600        acceptable unless it is accompanied by a qvalue of 0.  (As
601        defined in Section 5.3.1, a qvalue of 0 means "not acceptable".)
602
603NEW:
604
605    3.  If the representation's content-coding is one of the
606        content-codings listed in the Accept-Encoding field, then it is
607        acceptable unless it is accompanied by a qvalue of 0.  (As
608        defined in Section 5.3.1, a qvalue of 0 means "not acceptable".)
609
610
611Section 5.3.5., paragraph 10:
612OLD:
613
614    Since intelligibility is highly dependent on the individual user,
615    user agents need to allow user control over the linguistic preference
616    (either through configuration of the user agent itself or by
617    defaulting to a user controllable system setting).  A user agent that
618    does not provide such control to the user MUST NOT send an Accept-
619    Language header field.
620
621NEW:
622
623    Since intelligibility is highly dependent on the individual user,
624    user agents need to allow user control over the linguistic preference
625    (either through configuration of the user agent itself or by
626    defaulting to a user controllable system setting).  A user agent that
627    does not provide such control to the user MUST NOT send an
628    Accept-Language header field.
629
630
631Section 5.5.3., paragraph 5:
632OLD:
633
634    A sender SHOULD limit generated product identifiers to what is
635    necessary to identify the product; a sender MUST NOT generate
636    advertising or other nonessential information within the product
637    identifier.  A sender SHOULD NOT generate information in product-
638    version that is not a version identifier (i.e., successive versions
639    of the same product name ought to differ only in the product-version
640    portion of the product identifier).
641
642NEW:
643
644    A sender SHOULD limit generated product identifiers to what is
645    necessary to identify the product; a sender MUST NOT generate
646    advertising or other nonessential information within the product
647    identifier.  A sender SHOULD NOT generate information in
648    product-version that is not a version identifier (i.e., successive
649    versions of the same product name ought to differ only in the
650    product-version portion of the product identifier).
651
652
653Section 6.1., paragraph 3:
654OLD:
655
656    +------+-------------------------------+--------------------------+
657    | Code | Reason-Phrase                 | Defined in...            |
658    +------+-------------------------------+--------------------------+
659    | 100  | Continue                      | Section 6.2.1            |
660    | 101  | Switching Protocols           | Section 6.2.2            |
661    | 200  | OK                            | Section 6.3.1            |
662    | 201  | Created                       | Section 6.3.2            |
663    | 202  | Accepted                      | Section 6.3.3            |
664    | 203  | Non-Authoritative Information | Section 6.3.4            |
665    | 204  | No Content                    | Section 6.3.5            |
666    | 205  | Reset Content                 | Section 6.3.6            |
667    | 206  | Partial Content               | Section 4.1 of [RFC7233] |
668    | 300  | Multiple Choices              | Section 6.4.1            |
669    | 301  | Moved Permanently             | Section 6.4.2            |
670    | 302  | Found                         | Section 6.4.3            |
671    | 303  | See Other                     | Section 6.4.4            |
672    | 304  | Not Modified                  | Section 4.1 of [RFC7232] |
673    | 305  | Use Proxy                     | Section 6.4.5            |
674    | 307  | Temporary Redirect            | Section 6.4.7            |
675    | 400  | Bad Request                   | Section 6.5.1            |
676    | 401  | Unauthorized                  | Section 3.1 of [RFC7235] |
677    | 402  | Payment Required              | Section 6.5.2            |
678    | 403  | Forbidden                     | Section 6.5.3            |
679    | 404  | Not Found                     | Section 6.5.4            |
680    | 405  | Method Not Allowed            | Section 6.5.5            |
681    | 406  | Not Acceptable                | Section 6.5.6            |
682    | 407  | Proxy Authentication Required | Section 3.2 of [RFC7235] |
683    | 408  | Request Timeout               | Section 6.5.7            |
684    | 409  | Conflict                      | Section 6.5.8            |
685    | 410  | Gone                          | Section 6.5.9            |
686    | 411  | Length Required               | Section 6.5.10           |
687    | 412  | Precondition Failed           | Section 4.2 of [RFC7232] |
688    | 413  | Payload Too Large             | Section 6.5.11           |
689    | 414  | URI Too Long                  | Section 6.5.12           |
690    | 415  | Unsupported Media Type        | Section 6.5.13           |
691    | 416  | Range Not Satisfiable         | Section 4.4 of [RFC7233] |
692    | 417  | Expectation Failed            | Section 6.5.14           |
693    | 426  | Upgrade Required              | Section 6.5.15           |
694    | 500  | Internal Server Error         | Section 6.6.1            |
695    | 501  | Not Implemented               | Section 6.6.2            |
696    | 502  | Bad Gateway                   | Section 6.6.3            |
697    | 503  | Service Unavailable           | Section 6.6.4            |
698    | 504  | Gateway Timeout               | Section 6.6.5            |
699    | 505  | HTTP Version Not Supported    | Section 6.6.6            |
700    +------+-------------------------------+--------------------------+
701 
702    Note that this list is not exhaustive -- it does not include
703    extension status codes defined in other specifications.  The complete
704    list of status codes is maintained by IANA.  See Section 8.2 for
705    details.
706
707NEW:
708
709    +------+-------------------------------+--------------------------+
710    | Code | Reason-Phrase                 | Defined in...            |
711    +------+-------------------------------+--------------------------+
712    | 100  | Continue                      | Section 6.2.1            |
713    | 101  | Switching Protocols           | Section 6.2.2            |
714    | 200  | OK                            | Section 6.3.1            |
715    | 201  | Created                       | Section 6.3.2            |
716    | 202  | Accepted                      | Section 6.3.3            |
717    | 203  | Non-Authoritative Information | Section 6.3.4            |
718    | 204  | No Content                    | Section 6.3.5            |
719    | 205  | Reset Content                 | Section 6.3.6            |
720    | 206  | Partial Content               | Section 4.1 of [RFC7233] |
721    | 300  | Multiple Choices              | Section 6.4.1            |
722    | 301  | Moved Permanently             | Section 6.4.2            |
723    | 302  | Found                         | Section 6.4.3            |
724    | 303  | See Other                     | Section 6.4.4            |
725    | 304  | Not Modified                  | Section 4.1 of [RFC7232] |
726    | 305  | Use Proxy                     | Section 6.4.5            |
727    | 307  | Temporary Redirect            | Section 6.4.7            |
728    | 400  | Bad Request                   | Section 6.5.1            |
729    | 401  | Unauthorized                  | Section 3.1 of [RFC7235] |
730    | 402  | Payment Required              | Section 6.5.2            |
731    | 403  | Forbidden                     | Section 6.5.3            |
732    | 404  | Not Found                     | Section 6.5.4            |
733    | 405  | Method Not Allowed            | Section 6.5.5            |
734    | 406  | Not Acceptable                | Section 6.5.6            |
735    | 407  | Proxy Authentication Required | Section 3.2 of [RFC7235] |
736    | 408  | Request Timeout               | Section 6.5.7            |
737    | 409  | Conflict                      | Section 6.5.8            |
738    | 410  | Gone                          | Section 6.5.9            |
739    | 411  | Length Required               | Section 6.5.10           |
740    | 412  | Precondition Failed           | Section 4.2 of [RFC7232] |
741    | 413  | Payload Too Large             | Section 6.5.11           |
742    | 414  | URI Too Long                  | Section 6.5.12           |
743    | 415  | Unsupported Media Type        | Section 6.5.13           |
744    | 416  | Range Not Satisfiable         | Section 4.4 of [RFC7233] |
745    | 417  | Expectation Failed            | Section 6.5.14           |
746    | 426  | Upgrade Required              | Section 6.5.15           |
747    | 500  | Internal Server Error         | Section 6.6.1            |
748    | 501  | Not Implemented               | Section 6.6.2            |
749    | 502  | Bad Gateway                   | Section 6.6.3            |
750    | 503  | Service Unavailable           | Section 6.6.4            |
751    | 504  | Gateway Timeout               | Section 6.6.5            |
752    | 505  | HTTP Version Not Supported    | Section 6.6.6            |
753    +------+-------------------------------+--------------------------+
754    Note that this list is not exhaustive -- it does not include
755    extension status codes defined in other specifications.  The complete
756    list of status codes is maintained by IANA.  See Section 8.2 for
757    details.
758
759
760Section 6.2.1., paragraph 2:
761OLD:
762
763    When the request contains an Expect header field that includes a 100-
764    continue expectation, the 100 response indicates that the server
765    wishes to receive the request payload body, as described in
766    Section 5.1.1.  The client ought to continue sending the request and
767    discard the 100 response.
768
769NEW:
770
771    When the request contains an Expect header field that includes a
772    100-continue expectation, the 100 response indicates that the server
773    wishes to receive the request payload body, as described in
774    Section 5.1.1.  The client ought to continue sending the request and
775    discard the 100 response.
776
777
778Section 6.3.2., paragraph 2:
779OLD:
780
781    The 201 response payload typically describes and links to the
782    resource(s) created.  See Section 7.2 for a discussion of the meaning
783    and purpose of validator header fields, such as ETag and Last-
784    Modified, in a 201 response.
785
786NEW:
787
788    The 201 response payload typically describes and links to the
789    resource(s) created.  See Section 7.2 for a discussion of the meaning
790    and purpose of validator header fields, such as ETag and
791    Last-Modified, in a 201 response.
792
793
794Section 6.5.11., paragraph 2:
795OLD:
796
797    If the condition is temporary, the server SHOULD generate a Retry-
798    After header field to indicate that it is temporary and after what
799    time the client MAY try again.
800
801NEW:
802
803    If the condition is temporary, the server SHOULD generate a
804    Retry-After header field to indicate that it is temporary and after
805    what time the client MAY try again.
806
807
808Section 6.5.13., paragraph 1:
809OLD:
810
811    The 415 (Unsupported Media Type) status code indicates that the
812    origin server is refusing to service the request because the payload
813    is in a format not supported by this method on the target resource.
814    The format problem might be due to the request's indicated Content-
815    Type or Content-Encoding, or as a result of inspecting the data
816    directly.
817
818NEW:
819
820    The 415 (Unsupported Media Type) status code indicates that the
821    origin server is refusing to service the request because the payload
822    is in a format not supported by this method on the target resource.
823    The format problem might be due to the request's indicated
824    Content-Type or Content-Encoding, or as a result of inspecting the
825    data directly.
826
827
828Section 7., paragraph 1:
829OLD:
830
831    The response header fields allow the server to pass additional
832    information about the response beyond what is placed in the status-
833    line.  These header fields give information about the server, about
834    further access to the target resource, or about related resources.
835
836NEW:
837
838    The response header fields allow the server to pass additional
839    information about the response beyond what is placed in the
840    status-line.  These header fields give information about the server,
841    about further access to the target resource, or about related
842    resources.
843
844
845Section 7.1.1.1., paragraph 7:
846OLD:
847
848    A recipient that parses a timestamp value in an HTTP header field
849    MUST accept all three HTTP-date formats.  When a sender generates a
850    header field that contains one or more timestamps defined as HTTP-
851    date, the sender MUST generate those timestamps in the IMF-fixdate
852    format.
853
854NEW:
855
856    A recipient that parses a timestamp value in an HTTP header field
857    MUST accept all three HTTP-date formats.  When a sender generates a
858    header field that contains one or more timestamps defined as
859    HTTP-date, the sender MUST generate those timestamps in the
860    IMF-fixdate format.
861
862
863Section 7.1.1.1., paragraph 18:
864OLD:
865
866      obs-date     = rfc850-date / asctime-date
867      rfc850-date  = day-name-l "," SP date2 SP time-of-day SP GMT
868      date2        = day "-" month "-" 2DIGIT
869                   ; e.g., 02-Jun-82
870
871NEW:
872
873      obs-date     = rfc850-date / asctime-date
874 
875      rfc850-date  = day-name-l "," SP date2 SP time-of-day SP GMT
876      date2        = day "-" month "-" 2DIGIT
877                   ; e.g., 02-Jun-82
878
879
880Section 7.1.1.1., paragraph 21:
881OLD:
882
883    HTTP-date is case sensitive.  A sender MUST NOT generate additional
884    whitespace in an HTTP-date beyond that specifically included as SP in
885    the grammar.  The semantics of day-name, day, month, year, and time-
886    of-day are the same as those defined for the Internet Message Format
887    constructs with the corresponding name ([RFC5322], Section 3.3).
888
889NEW:
890
891    HTTP-date is case sensitive.  A sender MUST NOT generate additional
892    whitespace in an HTTP-date beyond that specifically included as SP in
893    the grammar.  The semantics of day-name, day, month, year, and
894    time-of-day are the same as those defined for the Internet Message
895    Format constructs with the corresponding name ([RFC5322], Section
896    3.3).
897
898
899Section 7.1.1.1., paragraph 23:
900OLD:
901
902    Recipients of timestamp values are encouraged to be robust in parsing
903    timestamps unless otherwise restricted by the field definition.  For
904    example, messages are occasionally forwarded over HTTP from a non-
905    HTTP source that might generate any of the date and time
906    specifications defined by the Internet Message Format.
907
908NEW:
909
910    Recipients of timestamp values are encouraged to be robust in parsing
911    timestamps unless otherwise restricted by the field definition.  For
912    example, messages are occasionally forwarded over HTTP from a
913    non-HTTP source that might generate any of the date and time
914    specifications defined by the Internet Message Format.
915
916
917Section 7.1.2., paragraph 8:
918OLD:
919
920    which suggests that the user agent redirect to
921    "http://www.example.org/People.html#tim"
922 
923    Likewise, a GET request generated for the URI reference
924    "http://www.example.org/index.html#larry" might result in a 301
925    (Moved Permanently) response containing the header field:
926
927NEW:
928
929    which suggests that the user agent redirect to
930    "http://www.example.org/People.html#tim"
931    Likewise, a GET request generated for the URI reference
932    "http://www.example.org/index.html#larry" might result in a 301
933    (Moved Permanently) response containing the header field:
934
935
936Section 7.1.4., paragraph 1:
937OLD:
938
939    The "Vary" header field in a response describes what parts of a
940    request message, aside from the method, Host header field, and
941    request target, might influence the origin server's process for
942    selecting and representing this response.  The value consists of
943    either a single asterisk ("*") or a list of header field names (case-
944    insensitive).
945
946NEW:
947
948    The "Vary" header field in a response describes what parts of a
949    request message, aside from the method, Host header field, and
950    request target, might influence the origin server's process for
951    selecting and representing this response.  The value consists of
952    either a single asterisk ("*") or a list of header field names
953    (case-insensitive).
954
955
956Section 8.1., paragraph 0:
957OLD:
958
959 8.  IANA Considerations
960 8.1.  Method Registry
961
962NEW:
963
964 8.  IANA Considerations
965 
966 8.1.  Method Registry
967
968
969Section 8.3.1., paragraph 6:
970OLD:
971
972    Because commas (",") are used as a generic delimiter between field-
973    values, they need to be treated with care if they are allowed in the
974    field-value.  Typically, components that might contain a comma are
975    protected with double-quotes using the quoted-string ABNF production.
976
977NEW:
978
979    Because commas (",") are used as a generic delimiter between
980    field-values, they need to be treated with care if they are allowed
981    in the field-value.  Typically, components that might contain a comma
982    are protected with double-quotes using the quoted-string ABNF
983    production.
984
985
986Section 8.3.1., paragraph 9:
987OLD:
988
989    Note that double-quote delimiters almost always are used with the
990    quoted-string production; using a different syntax inside double-
991    quotes will likely cause unnecessary confusion.
992
993NEW:
994
995    Note that double-quote delimiters almost always are used with the
996    quoted-string production; using a different syntax inside
997    double-quotes will likely cause unnecessary confusion.
998
999
1000Section 8.3.1., paragraph 10:
1001OLD:
1002
1003    Many header fields use a format including (case-insensitively) named
1004    parameters (for instance, Content-Type, defined in Section 3.1.1.5).
1005 
1006    Allowing both unquoted (token) and quoted (quoted-string) syntax for
1007    the parameter value enables recipients to use existing parser
1008    components.  When allowing both forms, the meaning of a parameter
1009    value ought to be independent of the syntax used for it (for an
1010    example, see the notes on parameter handling for media types in
1011    Section 3.1.1.1).
1012
1013NEW:
1014
1015    Many header fields use a format including (case-insensitively) named
1016    parameters (for instance, Content-Type, defined in Section 3.1.1.5).
1017    Allowing both unquoted (token) and quoted (quoted-string) syntax for
1018    the parameter value enables recipients to use existing parser
1019    components.  When allowing both forms, the meaning of a parameter
1020    value ought to be independent of the syntax used for it (for an
1021    example, see the notes on parameter handling for media types in
1022    Section 3.1.1.1).
1023
1024
1025Section 9.4., paragraph 2:
1026OLD:
1027
1028    Authors of services ought to avoid GET-based forms for the submission
1029    of sensitive data because that data will be placed in the request-
1030    target.  Many existing servers, proxies, and user agents log or
1031    display the request-target in places where it might be visible to
1032    third parties.  Such services ought to use POST-based form submission
1033    instead.
1034
1035NEW:
1036
1037    Authors of services ought to avoid GET-based forms for the submission
1038    of sensitive data because that data will be placed in the
1039    request-target.  Many existing servers, proxies, and user agents log
1040    or display the request-target in places where it might be visible to
1041    third parties.  Such services ought to use POST-based form submission
1042    instead.
1043
1044
1045Section 9.7., paragraph 4:
1046OLD:
1047
1048    In addition to the fingerprinting concern, detailed use of the
1049    Accept-Language header field can reveal information the user might
1050    consider to be of a private nature.  For example, understanding a
1051    given language set might be strongly correlated to membership in a
1052    particular ethnic group.  An approach that limits such loss of
1053    privacy would be for a user agent to omit the sending of Accept-
1054    Language except for sites that have been whitelisted, perhaps via
1055    interaction after detecting a Vary header field that indicates
1056    language negotiation might be useful.
1057
1058NEW:
1059
1060    In addition to the fingerprinting concern, detailed use of the
1061    Accept-Language header field can reveal information the user might
1062    consider to be of a private nature.  For example, understanding a
1063    given language set might be strongly correlated to membership in a
1064    particular ethnic group.  An approach that limits such loss of
1065    privacy would be for a user agent to omit the sending of
1066    Accept-Language except for sites that have been whitelisted, perhaps
1067    via interaction after detecting a Vary header field that indicates
1068    language negotiation might be useful.
1069
1070
1071Section 11.1., paragraph 9:
1072OLD:
1073
1074    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1075               Protocol (HTTP/1.1): Message Syntax and Routing",
1076               draft-ietf-httpbis-p1-messaging-latest (work in progress),
1077               June 2014.
1078
1079NEW:
1080
1081    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1082               Protocol (HTTP/1.1): Message Syntax and Routing",
1083               RFC 7230, June 2014.
1084
1085
1086Section 11.1., paragraph 10:
1087OLD:
1088
1089    [RFC7232]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1090               Protocol (HTTP/1.1): Conditional Requests",
1091               draft-ietf-httpbis-p4-conditional-latest (work in
1092               progress), June 2014.
1093
1094NEW:
1095
1096    [RFC7232]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1097               Protocol (HTTP/1.1): Conditional Requests", RFC 7232,
1098               June 2014.
1099
1100
1101Section 11.1., paragraph 11:
1102OLD:
1103
1104    [RFC7233]  Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
1105               "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
1106               draft-ietf-httpbis-p5-range-latest (work in progress),
1107               June 2014.
1108
1109NEW:
1110
1111    [RFC7233]  Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
1112               "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
1113               RFC 7233, June 2014.
1114
1115
1116Section 11.1., paragraph 12:
1117OLD:
1118
1119    [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1120               Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
1121               draft-ietf-httpbis-p6-cache-latest (work in progress),
1122               June 2014.
1123
1124NEW:
1125
1126    [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1127               Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
1128               RFC 7234, June 2014.
1129
1130
1131Section 11.1., paragraph 13:
1132OLD:
1133
1134    [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1135               Protocol (HTTP/1.1): Authentication",
1136               draft-ietf-httpbis-p7-auth-latest (work in progress),
1137               June 2014.
1138
1139NEW:
1140
1141    [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1142               Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014.
1143
1144
1145Section 11.2., paragraph 25:
1146OLD:
1147
1148    [RFC7238]  Reschke, J., "The Hypertext Transfer Protocol (HTTP)
1149               Status Code 308 (Permanent Redirect)",
1150               draft-reschke-http-status-308-07 (work in progress),
1151               March 2012.
1152
1153NEW:
1154
1155    [RFC7238]  Reschke, J., "The Hypertext Transfer Protocol (HTTP)
1156               Status Code 308 (Permanent Redirect)", RFC 7238,
1157               June 2014.
1158
1159
1160Appendix A., paragraph 4:
1161OLD:
1162
1163    HTTP is not a MIME-compliant protocol.  However, messages can include
1164    a single MIME-Version header field to indicate what version of the
1165    MIME protocol was used to construct the message.  Use of the MIME-
1166    Version header field indicates that the message is in full
1167    conformance with the MIME protocol (as defined in [RFC2045]).
1168    Senders are responsible for ensuring full conformance (where
1169    possible) when exporting HTTP messages to strict MIME environments.
1170
1171NEW:
1172
1173    HTTP is not a MIME-compliant protocol.  However, messages can include
1174    a single MIME-Version header field to indicate what version of the
1175    MIME protocol was used to construct the message.  Use of the
1176    MIME-Version header field indicates that the message is in full
1177    conformance with the MIME protocol (as defined in [RFC2045]).
1178    Senders are responsible for ensuring full conformance (where
1179    possible) when exporting HTTP messages to strict MIME environments.
1180
1181
1182Appendix A., paragraph 12:
1183OLD:
1184
1185    MIME does not include any concept equivalent to HTTP/1.1's Content-
1186    Encoding header field.  Since this acts as a modifier on the media
1187    type, proxies and gateways from HTTP to MIME-compliant protocols
1188    ought to either change the value of the Content-Type header field or
1189    decode the representation before forwarding the message.  (Some
1190    experimental applications of Content-Type for Internet mail have used
1191    a media-type parameter of ";conversions=<content-coding>" to perform
1192    a function equivalent to Content-Encoding.  However, this parameter
1193    is not part of the MIME standards).
1194
1195NEW:
1196
1197    MIME does not include any concept equivalent to HTTP/1.1's
1198    Content-Encoding header field.  Since this acts as a modifier on the
1199    media type, proxies and gateways from HTTP to MIME-compliant
1200    protocols ought to either change the value of the Content-Type header
1201    field or decode the representation before forwarding the message.
1202    (Some experimental applications of Content-Type for Internet mail
1203    have used a media-type parameter of ";conversions=<content-coding>"
1204    to perform a function equivalent to Content-Encoding.  However, this
1205    parameter is not part of the MIME standards).
1206
1207
1208Appendix B., paragraph 2:
1209OLD:
1210
1211    A new requirement has been added that semantics embedded in a URI be
1212    disabled when those semantics are inconsistent with the request
1213    method, since this is a common cause of interoperability failure.
1214 
1215    (Section 2)
1216
1217NEW:
1218
1219    A new requirement has been added that semantics embedded in a URI be
1220    disabled when those semantics are inconsistent with the request
1221    method, since this is a common cause of interoperability failure.
1222    (Section 2)
1223
1224
1225Appendix B., paragraph 9:
1226OLD:
1227
1228    The OPTIONS and TRACE request methods have been defined as being
1229    safe.  (Section 4.3.7 and Section 4.3.8)
1230 
1231    The Expect header field's extension mechanism has been removed due to
1232    widely-deployed broken implementations.  (Section 5.1.1)
1233
1234NEW:
1235
1236    The OPTIONS and TRACE request methods have been defined as being
1237    safe.  (Section 4.3.7 and Section 4.3.8)
1238    The Expect header field's extension mechanism has been removed due to
1239    widely-deployed broken implementations.  (Section 5.1.1)
1240
1241
1242Appendix B., paragraph 20:
1243OLD:
1244
1245    The 426 (Upgrade Required) status code has been incorporated from
1246    [RFC2817].  (Section 6.5.15)
1247 
1248    The target of requirements on HTTP-date and the Date header field
1249    have been reduced to those systems generating the date, rather than
1250    all systems sending a date.  (Section 7.1.1)
1251
1252NEW:
1253
1254    The 426 (Upgrade Required) status code has been incorporated from
1255    [RFC2817].  (Section 6.5.15)
1256    The target of requirements on HTTP-date and the Date header field
1257    have been reduced to those systems generating the date, rather than
1258    all systems sending a date.  (Section 7.1.1)
1259
1260
1261Appendix B., paragraph 24:
1262OLD:
1263
1264    The Status Code Registry has been redefined by this specification;
1265    previously, it was defined in Section 7.1 of [RFC2817].
1266 
1267    (Section 8.2)
1268
1269NEW:
1270
1271    The Status Code Registry has been redefined by this specification;
1272    previously, it was defined in Section 7.1 of [RFC2817].
1273    (Section 8.2)
1274
1275
1276Section 1.2, paragraph 1:
1277OLD:
1278
1279    Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
1280     OWS ( media-range [ accept-params ] ) ] ) ]
1281    Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS
1282     "," [ OWS ( ( charset / "*" ) [ weight ] ) ] )
1283    Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS
1284     ( codings [ weight ] ) ] ) ]
1285    Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS
1286     "," [ OWS ( language-range [ weight ] ) ] )
1287    Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ]
1288    BWS = <BWS, see [RFC7230], Section 3.2.3>
1289
1290NEW:
1291
1292    Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
1293     OWS ( media-range [ accept-params ] ) ] ) ]
1294    Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS
1295     "," [ OWS ( ( charset / "*" ) [ weight ] ) ] )
1296    Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS
1297     ( codings [ weight ] ) ] ) ]
1298    Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS
1299     "," [ OWS ( language-range [ weight ] ) ] )
1300    Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ]
1301 
1302    BWS = <BWS, see [RFC7230], Section 3.2.3>
1303
1304
1305Section 1.2, paragraph 12:
1306OLD:
1307
1308    RWS = <RWS, see [RFC7230], Section 3.2.3>
1309    Referer = absolute-URI / partial-URI
1310    Retry-After = HTTP-date / delay-seconds
1311 
1312    Server = product *( RWS ( product / comment ) )
1313
1314NEW:
1315
1316    RWS = <RWS, see [RFC7230], Section 3.2.3>
1317    Referer = absolute-URI / partial-URI
1318    Retry-After = HTTP-date / delay-seconds
1319    Server = product *( RWS ( product / comment ) )
1320
1321
1322Section 1.2, paragraph 16:
1323OLD:
1324
1325    charset = token
1326    codings = content-coding / "identity" / "*"
1327    comment = <comment, see [RFC7230], Section 3.2.6>
1328    content-coding = token
1329    date1 = day SP month SP year
1330    date2 = day "-" month "-" 2DIGIT
1331    date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
1332    day = 2DIGIT
1333    day-name = %x4D.6F.6E ; Mon
1334     / %x54.75.65 ; Tue
1335     / %x57.65.64 ; Wed
1336     / %x54.68.75 ; Thu
1337     / %x46.72.69 ; Fri
1338     / %x53.61.74 ; Sat
1339     / %x53.75.6E ; Sun
1340    day-name-l = %x4D.6F.6E.64.61.79 ; Monday
1341     / %x54.75.65.73.64.61.79 ; Tuesday
1342     / %x57.65.64.6E.65.73.64.61.79 ; Wednesday
1343     / %x54.68.75.72.73.64.61.79 ; Thursday
1344     / %x46.72.69.64.61.79 ; Friday
1345     / %x53.61.74.75.72.64.61.79 ; Saturday
1346     / %x53.75.6E.64.61.79 ; Sunday
1347    delay-seconds = 1*DIGIT
1348
1349NEW:
1350
1351    charset = token
1352    codings = content-coding / "identity" / "*"
1353    comment = <comment, see [RFC7230], Section 3.2.6>
1354    content-coding = token
1355 
1356    date1 = day SP month SP year
1357    date2 = day "-" month "-" 2DIGIT
1358    date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
1359    day = 2DIGIT
1360    day-name = %x4D.6F.6E ; Mon
1361     / %x54.75.65 ; Tue
1362     / %x57.65.64 ; Wed
1363     / %x54.68.75 ; Thu
1364     / %x46.72.69 ; Fri
1365     / %x53.61.74 ; Sat
1366     / %x53.75.6E ; Sun
1367    day-name-l = %x4D.6F.6E.64.61.79 ; Monday
1368     / %x54.75.65.73.64.61.79 ; Tuesday
1369     / %x57.65.64.6E.65.73.64.61.79 ; Wednesday
1370     / %x54.68.75.72.73.64.61.79 ; Thursday
1371     / %x46.72.69.64.61.79 ; Friday
1372     / %x53.61.74.75.72.64.61.79 ; Saturday
1373     / %x53.75.6E.64.61.79 ; Sunday
1374    delay-seconds = 1*DIGIT
1375
1376
1377Section 1.2, paragraph 20:
1378OLD:
1379
1380    mailbox = <mailbox, see [RFC5322], Section 3.4>
1381    media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS
1382     ";" OWS parameter )
1383    media-type = type "/" subtype *( OWS ";" OWS parameter )
1384    method = token
1385    minute = 2DIGIT
1386    month = %x4A.61.6E ; Jan
1387     / %x46.65.62 ; Feb
1388     / %x4D.61.72 ; Mar
1389     / %x41.70.72 ; Apr
1390     / %x4D.61.79 ; May
1391     / %x4A.75.6E ; Jun
1392     / %x4A.75.6C ; Jul
1393     / %x41.75.67 ; Aug
1394     / %x53.65.70 ; Sep
1395     / %x4F.63.74 ; Oct
1396     / %x4E.6F.76 ; Nov
1397     / %x44.65.63 ; Dec
1398
1399NEW:
1400
1401    mailbox = <mailbox, see [RFC5322], Section 3.4>
1402    media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS
1403     ";" OWS parameter )
1404 
1405    media-type = type "/" subtype *( OWS ";" OWS parameter )
1406    method = token
1407    minute = 2DIGIT
1408    month = %x4A.61.6E ; Jan
1409     / %x46.65.62 ; Feb
1410     / %x4D.61.72 ; Mar
1411     / %x41.70.72 ; Apr
1412     / %x4D.61.79 ; May
1413     / %x4A.75.6E ; Jun
1414     / %x4A.75.6C ; Jul
1415     / %x41.75.67 ; Aug
1416     / %x53.65.70 ; Sep
1417     / %x4F.63.74 ; Oct
1418     / %x4E.6F.76 ; Nov
1419     / %x44.65.63 ; Dec
1420
1421
1422Section 1.2, paragraph 21:
1423OLD:
1424
1425    obs-date = rfc850-date / asctime-date
1426    parameter = token "=" ( token / quoted-string )
1427    partial-URI = <partial-URI, see [RFC7230], Section 2.7>
1428    product = token [ "/" product-version ]
1429    product-version = token
1430 
1431    quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
1432    qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
1433
1434NEW:
1435
1436    obs-date = rfc850-date / asctime-date
1437 
1438    parameter = token "=" ( token / quoted-string )
1439    partial-URI = <partial-URI, see [RFC7230], Section 2.7>
1440    product = token [ "/" product-version ]
1441    product-version = token
1442    quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
1443    qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
1444
1445
1446Section 1.2, paragraph 34:
1447OLD:
1448
1449    2
1450       200 OK (status code)  51
1451       201 Created (status code)  51
1452       202 Accepted (status code)  52
1453       203 Non-Authoritative Information (status code)  52
1454       204 No Content (status code)  53
1455       205 Reset Content (status code)  53
1456
1457NEW:
1458
1459    2
1460       200 OK (status code)  51
1461       201 Created (status code)  52
1462       202 Accepted (status code)  52
1463       203 Non-Authoritative Information (status code)  52
1464       204 No Content (status code)  53
1465       205 Reset Content (status code)  53
1466
1467
1468Section 1.2, paragraph 35:
1469OLD:
1470
1471    3
1472       300 Multiple Choices (status code)  55
1473       301 Moved Permanently (status code)  56
1474       302 Found (status code)  56
1475       303 See Other (status code)  57
1476       305 Use Proxy (status code)  57
1477       306 (Unused) (status code)  57
1478       307 Temporary Redirect (status code)  58
1479
1480NEW:
1481
1482    3
1483       300 Multiple Choices (status code)  55
1484       301 Moved Permanently (status code)  56
1485       302 Found (status code)  56
1486       303 See Other (status code)  57
1487       305 Use Proxy (status code)  58
1488       306 (Unused) (status code)  58
1489       307 Temporary Redirect (status code)  58
1490
1491
1492Section 1.2, paragraph 36:
1493OLD:
1494
1495    4
1496       400 Bad Request (status code)  58
1497       402 Payment Required (status code)  58
1498       403 Forbidden (status code)  58
1499       404 Not Found (status code)  59
1500       405 Method Not Allowed (status code)  59
1501       406 Not Acceptable (status code)  59
1502       408 Request Timeout (status code)  60
1503       409 Conflict (status code)  60
1504       410 Gone (status code)  60
1505       411 Length Required (status code)  61
1506       413 Payload Too Large (status code)  61
1507       414 URI Too Long (status code)  61
1508       415 Unsupported Media Type (status code)  61
1509       417 Expectation Failed (status code)  62
1510       426 Upgrade Required (status code)  62
1511
1512NEW:
1513
1514    4
1515       400 Bad Request (status code)  58
1516       402 Payment Required (status code)  59
1517       403 Forbidden (status code)  59
1518       404 Not Found (status code)  59
1519       405 Method Not Allowed (status code)  59
1520       406 Not Acceptable (status code)  59
1521       408 Request Timeout (status code)  60
1522       409 Conflict (status code)  60
1523       410 Gone (status code)  60
1524       411 Length Required (status code)  61
1525       413 Payload Too Large (status code)  61
1526       414 URI Too Long (status code)  61
1527       415 Unsupported Media Type (status code)  62
1528       417 Expectation Failed (status code)  62
1529       426 Upgrade Required (status code)  62
1530
1531
1532Section 1.2, paragraph 37:
1533OLD:
1534
1535    5
1536       500 Internal Server Error (status code)  62
1537       501 Not Implemented (status code)  63
1538       502 Bad Gateway (status code)  63
1539       503 Service Unavailable (status code)  63
1540       504 Gateway Timeout (status code)  63
1541       505 HTTP Version Not Supported (status code)  63
1542
1543NEW:
1544
1545    5
1546       500 Internal Server Error (status code)  63
1547       501 Not Implemented (status code)  63
1548       502 Bad Gateway (status code)  63
1549       503 Service Unavailable (status code)  63
1550       504 Gateway Timeout (status code)  63
1551       505 HTTP Version Not Supported (status code)  64
1552
1553
1554Section 1.2, paragraph 39:
1555OLD:
1556
1557    C
1558       cacheable  24
1559       compress (content coding)  11
1560       conditional request  36
1561       CONNECT method  30
1562       content coding  11
1563       content negotiation  6
1564       Content-Encoding header field  12
1565       Content-Language header field  13
1566       Content-Location header field  15
1567       Content-Transfer-Encoding header field  90
1568       Content-Type header field  10
1569
1570NEW:
1571
1572    C
1573       cacheable  24
1574       compress (content coding)  11
1575       conditional request  36
1576       CONNECT method  30
1577       content coding  11
1578       content negotiation  6
1579       Content-Encoding header field  12
1580       Content-Language header field  13
1581       Content-Location header field  15
1582       Content-Transfer-Encoding header field  89
1583       Content-Type header field  10
1584
1585
1586Section 1.2, paragraph 43:
1587OLD:
1588
1589    G
1590       GET method  24
1591       Grammar
1592          Accept  38
1593          Accept-Charset  40
1594          Accept-Encoding  41
1595          accept-ext  38
1596          Accept-Language  42
1597          accept-params  38
1598          Allow  72
1599          asctime-date  67
1600          charset  9
1601          codings  41
1602          content-coding  11
1603          Content-Encoding  12
1604          Content-Language  13
1605          Content-Location  15
1606          Content-Type  10
1607          Date  67
1608          date1  66
1609          day  66
1610          day-name  66
1611          day-name-l  66
1612          delay-seconds  70
1613          Expect  34
1614          From  44
1615          GMT  66
1616          hour  66
1617          HTTP-date  64
1618          IMF-fixdate  66
1619          language-range  42
1620          language-tag  13
1621          Location  68
1622          Max-Forwards  36
1623          media-range  38
1624          media-type  8
1625          method  21
1626          minute  66
1627          month  66
1628          obs-date  66
1629          parameter  8
1630          product  46
1631          product-version  46
1632          qvalue  38
1633          Referer  45
1634          Retry-After  70
1635          rfc850-date  67
1636          second  66
1637          Server  73
1638          subtype  8
1639          time-of-day  66
1640          type  8
1641          User-Agent  46
1642          Vary  70
1643          weight  38
1644          year  66
1645       gzip (content coding)  11
1646
1647NEW:
1648
1649    G
1650       GET method  24
1651       Grammar
1652          Accept  38
1653          Accept-Charset  40
1654          Accept-Encoding  41
1655          accept-ext  38
1656          Accept-Language  42
1657          accept-params  38
1658          Allow  72
1659          asctime-date  66
1660          charset  9
1661          codings  41
1662          content-coding  11
1663          Content-Encoding  12
1664          Content-Language  13
1665          Content-Location  15
1666          Content-Type  10
1667          Date  67
1668          date1  65
1669          day  65
1670          day-name  65
1671          day-name-l  65
1672          delay-seconds  69
1673          Expect  34
1674          From  44
1675          GMT  65
1676          hour  65
1677          HTTP-date  65
1678          IMF-fixdate  65
1679          language-range  42
1680          language-tag  13
1681          Location  68
1682          Max-Forwards  36
1683          media-range  38
1684          media-type  8
1685          method  21
1686          minute  65
1687          month  65
1688          obs-date  66
1689          parameter  8
1690          product  46
1691          product-version  46
1692          qvalue  38
1693          Referer  45
1694          Retry-After  69
1695          rfc850-date  66
1696          second  65
1697          Server  73
1698          subtype  8
1699          time-of-day  65
1700          type  8
1701          User-Agent  46
1702          Vary  70
1703          weight  38
1704          year  65
1705       gzip (content coding)  11
1706
1707
1708Section 345, paragraph 1:
1709OLD:
1710
1711    EMail: fielding@gbiv.com
1712    URI:   http://roy.gbiv.com/
1713    Julian F. Reschke (editor)
1714    greenbytes GmbH
1715    Hafenweg 16
1716    Muenster, NW  48155
1717    Germany
1718
1719NEW:
1720
1721    EMail: fielding@gbiv.com
1722    URI:   http://roy.gbiv.com/
1723 
1724    Julian F. Reschke (editor)
1725    greenbytes GmbH
1726    Hafenweg 16
1727    Muenster, NW  48155
1728    Germany
1729
Note: See TracBrowser for help on using the repository browser.