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

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

hyphenation/spacing (#553)

File size: 76.2 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 7, 2014
10 Expires: November 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                                       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 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
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 9:
590OLD:
591
592    Additional methods, outside the scope of this specification, have
593    been standardized for use in HTTP.  All such methods ought to be
594    registered within the HTTP Method Registry maintained by IANA, as
595    defined in Section 8.1.
596
597NEW:
598
599    Additional methods, outside the scope of this specification, have
600    been standardized for use in HTTP.  All such methods ought to be
601    registered within the "Hypertext Transfer Protocol (HTTP) Method"
602    registry maintained by IANA, as defined in Section 8.1.
603
604
605Section 4.2.1., paragraph 2:
606OLD:
607
608    This definition of safe methods does not prevent an implementation
609    from including behavior that is potentially harmful, not entirely
610    read-only, or which causes side effects while invoking a safe method.
611    What is important, however, is that the client did not request that
612    additional behavior and cannot be held accountable for it.  For
613    example, most servers append request information to access log files
614    at the completion of every response, regardless of the method, and
615    that is considered safe even though the log storage might become full
616    and crash the server.  Likewise, a safe request initiated by
617    selecting an advertisement on the Web will often have the side effect
618    of charging an advertising account.
619
620NEW:
621
622    This definition of safe method does not prevent an implementation
623    from including behavior that is potentially harmful, that is not
624    entirely read-only, or that causes side effects while invoking a safe
625    method.  What is important, however, is that the client did not
626    request that additional behavior and cannot be held accountable for
627    it.  For example, most servers append request information to access
628    log files at the completion of every response, regardless of the
629    method, and that is considered safe even though the log storage might
630    become full and crash the server.  Likewise, a safe request initiated
631    by selecting an advertisement on the Web will often have the side
632    effect of charging an advertising account.
633
634
635Section 4.3.3., paragraph 6:
636OLD:
637
638    An origin server indicates response semantics by choosing an
639    appropriate status code depending on the result of processing the
640    POST request; almost all of the status codes defined by this
641    specification might be received in a response to POST (the exceptions
642    being 206, 304, and 416).
643
644NEW:
645
646    An origin server indicates response semantics by choosing an
647    appropriate status code depending on the result of processing the
648    POST request; almost all of the status codes defined by this
649    specification might be received in a response to POST (the exceptions
650    being 206 (Partial Content), 304 (Not Modified), and 416 (Range Not
651    Satisfiable)).
652
653
654Section 4.3.6., paragraph 2:
655OLD:
656
657    CONNECT is intended only for use in requests to a proxy.  An origin
658    server that receives a CONNECT request for itself MAY respond with a
659    2xx status code to indicate that a connection is established.
660    However, most origin servers do not implement CONNECT.
661
662NEW:
663
664    CONNECT is intended only for use in requests to a proxy.  An origin
665    server that receives a CONNECT request for itself MAY respond with a
666    2xx (Successful) status code to indicate that a connection is
667    established.  However, most origin servers do not implement CONNECT.
668
669
670Section 4.3.8., paragraph 2:
671OLD:
672
673    A client MUST NOT generate header fields in a TRACE request
674    containing sensitive data that might be disclosed by the response.
675 
676    For example, it would be foolish for a user agent to send stored user
677    credentials [RFC7235] or cookies [RFC6265] in a TRACE request.  The
678    final recipient of the request SHOULD exclude any request header
679    fields that are likely to contain sensitive data when that recipient
680    generates the response body.
681
682NEW:
683
684    A client MUST NOT generate header fields in a TRACE request
685    containing sensitive data that might be disclosed by the response.
686    For example, it would be foolish for a user agent to send stored user
687    credentials [RFC7235] or cookies [RFC6265] in a TRACE request.  The
688    final recipient of the request SHOULD exclude any request header
689    fields that are likely to contain sensitive data when that recipient
690    generates the response body.
691
692
693Section 5.1.1., paragraph 3:
694OLD:
695
696    The Expect field-value is case-insensitive.
697
698NEW:
699
700    The Expect field-value is case insensitive.
701
702
703Section 5.1.1., paragraph 21:
704OLD:
705
706       Note: The Expect header field was added after the original
707       publication of HTTP/1.1 [RFC2068] as both the means to request an
708       interim 100 response and the general mechanism for indicating
709       must-understand extensions.  However, the extension mechanism has
710       not been used by clients and the must-understand requirements have
711       not been implemented by many servers, rendering the extension
712       mechanism useless.  This specification has removed the extension
713       mechanism in order to simplify the definition and processing of
714       100-continue.
715
716NEW:
717
718       Note: The Expect header field was added after the original
719       publication of HTTP/1.1 [RFC2068] as both the means to request an
720       interim 100 (Continue) response and the general mechanism for
721       indicating must-understand extensions.  However, the extension
722       mechanism has not been used by clients and the must-understand
723       requirements have not been implemented by many servers, rendering
724       the extension mechanism useless.  This specification has removed
725       the extension mechanism in order to simplify the definition and
726       processing of 100-continue.
727
728
729Section 5.5.1., paragraph 1:
730OLD:
731
732    The "From" header field contains an Internet email address for a
733    human user who controls the requesting user agent.  The address ought
734    to be machine-usable, as defined by "mailbox" in Section 3.4 of
735    [RFC5322]:
736
737NEW:
738
739    The "From" header field contains an Internet email address for a
740    human user who controls the requesting user agent.  The address ought
741    to be machine usable, as defined by "mailbox" in Section 3.4 of
742    [RFC5322]:
743
744
745Section 5.5.2., paragraph 6:
746OLD:
747
748    If the target URI was obtained from a source that does not have its
749    own URI (e.g., input from the user keyboard, or an entry within the
750    user's bookmarks/favorites), the user agent MUST either exclude
751    Referer or send it with a value of "about:blank".
752
753NEW:
754
755    If the target URI was obtained from a source that does not have its
756    own URI (e.g., input from the user keyboard, or an entry within the
757    user's bookmarks/favorites), the user agent MUST either exclude the
758    Referer or send it with a value of "about:blank".
759
760
761Section 5.5.3., paragraph 1:
762OLD:
763
764    The "User-Agent" header field contains information about the user
765    agent originating the request, which is often used by servers to help
766    identify the scope of reported interoperability problems, to work
767    around or tailor responses to avoid particular user agent
768    limitations, and for analytics regarding browser or operating system
769    use.  A user agent SHOULD send a User-Agent field in each request
770    unless specifically configured not to do so.
771
772NEW:
773
774    The "User-Agent" header field contains information about the user
775    agent originating the request, which is often used by servers to help
776    identify the scope of reported interoperability problems, to work
777    around or tailor responses to avoid particular user-agent
778    limitations, and for analytics regarding browser or operating system
779    use.  A user agent SHOULD send a User-Agent field in each request
780    unless specifically configured not to do so.
781
782
783Section 5.5.3., paragraph 3:
784OLD:
785
786    The User-Agent field-value consists of one or more product
787    identifiers, each followed by zero or more comments (Section 3.2 of
788    [RFC7230]), which together identify the user agent software and its
789    significant subproducts.  By convention, the product identifiers are
790    listed in decreasing order of their significance for identifying the
791    user agent software.  Each product identifier consists of a name and
792    optional version.
793
794NEW:
795
796    The User-Agent field-value consists of one or more product
797    identifiers, each followed by zero or more comments (Section 3.2 of
798    [RFC7230]), which together identify the user-agent software and its
799    significant subproducts.  By convention, the product identifiers are
800    listed in decreasing order of their significance for identifying the
801    user-agent software.  Each product identifier consists of a name and
802    optional version.
803
804
805Section 5.5.3., paragraph 9:
806OLD:
807
808    Likewise, implementations are encouraged not to use the product
809    tokens of other implementations in order to declare compatibility
810    with them, as this circumvents the purpose of the field.  If a user
811    agent masquerades as a different user agent, recipients can assume
812    that the user intentionally desires to see responses tailored for
813    that identified user agent, even if they might not work as well for
814    the actual user agent being used.
815
816NEW:
817
818    Likewise, implementations are encouraged not to use the product
819    tokens of other implementations in order to declare compatibility
820    with them, as this circumvents the purpose of the field.  If a user
821    agent masquerades as a different user agent, recipients can assume
822    that the user intentionally desires to see responses tailored for
823    that identified user agent, even if they might not work as well for
824    the actual user agent being implemented.
825
826
827Section 6., paragraph 3:
828OLD:
829
830    For example, if an unrecognized status code of 471 is received by a
831    client, the client can assume that there was something wrong with its
832    request and treat the response as if it had received a 400 status
833    code.  The response message will usually contain a representation
834    that explains the status.
835
836NEW:
837
838    For example, if an unrecognized status code of 471 is received by a
839    client, the client can assume that there was something wrong with its
840    request and treat the response as if it had received a 400 (Bad
841    Request) status code.  The response message will usually contain a
842    representation that explains the status.
843
844
845Section 6.1., paragraph 2:
846OLD:
847
848    Responses with status codes that are defined as cacheable by default
849    (e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501 in this
850    specification) can be reused by a cache with heuristic expiration
851    unless otherwise indicated by the method definition or explicit cache
852    controls [RFC7234]; all other status codes are not cacheable by
853    default.
854
855NEW:
856
857    Responses with status codes that are defined as cacheable by default
858    (e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501 in
859    this specification) can be reused by a cache with heuristic
860    expiration unless otherwise indicated by the method definition or
861    explicit cache controls [RFC7234]; all other status codes are not
862    cacheable by default.
863
864
865Section 6.4.1., paragraph 5:
866OLD:
867
868       Note: The original proposal for 300 defined the URI header field
869       as providing a list of alternative representations, such that it
870       would be usable for 200, 300, and 406 responses and be transferred
871       in responses to the HEAD method.  However, lack of deployment and
872       disagreement over syntax led to both URI and Alternates (a
873       subsequent proposal) being dropped from this specification.  It is
874       possible to communicate the list using a set of Link header fields
875       [RFC5988], each with a relationship of "alternate", though
876       deployment is a chicken-and-egg problem.
877
878NEW:
879
880       Note: The original proposal for the 300 response defined the URI
881       header field as providing a list of alternative representations,
882       such that it would be usable for 200, 300, and 406 responses and
883       be transferred in responses to the HEAD method.  However, lack of
884       deployment and disagreement over syntax led to both URI and
885       Alternates (a subsequent proposal) being dropped from this
886       specification.  It is possible to communicate the list using a set
887       of Link header fields [RFC5988], each with a relationship of
888       "alternate", though deployment is a chicken-and-egg problem.
889
890
891Section 6.4.7., paragraph 3:
892OLD:
893
894       Note: This status code is similar to 302 (Found), except that it
895       does not allow changing the request method from POST to GET.  This
896       specification defines no equivalent counterpart for 301 (Moved
897       Permanently) ([RFC7238], however, defines the status code 308
898       (Permanent Redirect) for this purpose).
899
900NEW:
901
902       Note: This status code is similar to 302 (Found), except that it
903       does not allow changing the request method from POST to GET.  This
904       specification defines no equivalent counterpart for 301 (Moved
905       Permanently) ([RFC7238]; however, it defines the status code 308
906       (Permanent Redirect) for this purpose).
907
908
909Section 7.1.1.1., paragraph 11:
910OLD:
911
912      day-name     = %x4D.6F.6E ; "Mon", case-sensitive
913                   / %x54.75.65 ; "Tue", case-sensitive
914                   / %x57.65.64 ; "Wed", case-sensitive
915                   / %x54.68.75 ; "Thu", case-sensitive
916                   / %x46.72.69 ; "Fri", case-sensitive
917                   / %x53.61.74 ; "Sat", case-sensitive
918                   / %x53.75.6E ; "Sun", case-sensitive
919
920NEW:
921
922      day-name     = %x4D.6F.6E ; "Mon", case sensitive
923                   / %x54.75.65 ; "Tue", case sensitive
924                   / %x57.65.64 ; "Wed", case sensitive
925                   / %x54.68.75 ; "Thu", case sensitive
926                   / %x46.72.69 ; "Fri", case sensitive
927                   / %x53.61.74 ; "Sat", case sensitive
928                   / %x53.75.6E ; "Sun", case sensitive
929
930
931Section 7.1.1.1., paragraph 13:
932OLD:
933
934      day          = 2DIGIT
935      month        = %x4A.61.6E ; "Jan", case-sensitive
936                   / %x46.65.62 ; "Feb", case-sensitive
937                   / %x4D.61.72 ; "Mar", case-sensitive
938                   / %x41.70.72 ; "Apr", case-sensitive
939                   / %x4D.61.79 ; "May", case-sensitive
940                   / %x4A.75.6E ; "Jun", case-sensitive
941                   / %x4A.75.6C ; "Jul", case-sensitive
942                   / %x41.75.67 ; "Aug", case-sensitive
943                   / %x53.65.70 ; "Sep", case-sensitive
944                   / %x4F.63.74 ; "Oct", case-sensitive
945                   / %x4E.6F.76 ; "Nov", case-sensitive
946                   / %x44.65.63 ; "Dec", case-sensitive
947      year         = 4DIGIT
948
949NEW:
950
951      day          = 2DIGIT
952      month        = %x4A.61.6E ; "Jan", case sensitive
953                   / %x46.65.62 ; "Feb", case sensitive
954                   / %x4D.61.72 ; "Mar", case sensitive
955                   / %x41.70.72 ; "Apr", case sensitive
956                   / %x4D.61.79 ; "May", case sensitive
957                   / %x4A.75.6E ; "Jun", case sensitive
958                   / %x4A.75.6C ; "Jul", case sensitive
959                   / %x41.75.67 ; "Aug", case sensitive
960                   / %x53.65.70 ; "Sep", case sensitive
961                   / %x4F.63.74 ; "Oct", case sensitive
962                   / %x4E.6F.76 ; "Nov", case sensitive
963                   / %x44.65.63 ; "Dec", case sensitive
964      year         = 4DIGIT
965
966
967Section 7.1.1.1., paragraph 14:
968OLD:
969
970      GMT          = %x47.4D.54 ; "GMT", case-sensitive
971
972NEW:
973
974      GMT          = %x47.4D.54 ; "GMT", case sensitive
975
976
977Section 7.1.1.1., paragraph 19:
978OLD:
979
980      day-name-l   = %x4D.6F.6E.64.61.79    ; "Monday", case-sensitive
981             / %x54.75.65.73.64.61.79       ; "Tuesday", case-sensitive
982             / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive
983             / %x54.68.75.72.73.64.61.79    ; "Thursday", case-sensitive
984             / %x46.72.69.64.61.79          ; "Friday", case-sensitive
985             / %x53.61.74.75.72.64.61.79    ; "Saturday", case-sensitive
986             / %x53.75.6E.64.61.79          ; "Sunday", case-sensitive
987
988NEW:
989
990      day-name-l   = %x4D.6F.6E.64.61.79    ; "Monday", case sensitive
991             / %x54.75.65.73.64.61.79       ; "Tuesday", case sensitive
992             / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case sensitive
993             / %x54.68.75.72.73.64.61.79    ; "Thursday", case sensitive
994             / %x46.72.69.64.61.79          ; "Friday", case sensitive
995             / %x53.61.74.75.72.64.61.79    ; "Saturday", case sensitive
996             / %x53.75.6E.64.61.79          ; "Sunday", case sensitive
997
998
999Section 7.1.4., paragraph 1:
1000OLD:
1001
1002    The "Vary" header field in a response describes what parts of a
1003    request message, aside from the method, Host header field, and
1004    request target, might influence the origin server's process for
1005    selecting and representing this response.  The value consists of
1006    either a single asterisk ("*") or a list of header field names (case-
1007    insensitive).
1008
1009NEW:
1010
1011    The "Vary" header field in a response describes what parts of a
1012    request message, aside from the method, Host header field, and
1013    request target, might influence the origin server's process for
1014    selecting and representing this response.  The value consists of
1015    either a single asterisk ("*") or a list of header field names (case
1016    insensitive).
1017
1018
1019Section 1., paragraph 1:
1020OLD:
1021
1022    2.  To inform user agent recipients that this response is subject to
1023        content negotiation (Section 5.3) and that a different
1024        representation might be sent in a subsequent request if
1025        additional parameters are provided in the listed header fields
1026        (proactive negotiation).
1027
1028NEW:
1029
1030    2.  To inform user-agent recipients that this response is subject to
1031        content negotiation (Section 5.3) and that a different
1032        representation might be sent in a subsequent request if
1033        additional parameters are provided in the listed header fields
1034        (proactive negotiation).
1035
1036
1037Section 7.2., paragraph 3:
1038OLD:
1039
1040    For example, an ETag header field in a 201 response communicates the
1041    entity-tag of the newly created resource's representation, so that it
1042    can be used in later conditional requests to prevent the "lost
1043    update" problem [RFC7232].
1044
1045NEW:
1046
1047    For example, an ETag header field in a 201 (Created) response
1048    communicates the entity-tag of the newly created resource's
1049    representation, so that it can be used in later conditional requests
1050    to prevent the "lost update" problem [RFC7232].
1051
1052
1053Section 8.1., paragraph 1:
1054OLD:
1055
1056    The HTTP Method Registry defines the namespace for the request method
1057    token (Section 4).  The method registry has been created and is now
1058    maintained at <http://www.iana.org/assignments/http-methods>.
1059
1060NEW:
1061
1062    The "Hypertext Transfer Protocol (HTTP) Method Registry" defines the
1063    namespace for the request method token (Section 4).  The "HTTP Method
1064    Registry" has been created and is now maintained at
1065    <http://www.iana.org/assignments/http-methods>.
1066
1067
1068Section 8.1.2., paragraph 3:
1069OLD:
1070
1071    A new method definition needs to indicate whether it is safe
1072    (Section 4.2.1), idempotent (Section 4.2.2), cacheable
1073    (Section 4.2.3), what semantics are to be associated with the payload
1074    body if any is present in the request, and what refinements the
1075    method makes to header field or status code semantics.  If the new
1076    method is cacheable, its definition ought to describe how, and under
1077    what conditions, a cache can store a response and use it to satisfy a
1078    subsequent request.  The new method ought to describe whether it can
1079    be made conditional (Section 5.2) and, if so, how a server responds
1080    when the condition is false.  Likewise, if the new method might have
1081    some use for partial response semantics ([RFC7233]), it ought to
1082    document this, too.
1083
1084NEW:
1085
1086    A new method definition needs to indicate whether it is safe
1087    (Section 4.2.1), idempotent (Section 4.2.2), or cacheable
1088    (Section 4.2.3).  It needs to indicate what semantics are to be
1089    associated with the payload body if any is present in the request and
1090    what refinements the method makes to header field or status code
1091    semantics.  If the new method is cacheable, its definition ought to
1092    describe how, and under what conditions, a cache can store a response
1093    and use it to satisfy a subsequent request.  The new method ought to
1094    describe whether it can be made conditional (Section 5.2) and, if so,
1095    how a server responds when the condition is false.  Likewise, if the
1096    new method might have some use for partial response semantics
1097    ([RFC7233]), it ought to document this, too.
1098
1099
1100Section 8.1.3., paragraph 1:
1101OLD:
1102
1103    The HTTP Method Registry has been populated with the registrations
1104    below:
1105
1106NEW:
1107
1108    The "Hypertext Transfer Protocol (HTTP) Method Registry" has been
1109    populated with the registrations below:
1110
1111
1112Section 8.2., paragraph 1:
1113OLD:
1114
1115    The HTTP Status Code Registry defines the namespace for the response
1116    status-code token (Section 6).  The status code registry is
1117    maintained at <http://www.iana.org/assignments/http-status-codes>.
1118
1119NEW:
1120
1121    The "Hypertext Transfer Protocol (HTTP) Status Code Registry" defines
1122    the namespace for the response status-code token (Section 6).  The
1123    "HTTP Status Codes" registry is maintained at
1124    <http://www.iana.org/assignments/http-status-codes>.
1125
1126
1127Section 8.2.3., paragraph 1:
1128OLD:
1129
1130    The HTTP Status Code Registry has been updated with the registrations
1131    below:
1132
1133NEW:
1134
1135    The "HTTP Status Codes" registry has been updated with the
1136    registrations below:
1137
1138
1139Section 8.3., paragraph 1:
1140OLD:
1141
1142    HTTP header fields are registered within the Message Header Field
1143    Registry located at <http://www.iana.org/assignments/message-headers/
1144    message-header-index.html>, as defined by [BCP90].
1145
1146NEW:
1147
1148    HTTP header fields are registered within the "Message Headers"
1149    registry located at <http://www.iana.org/assignments/message-headers>
1150    as defined by [BCP90].
1151
1152
1153Section 8.3.1., paragraph 4:
1154OLD:
1155
1156    New header field values typically have their syntax defined using
1157    ABNF ([RFC5234]), using the extension defined in Section 7 of
1158    [RFC7230] as necessary, and are usually constrained to the range of
1159    ASCII characters.  Header fields needing a greater range of
1160    characters can use an encoding such as the one defined in [RFC5987].
1161
1162NEW:
1163
1164    New header field values typically have their syntax defined using
1165    ABNF ([RFC5234]) (implementing the extension defined in Section 7 of
1166    [RFC7230] as necessary), and they are usually constrained to the
1167    range of ASCII characters.  Header fields needing a greater range of
1168    characters can use an encoding such as the one defined in [RFC5987].
1169
1170
1171Section 8.3.2., paragraph 1:
1172OLD:
1173
1174    The Message Header Field Registry has been updated with the following
1175    permanent registrations:
1176
1177NEW:
1178
1179    The "Message Headers" registry has been updated with the following
1180    permanent registrations:
1181
1182
1183Section 8.4., paragraph 1:
1184OLD:
1185
1186    The HTTP Content Coding Registry defines the namespace for content
1187    coding names (Section 4.2 of [RFC7230]).  The content coding registry
1188    is maintained at <http://www.iana.org/assignments/http-parameters>.
1189
1190NEW:
1191
1192    The "HTTP Content Coding Registry" defines the namespace for content
1193    coding names (Section 4.2 of [RFC7230]).  The "HTTP Content Coding
1194    Registry" is maintained at
1195    <http://www.iana.org/assignments/http-parameters>.
1196
1197
1198Section 8.4.1., paragraph 1:
1199OLD:
1200
1201    Content Coding registrations MUST include the following fields:
1202
1203NEW:
1204
1205    Content coding registrations MUST include the following fields:
1206
1207
1208Section 8.4.1., paragraph 6:
1209OLD:
1210
1211    Values to be added to this namespace require IETF Review (see Section
1212    4.1 of [RFC5226]), and MUST conform to the purpose of content coding
1213    defined in this section.
1214
1215NEW:
1216
1217    Values to be added to this namespace require IETF Review (see Section
1218    4.1 of [RFC5226]) and MUST conform to the purpose of content coding
1219    defined in this section.
1220
1221
1222Section 8.4.2., paragraph 1:
1223OLD:
1224
1225    The HTTP Content Codings Registry has been updated with the
1226    registrations below:
1227
1228NEW:
1229
1230    The "HTTP Content Codings Registry" has been updated with the
1231    registrations below:
1232
1233
1234Section 9., paragraph 2:
1235OLD:
1236
1237    The list of considerations below is not exhaustive.  Most security
1238    concerns related to HTTP semantics are about securing server-side
1239    applications (code behind the HTTP interface), securing user agent
1240    processing of payloads received via HTTP, or secure use of the
1241    Internet in general, rather than security of the protocol.  Various
1242    organizations maintain topical information and links to current
1243    research on Web application security (e.g., [OWASP]).
1244
1245NEW:
1246
1247    The list of considerations below is not exhaustive.  Most security
1248    concerns related to HTTP semantics are about securing server-side
1249    applications (code behind the HTTP interface) or securing user-agent
1250    processing of payloads received via HTTP.  Secure use of the Internet
1251    in general, rather than security of the protocol, might also be
1252    related.  Various organizations maintain topical information and
1253    links to current research on Web application security (e.g.,
1254    [OWASP]).
1255
1256
1257Section 9.1., paragraph 3:
1258OLD:
1259
1260    Attacks based on such special names tend to focus on either denial-
1261    of-service (e.g., telling the server to read from a COM port) or
1262    disclosure of configuration and source files that are not meant to be
1263    served.
1264
1265NEW:
1266
1267    Attacks based on such special names tend to focus on either denial of
1268    service (e.g., telling the server to read from a COM port) or
1269    disclosure of configuration and source files that are not meant to be
1270    served.
1271
1272
1273Section 9.4., paragraph 3:
1274OLD:
1275
1276    Since the Referer header field tells a target site about the context
1277    that resulted in a request, it has the potential to reveal
1278    information about the user's immediate browsing history and any
1279    personal information that might be found in the referring resource's
1280    URI.  Limitations on Referer are described in Section 5.5.2 to
1281    address some of its security considerations.
1282
1283NEW:
1284
1285    Since the Referer header field tells a target site about the context
1286    that resulted in a request, it has the potential to reveal
1287    information about the user's immediate browsing history and any
1288    personal information that might be found in the referring resource's
1289    URI.  Limitations on the Referer header field are described in
1290    Section 5.5.2 to address some of its security considerations.
1291
1292
1293Section 11.1., paragraph 9:
1294OLD:
1295
1296    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1297               Protocol (HTTP/1.1): Message Syntax and Routing",
1298               draft-ietf-httpbis-p1-messaging-latest (work in progress),
1299               May 2014.
1300
1301NEW:
1302
1303    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1304               Protocol (HTTP/1.1): Message Syntax and Routing",
1305               RFC 7230, May 2014.
1306
1307
1308Section 11.1., paragraph 10:
1309OLD:
1310
1311    [RFC7232]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1312               Protocol (HTTP/1.1): Conditional Requests",
1313               draft-ietf-httpbis-p4-conditional-latest (work in
1314               progress), May 2014.
1315
1316NEW:
1317
1318    [RFC7232]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1319               Protocol (HTTP/1.1): Conditional Requests", RFC 7232,
1320               May 2014.
1321
1322
1323Section 11.1., paragraph 11:
1324OLD:
1325
1326    [RFC7233]  Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
1327               "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
1328               draft-ietf-httpbis-p5-range-latest (work in progress),
1329               May 2014.
1330
1331NEW:
1332
1333    [RFC7233]  Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
1334               "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
1335               RFC 7233, May 2014.
1336
1337
1338Section 11.1., paragraph 12:
1339OLD:
1340
1341    [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1342               Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
1343               draft-ietf-httpbis-p6-cache-latest (work in progress),
1344               May 2014.
1345
1346NEW:
1347
1348    [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
1349               Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
1350               RFC 7234, May 2014.
1351
1352
1353Section 11.1., paragraph 13:
1354OLD:
1355
1356    [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1357               Protocol (HTTP/1.1): Authentication",
1358               draft-ietf-httpbis-p7-auth-latest (work in progress),
1359               May 2014.
1360
1361NEW:
1362
1363    [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
1364               Protocol (HTTP/1.1): Authentication", RFC 7235, May 2014.
1365
1366
1367Section 11.2., paragraph 25:
1368OLD:
1369
1370    [RFC7238]  Reschke, J., "The Hypertext Transfer Protocol (HTTP)
1371               Status Code 308 (Permanent Redirect)",
1372               draft-reschke-http-status-308-07 (work in progress),
1373               March 2012.
1374
1375NEW:
1376
1377    [RFC7238]  Reschke, J., "The Hypertext Transfer Protocol (HTTP)
1378               Status Code 308 (Permanent Redirect)", RFC 7238, May 2014.
1379
1380
1381Appendix A., paragraph 16:
1382OLD:
1383
1384 A.6.  MHTML and Line Length Limitations
1385
1386NEW:
1387
1388 A.6.  MHTML and Line-Length Limitations
1389
1390
1391Appendix A., paragraph 17:
1392OLD:
1393
1394    HTTP implementations that share code with MHTML [RFC2557]
1395    implementations need to be aware of MIME line length limitations.
1396    Since HTTP does not have this limitation, HTTP does not fold long
1397    lines.  MHTML messages being transported by HTTP follow all
1398    conventions of MHTML, including line length limitations and folding,
1399    canonicalization, etc., since HTTP transfers message-bodies as
1400    payload and, aside from the "multipart/byteranges" type (Appendix A
1401    of [RFC7233]), does not interpret the content or any MIME header
1402    lines that might be contained therein.
1403
1404NEW:
1405
1406    HTTP implementations that share code with MHTML [RFC2557]
1407    implementations need to be aware of MIME line-length limitations.
1408    Since HTTP does not have this limitation, HTTP does not fold long
1409    lines.  MHTML messages being transported by HTTP follow all
1410    conventions of MHTML, including line-length limitations and folding,
1411    canonicalization, etc., since HTTP transfers message-bodies as
1412    payload and, aside from the "multipart/byteranges" type (Appendix A
1413    of [RFC7233]), does not interpret the content or any MIME header
1414    lines that might be contained therein.
1415
1416
1417Appendix B., paragraph 2:
1418OLD:
1419
1420    A new requirement has been added that semantics embedded in a URI
1421    should be disabled when those semantics are inconsistent with the
1422    request method, since this is a common cause of interoperability
1423    failure.  (Section 2)
1424
1425NEW:
1426
1427    A new requirement has been added that semantics embedded in a URI be
1428    disabled when those semantics are inconsistent with the request
1429    method, since this is a common cause of interoperability failure
1430    (Section 2).
1431
1432
1433Appendix B., paragraph 3:
1434OLD:
1435
1436    An algorithm has been added for determining if a payload is
1437    associated with a specific identifier.  (Section 3.1.4.1)
1438
1439NEW:
1440
1441    An algorithm has been added for determining if a payload is
1442    associated with a specific identifier (Section 3.1.4.1).
1443
1444
1445Appendix B., paragraph 4:
1446OLD:
1447
1448    The default charset of ISO-8859-1 for text media types has been
1449    removed; the default is now whatever the media type definition says.
1450    Likewise, special treatment of ISO-8859-1 has been removed from the
1451    Accept-Charset header field.  (Section 3.1.1.3 and Section 5.3.3)
1452
1453NEW:
1454
1455    The default charset of ISO-8859-1 for text media types has been
1456    removed; the default is now whatever the media type definition says.
1457    Likewise, special treatment of ISO-8859-1 has been removed from the
1458    Accept-Charset header field.  (Sections 3.1.1.3 and 5.3.3.)
1459
1460
1461Appendix B., paragraph 5:
1462OLD:
1463
1464    The definition of Content-Location has been changed to no longer
1465    affect the base URI for resolving relative URI references, due to
1466    poor implementation support and the undesirable effect of potentially
1467    breaking relative links in content-negotiated resources.
1468    (Section 3.1.4.2)
1469
1470NEW:
1471
1472    The definition of Content-Location has been changed to no longer
1473    affect the base URI for resolving relative URI references, due to
1474    poor implementation support and the undesirable effect of potentially
1475    breaking relative links in content-negotiated resources
1476    (Section 3.1.4.2).
1477
1478
1479Appendix B., paragraph 6:
1480OLD:
1481
1482    To be consistent with the method-neutral parsing algorithm of
1483    [RFC7230], the definition of GET has been relaxed so that requests
1484    can have a body, even though a body has no meaning for GET.
1485    (Section 4.3.1)
1486
1487NEW:
1488
1489    To be consistent with the method-neutral parsing algorithm of
1490    [RFC7230], the definition of GET has been relaxed so that requests
1491    can have a body, even though a body has no meaning for GET
1492    (Section 4.3.1).
1493
1494
1495Appendix B., paragraph 7:
1496OLD:
1497
1498    Servers are no longer required to handle all Content-* header fields
1499    and use of Content-Range has been explicitly banned in PUT requests.
1500    (Section 4.3.4)
1501
1502NEW:
1503
1504    Servers are no longer required to handle all Content-* header fields
1505    and use of Content-Range has been explicitly banned in PUT requests
1506    (Section 4.3.4).
1507
1508
1509Appendix B., paragraph 8:
1510OLD:
1511
1512    Definition of the CONNECT method has been moved from [RFC2817] to
1513    this specification.  (Section 4.3.6)
1514
1515NEW:
1516
1517    Definition of the CONNECT method has been moved from [RFC2817] to
1518    this specification (Section 4.3.6).
1519
1520
1521Appendix B., paragraph 9:
1522OLD:
1523
1524    The OPTIONS and TRACE request methods have been defined as being
1525    safe.  (Section 4.3.7 and Section 4.3.8)
1526
1527NEW:
1528
1529    The OPTIONS and TRACE request methods have been defined as being safe
1530    (Section 4.3.7 and Section 4.3.8).
1531
1532
1533Appendix B., paragraph 10:
1534OLD:
1535
1536    The Expect header field's extension mechanism has been removed due to
1537    widely-deployed broken implementations.  (Section 5.1.1)
1538
1539NEW:
1540
1541    The Expect header field's extension mechanism has been removed due to
1542    widely deployed broken implementations (Section 5.1.1).
1543
1544
1545Appendix B., paragraph 11:
1546OLD:
1547
1548    The Max-Forwards header field has been restricted to the OPTIONS and
1549    TRACE methods; previously, extension methods could have used it as
1550    well.  (Section 5.1.2)
1551
1552NEW:
1553
1554    The Max-Forwards header field has been restricted to the OPTIONS and
1555    TRACE methods; previously, extension methods could have used it as
1556    well (Section 5.1.2).
1557
1558
1559Appendix B., paragraph 12:
1560OLD:
1561
1562    The "about:blank" URI has been suggested as a value for the Referer
1563    header field when no referring URI is applicable, which distinguishes
1564    that case from others where the Referer field is not sent or has been
1565    removed.  (Section 5.5.2)
1566
1567NEW:
1568
1569    The "about:blank" URI has been suggested as a value for the Referer
1570    header field when no referring URI is applicable, which distinguishes
1571    that case from others where the Referer field is not sent or has been
1572    removed (Section 5.5.2).
1573
1574
1575Appendix B., paragraph 13:
1576OLD:
1577
1578    The following status codes are now cacheable (that is, they can be
1579    stored and reused by a cache without explicit freshness information
1580    present): 204, 404, 405, 414, 501.  (Section 6)
1581
1582NEW:
1583
1584    The following status codes are now cacheable (that is, they can be
1585    stored and reused by a cache without explicit freshness information
1586    present): 204, 404, 405, 414, 501 (Section 6).
1587
1588
1589Appendix B., paragraph 14:
1590OLD:
1591
1592    The 201 (Created) status description has been changed to allow for
1593    the possibility that more than one resource has been created.
1594    (Section 6.3.2)
1595
1596NEW:
1597
1598    The 201 (Created) status description has been changed to allow for
1599    the possibility that more than one resource has been created
1600    (Section 6.3.2).
1601
1602
1603Appendix B., paragraph 15:
1604OLD:
1605
1606    The definition of 203 (Non-Authoritative Information) has been
1607    broadened to include cases of payload transformations as well.
1608    (Section 6.3.4)
1609
1610NEW:
1611
1612    The definition of 203 (Non-Authoritative Information) has been
1613    broadened to include cases of payload transformations as well
1614    (Section 6.3.4).
1615
1616
1617Appendix B., paragraph 16:
1618OLD:
1619
1620    The set of request methods that are safe to automatically redirect is
1621    no longer closed; user agents are able to make that determination
1622    based upon the request method semantics.  The redirect status codes
1623    301, 302, and 307 no longer have normative requirements on response
1624    payloads and user interaction.  (Section 6.4)
1625
1626NEW:
1627
1628    The set of request methods that are safe to automatically redirect is
1629    no longer closed; user agents are able to make that determination
1630    based upon the request method semantics.  The redirect status codes
1631    301, 302, and 307 no longer have normative requirements on response
1632    payloads and user interaction (Section 6.4).
1633
1634
1635Appendix B., paragraph 17:
1636OLD:
1637
1638    The status codes 301 and 302 have been changed to allow user agents
1639    to rewrite the method from POST to GET.  (Sections 6.4.2 and 6.4.3)
1640
1641NEW:
1642
1643    The status codes 301 and 302 have been changed to allow user agents
1644    to rewrite the method from POST to GET.  (Sections 6.4.2 and 6.4.3.)
1645
1646
1647Appendix B., paragraph 18:
1648OLD:
1649
1650    The description of 303 (See Other) status code has been changed to
1651    allow it to be cached if explicit freshness information is given, and
1652    a specific definition has been added for a 303 response to GET.
1653    (Section 6.4.4)
1654
1655NEW:
1656
1657    The description of the 303 (See Other) status code has been changed
1658    to allow it to be cached if explicit freshness information is given,
1659    and a specific definition has been added for a 303 response to GET
1660    (Section 6.4.4).
1661
1662
1663Appendix B., paragraph 19:
1664OLD:
1665
1666    The 305 (Use Proxy) status code has been deprecated due to security
1667    concerns regarding in-band configuration of a proxy.  (Section 6.4.5)
1668
1669NEW:
1670
1671    The 305 (Use Proxy) status code has been deprecated due to security
1672    concerns regarding in-band configuration of a proxy (Section 6.4.5).
1673
1674
1675Appendix B., paragraph 20:
1676OLD:
1677
1678    The 400 (Bad Request) status code has been relaxed so that it isn't
1679    limited to syntax errors.  (Section 6.5.1)
1680
1681NEW:
1682
1683    The 400 (Bad Request) status code has been relaxed so that it isn't
1684    limited to syntax errors (Section 6.5.1).
1685
1686
1687Appendix B., paragraph 21:
1688OLD:
1689
1690    The 426 (Upgrade Required) status code has been incorporated from
1691    [RFC2817].  (Section 6.5.15)
1692
1693NEW:
1694
1695    The 426 (Upgrade Required) status code has been incorporated from
1696    [RFC2817] (Section 6.5.15).
1697
1698
1699Appendix B., paragraph 22:
1700OLD:
1701
1702    The target of requirements on HTTP-date and the Date header field
1703    have been reduced to those systems generating the date, rather than
1704    all systems sending a date.  (Section 7.1.1)
1705
1706NEW:
1707
1708    The target of requirements on HTTP-date and the Date header field
1709    have been reduced to those systems generating the date, rather than
1710    all systems sending a date (Section 7.1.1).
1711
1712
1713Appendix B., paragraph 23:
1714OLD:
1715
1716    The syntax of the Location header field has been changed to allow all
1717    URI references, including relative references and fragments, along
1718    with some clarifications as to when use of fragments would not be
1719    appropriate.  (Section 7.1.2)
1720
1721NEW:
1722
1723    The syntax of the Location header field has been changed to allow all
1724    URI references, including relative references and fragments, along
1725    with some clarifications as to when use of fragments would not be
1726    appropriate (Section 7.1.2).
1727
1728
1729Appendix B., paragraph 24:
1730OLD:
1731
1732    Allow has been reclassified as a response header field, removing the
1733    option to specify it in a PUT request.  Requirements relating to the
1734    content of Allow have been relaxed; correspondingly, clients are not
1735    required to always trust its value.  (Section 7.4.1)
1736
1737NEW:
1738
1739    Allow has been reclassified as a response header field, removing the
1740    option to specify it in a PUT request.  Requirements relating to the
1741    content of Allow have been relaxed; correspondingly, clients are not
1742    required to always trust its value (Section 7.4.1).
1743
1744
1745Appendix B., paragraph 25:
1746OLD:
1747
1748    A Method Registry has been defined.  (Section 8.1)
1749
1750NEW:
1751
1752    A Method Registry has been defined (Section 8.1).
1753
1754
1755Appendix B., paragraph 26:
1756OLD:
1757
1758    The Status Code Registry has been redefined by this specification;
1759    previously, it was defined in Section 7.1 of [RFC2817].
1760 
1761    (Section 8.2)
1762
1763NEW:
1764
1765    The Status Code Registry has been redefined by this specification;
1766    previously, it was defined in Section 7.1 of [RFC2817] (Section 8.2).
1767
1768
1769Appendix B., paragraph 27:
1770OLD:
1771
1772    Registration of Content Codings has been changed to require IETF
1773    Review.  (Section 8.4)
1774
1775NEW:
1776
1777    Registration of content codings has been changed to require IETF
1778    Review (Section 8.4).
1779
1780
1781Section 1.2, paragraph 1:
1782OLD:
1783
1784    Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
1785     OWS ( media-range [ accept-params ] ) ] ) ]
1786    Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS
1787     "," [ OWS ( ( charset / "*" ) [ weight ] ) ] )
1788    Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS
1789     ( codings [ weight ] ) ] ) ]
1790    Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS
1791     "," [ OWS ( language-range [ weight ] ) ] )
1792    Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ]
1793    BWS = <BWS, defined in [RFC7230], Section 3.2.3>
1794
1795NEW:
1796
1797    Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
1798     OWS ( media-range [ accept-params ] ) ] ) ]
1799    Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS
1800     "," [ OWS ( ( charset / "*" ) [ weight ] ) ] )
1801    Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS
1802     ( codings [ weight ] ) ] ) ]
1803    Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS
1804     "," [ OWS ( language-range [ weight ] ) ] )
1805    Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ]
1806 
1807    BWS = <BWS, defined in [RFC7230], Section 3.2.3>
1808
1809
1810Section 1.2, paragraph 2:
1811OLD:
1812
1813    Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS
1814     content-coding ] )
1815    Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS
1816     language-tag ] )
1817    Content-Location = absolute-URI / partial-URI
1818    Content-Type = media-type
1819 
1820    Date = HTTP-date
1821
1822NEW:
1823
1824    Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS
1825     content-coding ] )
1826    Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS
1827     language-tag ] )
1828    Content-Location = absolute-URI / partial-URI
1829    Content-Type = media-type
1830    Date = HTTP-date
1831
1832
1833Section 1.2, paragraph 16:
1834OLD:
1835
1836    charset = token
1837    codings = content-coding / "identity" / "*"
1838    comment = <comment, defined in [RFC7230], Section 3.2.6>
1839    content-coding = token
1840    date1 = day SP month SP year
1841    date2 = day "-" month "-" 2DIGIT
1842    date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
1843    day = 2DIGIT
1844    day-name = %x4D.6F.6E ; Mon
1845     / %x54.75.65 ; Tue
1846     / %x57.65.64 ; Wed
1847     / %x54.68.75 ; Thu
1848     / %x46.72.69 ; Fri
1849     / %x53.61.74 ; Sat
1850     / %x53.75.6E ; Sun
1851    day-name-l = %x4D.6F.6E.64.61.79 ; Monday
1852     / %x54.75.65.73.64.61.79 ; Tuesday
1853     / %x57.65.64.6E.65.73.64.61.79 ; Wednesday
1854     / %x54.68.75.72.73.64.61.79 ; Thursday
1855     / %x46.72.69.64.61.79 ; Friday
1856     / %x53.61.74.75.72.64.61.79 ; Saturday
1857     / %x53.75.6E.64.61.79 ; Sunday
1858    delay-seconds = 1*DIGIT
1859
1860NEW:
1861
1862    charset = token
1863    codings = content-coding / "identity" / "*"
1864    comment = <comment, defined in [RFC7230], Section 3.2.6>
1865    content-coding = token
1866 
1867    date1 = day SP month SP year
1868    date2 = day "-" month "-" 2DIGIT
1869    date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
1870    day = 2DIGIT
1871    day-name = %x4D.6F.6E ; Mon
1872     / %x54.75.65 ; Tue
1873     / %x57.65.64 ; Wed
1874     / %x54.68.75 ; Thu
1875     / %x46.72.69 ; Fri
1876     / %x53.61.74 ; Sat
1877     / %x53.75.6E ; Sun
1878    day-name-l = %x4D.6F.6E.64.61.79 ; Monday
1879     / %x54.75.65.73.64.61.79 ; Tuesday
1880     / %x57.65.64.6E.65.73.64.61.79 ; Wednesday
1881     / %x54.68.75.72.73.64.61.79 ; Thursday
1882     / %x46.72.69.64.61.79 ; Friday
1883     / %x53.61.74.75.72.64.61.79 ; Saturday
1884     / %x53.75.6E.64.61.79 ; Sunday
1885    delay-seconds = 1*DIGIT
1886
1887
1888Section 1.2, paragraph 21:
1889OLD:
1890
1891    obs-date = rfc850-date / asctime-date
1892    parameter = token "=" ( token / quoted-string )
1893    partial-URI = <partial-URI, defined in [RFC7230], Section 2.7>
1894    product = token [ "/" product-version ]
1895    product-version = token
1896 
1897    quoted-string = <quoted-string, defined in [RFC7230], Section 3.2.6>
1898    qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
1899
1900NEW:
1901
1902    obs-date = rfc850-date / asctime-date
1903 
1904    parameter = token "=" ( token / quoted-string )
1905    partial-URI = <partial-URI, defined in [RFC7230], Section 2.7>
1906    product = token [ "/" product-version ]
1907    product-version = token
1908    quoted-string = <quoted-string, defined in [RFC7230], Section 3.2.6>
1909    qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
1910
1911
1912Section 1.2, paragraph 47:
1913OLD:
1914
1915    M
1916       Max-Forwards header field  36
1917       MIME-Version header field  89
1918
1919NEW:
1920
1921    M
1922       Max-Forwards header field  36
1923       MIME-Version header field  88
1924
1925
1926Section 345, paragraph 1:
1927OLD:
1928
1929    EMail: fielding@gbiv.com
1930    URI:   http://roy.gbiv.com/
1931    Julian F. Reschke (editor)
1932    greenbytes GmbH
1933    Hafenweg 16
1934    Muenster, NW  48155
1935    Germany
1936
1937NEW:
1938
1939    EMail: fielding@gbiv.com
1940    URI:   http://roy.gbiv.com/
1941 
1942    Julian F. Reschke (editor)
1943    greenbytes GmbH
1944    Hafenweg 16
1945    Muenster, NW  48155
1946    Germany
1947
Note: See TracBrowser for help on using the repository browser.