source: draft-ietf-httpbis/21/draft-ietf-httpbis-p2-semantics-21.txt @ 2650

Last change on this file since 2650 was 1929, checked in by julian.reschke@…, 8 years ago

prepare release of -21 drafts on Oct 4

  • Property svn:eol-style set to native
  • Property svn:executable set to *
File size: 239.6 KB
Line 
1
2
3
4HTTPbis Working Group                                   R. Fielding, Ed.
5Internet-Draft                                                     Adobe
6Obsoletes: 2616 (if approved)                            J. Reschke, Ed.
7Updates: 2817 (if approved)                                   greenbytes
8Intended status: Standards Track                         October 4, 2012
9Expires: April 7, 2013
10
11
12     Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
13                   draft-ietf-httpbis-p2-semantics-21
14
15Abstract
16
17   The Hypertext Transfer Protocol (HTTP) is an application-level
18   protocol for distributed, collaborative, hypertext information
19   systems.  This document defines the semantics of HTTP/1.1 messages,
20   as expressed by request methods, request header fields, response
21   status codes, and response header fields, along with the payload of
22   messages (metadata and body content) and mechanisms for content
23   negotiation.
24
25Editorial Note (To be removed by RFC Editor)
26
27   Discussion of this draft takes place on the HTTPBIS working group
28   mailing list (ietf-http-wg@w3.org), which is archived at
29   <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
30
31   The current issues list is at
32   <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
33   documents (including fancy diffs) can be found at
34   <http://tools.ietf.org/wg/httpbis/>.
35
36   The changes in this draft are summarized in Appendix F.41.
37
38Status of This Memo
39
40   This Internet-Draft is submitted in full conformance with the
41   provisions of BCP 78 and BCP 79.
42
43   Internet-Drafts are working documents of the Internet Engineering
44   Task Force (IETF).  Note that other groups may also distribute
45   working documents as Internet-Drafts.  The list of current Internet-
46   Drafts is at http://datatracker.ietf.org/drafts/current/.
47
48   Internet-Drafts are draft documents valid for a maximum of six months
49   and may be updated, replaced, or obsoleted by other documents at any
50   time.  It is inappropriate to use Internet-Drafts as reference
51   material or to cite them other than as "work in progress."
52
53
54
55Fielding & Reschke        Expires April 7, 2013                 [Page 1]
56
57Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
58
59
60   This Internet-Draft will expire on April 7, 2013.
61
62Copyright Notice
63
64   Copyright (c) 2012 IETF Trust and the persons identified as the
65   document authors.  All rights reserved.
66
67   This document is subject to BCP 78 and the IETF Trust's Legal
68   Provisions Relating to IETF Documents
69   (http://trustee.ietf.org/license-info) in effect on the date of
70   publication of this document.  Please review these documents
71   carefully, as they describe your rights and restrictions with respect
72   to this document.  Code Components extracted from this document must
73   include Simplified BSD License text as described in Section 4.e of
74   the Trust Legal Provisions and are provided without warranty as
75   described in the Simplified BSD License.
76
77   This document may contain material from IETF Documents or IETF
78   Contributions published or made publicly available before November
79   10, 2008.  The person(s) controlling the copyright in some of this
80   material may not have granted the IETF Trust the right to allow
81   modifications of such material outside the IETF Standards Process.
82   Without obtaining an adequate license from the person(s) controlling
83   the copyright in such materials, this document may not be modified
84   outside the IETF Standards Process, and derivative works of it may
85   not be created outside the IETF Standards Process, except to format
86   it for publication as an RFC or to translate it into languages other
87   than English.
88
89Table of Contents
90
91   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   7
92     1.1.  Conformance and Error Handling  . . . . . . . . . . . . .   7
93     1.2.  Syntax Notation . . . . . . . . . . . . . . . . . . . . .   7
94   2.  Resource  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
95   3.  Representation  . . . . . . . . . . . . . . . . . . . . . . .   8
96     3.1.  Representation Metadata . . . . . . . . . . . . . . . . .   8
97       3.1.1.  Data Type . . . . . . . . . . . . . . . . . . . . . .   9
98       3.1.2.  Data Encoding . . . . . . . . . . . . . . . . . . . .  12
99       3.1.3.  Audience Language . . . . . . . . . . . . . . . . . .  14
100       3.1.4.  Identification  . . . . . . . . . . . . . . . . . . .  15
101     3.2.  Representation Data . . . . . . . . . . . . . . . . . . .  18
102     3.3.  Payload Semantics . . . . . . . . . . . . . . . . . . . .  18
103     3.4.  Content Negotiation . . . . . . . . . . . . . . . . . . .  19
104       3.4.1.  Proactive Negotiation . . . . . . . . . . . . . . . .  20
105       3.4.2.  Reactive Negotiation  . . . . . . . . . . . . . . . .  21
106   4.  Product Tokens  . . . . . . . . . . . . . . . . . . . . . . .  22
107   5.  Request Methods . . . . . . . . . . . . . . . . . . . . . . .  22
108
109
110
111Fielding & Reschke        Expires April 7, 2013                 [Page 2]
112
113Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
114
115
116     5.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  22
117     5.2.  Common Method Properties  . . . . . . . . . . . . . . . .  24
118       5.2.1.  Safe Methods  . . . . . . . . . . . . . . . . . . . .  24
119       5.2.2.  Idempotent Methods  . . . . . . . . . . . . . . . . .  25
120       5.2.3.  Cacheable Methods . . . . . . . . . . . . . . . . . .  25
121     5.3.  Method Definitions  . . . . . . . . . . . . . . . . . . .  25
122       5.3.1.  GET . . . . . . . . . . . . . . . . . . . . . . . . .  25
123       5.3.2.  HEAD  . . . . . . . . . . . . . . . . . . . . . . . .  26
124       5.3.3.  POST  . . . . . . . . . . . . . . . . . . . . . . . .  27
125       5.3.4.  PUT . . . . . . . . . . . . . . . . . . . . . . . . .  28
126       5.3.5.  DELETE  . . . . . . . . . . . . . . . . . . . . . . .  30
127       5.3.6.  CONNECT . . . . . . . . . . . . . . . . . . . . . . .  30
128       5.3.7.  OPTIONS . . . . . . . . . . . . . . . . . . . . . . .  32
129       5.3.8.  TRACE . . . . . . . . . . . . . . . . . . . . . . . .  33
130   6.  Request Header Fields . . . . . . . . . . . . . . . . . . . .  33
131     6.1.  Controls  . . . . . . . . . . . . . . . . . . . . . . . .  33
132       6.1.1.  Max-Forwards  . . . . . . . . . . . . . . . . . . . .  34
133       6.1.2.  Expect  . . . . . . . . . . . . . . . . . . . . . . .  34
134     6.2.  Conditionals  . . . . . . . . . . . . . . . . . . . . . .  37
135     6.3.  Content Negotiation . . . . . . . . . . . . . . . . . . .  38
136       6.3.1.  Quality Values  . . . . . . . . . . . . . . . . . . .  38
137       6.3.2.  Accept  . . . . . . . . . . . . . . . . . . . . . . .  38
138       6.3.3.  Accept-Charset  . . . . . . . . . . . . . . . . . . .  41
139       6.3.4.  Accept-Encoding . . . . . . . . . . . . . . . . . . .  41
140       6.3.5.  Accept-Language . . . . . . . . . . . . . . . . . . .  42
141     6.4.  Authentication Credentials  . . . . . . . . . . . . . . .  44
142     6.5.  Context . . . . . . . . . . . . . . . . . . . . . . . . .  44
143       6.5.1.  From  . . . . . . . . . . . . . . . . . . . . . . . .  44
144       6.5.2.  Referer . . . . . . . . . . . . . . . . . . . . . . .  45
145       6.5.3.  User-Agent  . . . . . . . . . . . . . . . . . . . . .  45
146   7.  Response Status Codes . . . . . . . . . . . . . . . . . . . .  46
147     7.1.  Overview of Status Codes  . . . . . . . . . . . . . . . .  47
148     7.2.  Informational 1xx . . . . . . . . . . . . . . . . . . . .  49
149       7.2.1.  100 Continue  . . . . . . . . . . . . . . . . . . . .  49
150       7.2.2.  101 Switching Protocols . . . . . . . . . . . . . . .  49
151     7.3.  Successful 2xx  . . . . . . . . . . . . . . . . . . . . .  50
152       7.3.1.  200 OK  . . . . . . . . . . . . . . . . . . . . . . .  50
153       7.3.2.  201 Created . . . . . . . . . . . . . . . . . . . . .  50
154       7.3.3.  202 Accepted  . . . . . . . . . . . . . . . . . . . .  51
155       7.3.4.  203 Non-Authoritative Information . . . . . . . . . .  51
156       7.3.5.  204 No Content  . . . . . . . . . . . . . . . . . . .  51
157       7.3.6.  205 Reset Content . . . . . . . . . . . . . . . . . .  52
158     7.4.  Redirection 3xx . . . . . . . . . . . . . . . . . . . . .  52
159       7.4.1.  300 Multiple Choices  . . . . . . . . . . . . . . . .  54
160       7.4.2.  301 Moved Permanently . . . . . . . . . . . . . . . .  54
161       7.4.3.  302 Found . . . . . . . . . . . . . . . . . . . . . .  55
162       7.4.4.  303 See Other . . . . . . . . . . . . . . . . . . . .  55
163       7.4.5.  305 Use Proxy . . . . . . . . . . . . . . . . . . . .  56
164
165
166
167Fielding & Reschke        Expires April 7, 2013                 [Page 3]
168
169Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
170
171
172       7.4.6.  306 (Unused)  . . . . . . . . . . . . . . . . . . . .  56
173       7.4.7.  307 Temporary Redirect  . . . . . . . . . . . . . . .  56
174     7.5.  Client Error 4xx  . . . . . . . . . . . . . . . . . . . .  56
175       7.5.1.  400 Bad Request . . . . . . . . . . . . . . . . . . .  56
176       7.5.2.  402 Payment Required  . . . . . . . . . . . . . . . .  56
177       7.5.3.  403 Forbidden . . . . . . . . . . . . . . . . . . . .  57
178       7.5.4.  404 Not Found . . . . . . . . . . . . . . . . . . . .  57
179       7.5.5.  405 Method Not Allowed  . . . . . . . . . . . . . . .  57
180       7.5.6.  406 Not Acceptable  . . . . . . . . . . . . . . . . .  57
181       7.5.7.  408 Request Timeout . . . . . . . . . . . . . . . . .  58
182       7.5.8.  409 Conflict  . . . . . . . . . . . . . . . . . . . .  58
183       7.5.9.  410 Gone  . . . . . . . . . . . . . . . . . . . . . .  58
184       7.5.10. 411 Length Required . . . . . . . . . . . . . . . . .  59
185       7.5.11. 413 Request Representation Too Large  . . . . . . . .  59
186       7.5.12. 414 URI Too Long  . . . . . . . . . . . . . . . . . .  59
187       7.5.13. 415 Unsupported Media Type  . . . . . . . . . . . . .  59
188       7.5.14. 417 Expectation Failed  . . . . . . . . . . . . . . .  60
189       7.5.15. 426 Upgrade Required  . . . . . . . . . . . . . . . .  60
190     7.6.  Server Error 5xx  . . . . . . . . . . . . . . . . . . . .  60
191       7.6.1.  500 Internal Server Error . . . . . . . . . . . . . .  60
192       7.6.2.  501 Not Implemented . . . . . . . . . . . . . . . . .  60
193       7.6.3.  502 Bad Gateway . . . . . . . . . . . . . . . . . . .  61
194       7.6.4.  503 Service Unavailable . . . . . . . . . . . . . . .  61
195       7.6.5.  504 Gateway Timeout . . . . . . . . . . . . . . . . .  61
196       7.6.6.  505 HTTP Version Not Supported  . . . . . . . . . . .  61
197   8.  Response Header Fields  . . . . . . . . . . . . . . . . . . .  61
198     8.1.  Control Data  . . . . . . . . . . . . . . . . . . . . . .  62
199       8.1.1.  Origination Date  . . . . . . . . . . . . . . . . . .  62
200       8.1.2.  Location  . . . . . . . . . . . . . . . . . . . . . .  65
201       8.1.3.  Retry-After . . . . . . . . . . . . . . . . . . . . .  66
202     8.2.  Selected Representation Header Fields . . . . . . . . . .  67
203       8.2.1.  Vary  . . . . . . . . . . . . . . . . . . . . . . . .  67
204     8.3.  Authentication Challenges . . . . . . . . . . . . . . . .  68
205     8.4.  Informative . . . . . . . . . . . . . . . . . . . . . . .  68
206       8.4.1.  Allow . . . . . . . . . . . . . . . . . . . . . . . .  69
207       8.4.2.  Server  . . . . . . . . . . . . . . . . . . . . . . .  69
208   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  70
209     9.1.  Method Registry . . . . . . . . . . . . . . . . . . . . .  70
210       9.1.1.  Procedure . . . . . . . . . . . . . . . . . . . . . .  70
211       9.1.2.  Considerations for New Methods  . . . . . . . . . . .  70
212       9.1.3.  Registrations . . . . . . . . . . . . . . . . . . . .  71
213     9.2.  Status Code Registry  . . . . . . . . . . . . . . . . . .  71
214       9.2.1.  Procedure . . . . . . . . . . . . . . . . . . . . . .  71
215       9.2.2.  Considerations for New Status Codes . . . . . . . . .  71
216       9.2.3.  Registrations . . . . . . . . . . . . . . . . . . . .  72
217     9.3.  Header Field Registry . . . . . . . . . . . . . . . . . .  73
218       9.3.1.  Considerations for New Header Fields  . . . . . . . .  74
219       9.3.2.  Registrations . . . . . . . . . . . . . . . . . . . .  75
220
221
222
223Fielding & Reschke        Expires April 7, 2013                 [Page 4]
224
225Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
226
227
228     9.4.  Content Coding Registry . . . . . . . . . . . . . . . . .  76
229       9.4.1.  Procedure . . . . . . . . . . . . . . . . . . . . . .  76
230       9.4.2.  Registrations . . . . . . . . . . . . . . . . . . . .  77
231   10. Security Considerations . . . . . . . . . . . . . . . . . . .  77
232     10.1. Transfer of Sensitive Information . . . . . . . . . . . .  77
233     10.2. Encoding Sensitive Information in URIs  . . . . . . . . .  78
234     10.3. Location Header Fields: Spoofing and Information
235           Leakage . . . . . . . . . . . . . . . . . . . . . . . . .  79
236     10.4. Security Considerations for CONNECT . . . . . . . . . . .  79
237     10.5. Privacy Issues Connected to Accept Header Fields  . . . .  79
238   11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  80
239   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  80
240     12.1. Normative References  . . . . . . . . . . . . . . . . . .  80
241     12.2. Informative References  . . . . . . . . . . . . . . . . .  81
242   Appendix A.  Differences between HTTP and MIME  . . . . . . . . .  83
243     A.1.  MIME-Version  . . . . . . . . . . . . . . . . . . . . . .  84
244     A.2.  Conversion to Canonical Form  . . . . . . . . . . . . . .  84
245     A.3.  Conversion of Date Formats  . . . . . . . . . . . . . . .  84
246     A.4.  Introduction of Content-Encoding  . . . . . . . . . . . .  85
247     A.5.  No Content-Transfer-Encoding  . . . . . . . . . . . . . .  85
248     A.6.  MHTML and Line Length Limitations . . . . . . . . . . . .  85
249   Appendix B.  Additional Features  . . . . . . . . . . . . . . . .  85
250   Appendix C.  Changes from RFC 2616  . . . . . . . . . . . . . . .  86
251   Appendix D.  Imported ABNF  . . . . . . . . . . . . . . . . . . .  88
252   Appendix E.  Collected ABNF . . . . . . . . . . . . . . . . . . .  88
253   Appendix F.  Change Log (to be removed by RFC Editor before
254                publication) . . . . . . . . . . . . . . . . . . . .  91
255     F.1.  Since RFC 2616  . . . . . . . . . . . . . . . . . . . . .  91
256     F.2.  Since draft-ietf-httpbis-p2-semantics-00  . . . . . . . .  91
257     F.3.  Since draft-ietf-httpbis-p3-payload-00  . . . . . . . . .  92
258     F.4.  Since draft-ietf-httpbis-p2-semantics-01  . . . . . . . .  93
259     F.5.  Since draft-ietf-httpbis-p3-payload-01  . . . . . . . . .  93
260     F.6.  Since draft-ietf-httpbis-p2-semantics-02  . . . . . . . .  93
261     F.7.  Since draft-ietf-httpbis-p3-payload-02  . . . . . . . . .  94
262     F.8.  Since draft-ietf-httpbis-p2-semantics-03  . . . . . . . .  95
263     F.9.  Since draft-ietf-httpbis-p3-payload-03  . . . . . . . . .  95
264     F.10. Since draft-ietf-httpbis-p2-semantics-04  . . . . . . . .  95
265     F.11. Since draft-ietf-httpbis-p3-payload-04  . . . . . . . . .  96
266     F.12. Since draft-ietf-httpbis-p2-semantics-05  . . . . . . . .  96
267     F.13. Since draft-ietf-httpbis-p3-payload-05  . . . . . . . . .  96
268     F.14. Since draft-ietf-httpbis-p2-semantics-06  . . . . . . . .  97
269     F.15. Since draft-ietf-httpbis-p3-payload-06  . . . . . . . . .  97
270     F.16. Since draft-ietf-httpbis-p2-semantics-07  . . . . . . . .  97
271     F.17. Since draft-ietf-httpbis-p3-payload-07  . . . . . . . . .  98
272     F.18. Since draft-ietf-httpbis-p2-semantics-08  . . . . . . . .  99
273     F.19. Since draft-ietf-httpbis-p3-payload-08  . . . . . . . . .  99
274     F.20. Since draft-ietf-httpbis-p2-semantics-09  . . . . . . . .  99
275     F.21. Since draft-ietf-httpbis-p3-payload-09  . . . . . . . . .  99
276
277
278
279Fielding & Reschke        Expires April 7, 2013                 [Page 5]
280
281Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
282
283
284     F.22. Since draft-ietf-httpbis-p2-semantics-10  . . . . . . . . 100
285     F.23. Since draft-ietf-httpbis-p3-payload-10  . . . . . . . . . 100
286     F.24. Since draft-ietf-httpbis-p2-semantics-11  . . . . . . . . 101
287     F.25. Since draft-ietf-httpbis-p3-payload-11  . . . . . . . . . 101
288     F.26. Since draft-ietf-httpbis-p2-semantics-12  . . . . . . . . 101
289     F.27. Since draft-ietf-httpbis-p3-payload-12  . . . . . . . . . 103
290     F.28. Since draft-ietf-httpbis-p2-semantics-13  . . . . . . . . 103
291     F.29. Since draft-ietf-httpbis-p3-payload-13  . . . . . . . . . 103
292     F.30. Since draft-ietf-httpbis-p2-semantics-14  . . . . . . . . 103
293     F.31. Since draft-ietf-httpbis-p3-payload-14  . . . . . . . . . 104
294     F.32. Since draft-ietf-httpbis-p2-semantics-15  . . . . . . . . 104
295     F.33. Since draft-ietf-httpbis-p3-payload-15  . . . . . . . . . 104
296     F.34. Since draft-ietf-httpbis-p2-semantics-16  . . . . . . . . 104
297     F.35. Since draft-ietf-httpbis-p3-payload-16  . . . . . . . . . 104
298     F.36. Since draft-ietf-httpbis-p2-semantics-17  . . . . . . . . 105
299     F.37. Since draft-ietf-httpbis-p3-payload-17  . . . . . . . . . 105
300     F.38. Since draft-ietf-httpbis-p2-semantics-18  . . . . . . . . 105
301     F.39. Since draft-ietf-httpbis-p3-payload-18  . . . . . . . . . 106
302     F.40. Since draft-ietf-httpbis-p2-semantics-19 and
303           draft-ietf-httpbis-p3-payload-19  . . . . . . . . . . . . 106
304     F.41. Since draft-ietf-httpbis-p2-semantics-20  . . . . . . . . 107
305   Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335Fielding & Reschke        Expires April 7, 2013                 [Page 6]
336
337Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
338
339
3401.  Introduction
341
342   Each Hypertext Transfer Protocol (HTTP) message is either a request
343   or a response.  A server listens on a connection for a request,
344   parses each message received, interprets the message semantics in
345   relation to the identified request target, and responds to that
346   request with one or more response messages.  A client constructs
347   request messages to communicate specific intentions, and examines
348   received responses to see if the intentions were carried out and
349   determine how to interpret the results.  This document defines
350   HTTP/1.1 request and response semantics in terms of the architecture
351   defined in [Part1].
352
353   HTTP provides a uniform interface for interacting with a resource
354   (Section 2), regardless of its type, nature, or implementation, and
355   for transferring content in message payloads in the form of a
356   representation (Section 3).
357
358   HTTP semantics include the intentions defined by each request method
359   (Section 5), extensions to those semantics that might be described in
360   request header fields (Section 6), the meaning of status codes to
361   indicate a machine-readable response (Section 7), and the meaning of
362   other control data and resource metadata that might be given in
363   response header fields (Section 8).
364
365   This document also defines representation metadata that describe how
366   a payload is intended to be interpreted by a recipient, the request
367   header fields that might influence content selection, and the various
368   selection algorithms that are collectively referred to as "content
369   negotiation" (Section 3.4).
370
3711.1.  Conformance and Error Handling
372
373   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
374   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
375   document are to be interpreted as described in [RFC2119].
376
377   Conformance criteria and considerations regarding error handling are
378   defined in Section 2.5 of [Part1].
379
3801.2.  Syntax Notation
381
382   This specification uses the Augmented Backus-Naur Form (ABNF)
383   notation of [RFC5234] with the list rule extension defined in Section
384   1.2 of [Part1].  Appendix D describes rules imported from other
385   documents.  Appendix E shows the collected ABNF with the list rule
386   expanded.
387
388
389
390
391Fielding & Reschke        Expires April 7, 2013                 [Page 7]
392
393Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
394
395
3962.  Resource
397
398   The target of each HTTP request is called a resource.  HTTP does not
399   limit the nature of a resource; it merely defines an interface that
400   might be used to interact with resources.  Each resource is
401   identified by a Uniform Resource Identifier (URI), as described in
402   Section 2.7 of [Part1].
403
404   When a client constructs an HTTP/1.1 request message, it sends the
405   "target URI" in one of various forms, as defined in (Section 5.3 of
406   [Part1]).  When a request is received, the server reconstructs an
407   "effective request URI" for the target resource (Section 5.5 of
408   [Part1]).
409
410   One design goal of HTTP is to separate resource identification from
411   request semantics, which is made possible by vesting the request
412   semantics in the request method (Section 5) and a few request-
413   modifying header fields (Section 6).  Resource owners SHOULD NOT
414   include request semantics within a URI, such as by specifying an
415   action to invoke within the path or query components of the effective
416   request URI, unless those semantics are disabled when they are
417   inconsistent with the request method.
418
4193.  Representation
420
421   If we consider that a resource could be anything, and that the
422   uniform interface provided by HTTP is similar to a window through
423   which one can observe and act upon such a thing only through the
424   communication of messages to some independent actor on the other
425   side, then we need an abstraction to represent ("take the place of")
426   the current or desired state of that thing in our communications.  We
427   call that abstraction a "representation" [REST].
428
429   For the purposes of HTTP, a representation is information that
430   reflects the current or desired state of a given resource, in a
431   format that can be readily communicated via the protocol, consisting
432   of a set of representation metadata and a potentially unbounded
433   stream of representation data.
434
4353.1.  Representation Metadata
436
437   Representation header fields provide metadata about the
438   representation.  When a message includes a payload body, the
439   representation header fields describe how to interpret the
440   representation data enclosed in the payload body.  In a response to a
441   HEAD request, the representation header fields describe the
442   representation data that would have been enclosed in the payload body
443   if the same request had been a GET.
444
445
446
447Fielding & Reschke        Expires April 7, 2013                 [Page 8]
448
449Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
450
451
452   The following header fields are defined to convey representation
453   metadata:
454
455   +-------------------+------------------------+
456   | Header Field Name | Defined in...          |
457   +-------------------+------------------------+
458   | Content-Type      | Section 3.1.1.5        |
459   | Content-Encoding  | Section 3.1.2.2        |
460   | Content-Language  | Section 3.1.3.2        |
461   | Content-Location  | Section 3.1.4.2        |
462   | Expires           | Section 7.3 of [Part6] |
463   +-------------------+------------------------+
464
4653.1.1.  Data Type
466
4673.1.1.1.  Media Types
468
469   HTTP uses Internet Media Types [RFC2046] in the Content-Type
470   (Section 3.1.1.5) and Accept (Section 6.3.2) header fields in order
471   to provide open and extensible data typing and type negotiation.
472
473     media-type = type "/" subtype *( OWS ";" OWS parameter )
474     type       = token
475     subtype    = token
476
477   The type/subtype MAY be followed by parameters in the form of
478   attribute/value pairs.
479
480     parameter      = attribute "=" value
481     attribute      = token
482     value          = word
483
484   The type, subtype, and parameter attribute names are case-
485   insensitive.  Parameter values might or might not be case-sensitive,
486   depending on the semantics of the parameter name.  The presence or
487   absence of a parameter might be significant to the processing of a
488   media-type, depending on its definition within the media type
489   registry.
490
491   A parameter value that matches the token production can be
492   transmitted as either a token or within a quoted-string.  The quoted
493   and unquoted values are equivalent.
494
495   Media-type values are registered with the Internet Assigned Number
496   Authority (IANA).  The media type registration process is outlined in
497   [RFC4288].  Use of non-registered media types is discouraged.
498
499
500
501
502
503Fielding & Reschke        Expires April 7, 2013                 [Page 9]
504
505Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
506
507
5083.1.1.2.  Character Encodings (charset)
509
510   HTTP uses charset names to indicate the character encoding of a
511   textual representation.
512
513   A character encoding is identified by a case-insensitive token.  The
514   complete set of tokens is defined by the IANA Character Set registry
515   (<http://www.iana.org/assignments/character-sets>).
516
517     charset = token
518
519   Although HTTP allows an arbitrary token to be used as a charset
520   value, any token that has a predefined value within the IANA
521   Character Set registry MUST represent the character encoding defined
522   by that registry.  Applications SHOULD limit their use of character
523   encodings to those defined within the IANA registry.
524
525   HTTP uses charset in two contexts: within an Accept-Charset request
526   header field (in which the charset value is an unquoted token) and as
527   the value of a parameter in a Content-Type header field (within a
528   request or response), in which case the parameter value of the
529   charset parameter can be quoted.
530
531   Implementers need to be aware of IETF character set requirements
532   [RFC3629] [RFC2277].
533
5343.1.1.3.  Canonicalization and Text Defaults
535
536   Internet media types are registered with a canonical form.  A
537   representation transferred via HTTP messages MUST be in the
538   appropriate canonical form prior to its transmission except for
539   "text" types, as defined in the next paragraph.
540
541   When in canonical form, media subtypes of the "text" type use CRLF as
542   the text line break.  HTTP relaxes this requirement and allows the
543   transport of text media with plain CR or LF alone representing a line
544   break when it is done consistently for an entire representation.
545   HTTP applications MUST accept CRLF, bare CR, and bare LF as
546   indicating a line break in text media received via HTTP.  In
547   addition, if the text is in a character encoding that does not use
548   octets 13 and 10 for CR and LF respectively, as is the case for some
549   multi-byte character encodings, HTTP allows the use of whatever octet
550   sequences are defined by that character encoding to represent the
551   equivalent of CR and LF for line breaks.  This flexibility regarding
552   line breaks applies only to text media in the payload body; a bare CR
553   or LF MUST NOT be substituted for CRLF within any of the HTTP control
554   structures (such as header fields and multipart boundaries).
555
556
557
558
559Fielding & Reschke        Expires April 7, 2013                [Page 10]
560
561Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
562
563
564   If a representation is encoded with a content-coding, the underlying
565   data MUST be in a form defined above prior to being encoded.
566
5673.1.1.4.  Multipart Types
568
569   MIME provides for a number of "multipart" types -- encapsulations of
570   one or more representations within a single message body.  All
571   multipart types share a common syntax, as defined in Section 5.1.1 of
572   [RFC2046], and include a boundary parameter as part of the media type
573   value.  The message body is itself a protocol element; a sender MUST
574   generate only CRLF to represent line breaks between body-parts.
575
576   In general, HTTP treats a multipart message body no differently than
577   any other media type: strictly as payload.  HTTP does not use the
578   multipart boundary as an indicator of message body length.  In all
579   other respects, an HTTP user agent SHOULD follow the same or similar
580   behavior as a MIME user agent would upon receipt of a multipart type.
581   The MIME header fields within each body-part of a multipart message
582   body do not have any significance to HTTP beyond that defined by
583   their MIME semantics.
584
585   A recipient MUST treat an unrecognized multipart subtype as being
586   equivalent to "multipart/mixed".
587
588      Note: The "multipart/form-data" type has been specifically defined
589      for carrying form data suitable for processing via the POST
590      request method, as described in [RFC2388].
591
5923.1.1.5.  Content-Type
593
594   The "Content-Type" header field indicates the media type of the
595   representation, which defines both the data format and how that data
596   SHOULD be processed by the recipient (within the scope of the request
597   method semantics) after any Content-Encoding is decoded.  For
598   responses to the HEAD method, the media type is that which would have
599   been sent had the request been a GET.
600
601     Content-Type = media-type
602
603   Media types are defined in Section 3.1.1.1.  An example of the field
604   is
605
606     Content-Type: text/html; charset=ISO-8859-4
607
608   A sender SHOULD include a Content-Type header field in a message
609   containing a payload body, defining the media type of the enclosed
610   representation, unless the intended media type is unknown to the
611   sender.  If a Content-Type header field is not present, recipients
612
613
614
615Fielding & Reschke        Expires April 7, 2013                [Page 11]
616
617Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
618
619
620   MAY either assume a media type of "application/octet-stream"
621   ([RFC2046], Section 4.5.1) or examine the representation data to
622   determine its type.
623
624   In practice, resource owners do not always properly configure their
625   origin server to provide the correct Content-Type for a given
626   representation, with the result that some clients will examine a
627   payload's content and override the specified type.  Clients that do
628   so risk drawing incorrect conclusions, which might expose additional
629   security risks (e.g., "privilege escalation").  Furthermore, it is
630   impossible to determine the sender's intent by examining the data
631   format: many data formats match multiple media types that differ only
632   in processing semantics.  Implementers are encouraged to provide a
633   means of disabling such "content sniffing" when it is used.
634
6353.1.2.  Data Encoding
636
6373.1.2.1.  Content Codings
638
639   Content coding values indicate an encoding transformation that has
640   been or can be applied to a representation.  Content codings are
641   primarily used to allow a representation to be compressed or
642   otherwise usefully transformed without losing the identity of its
643   underlying media type and without loss of information.  Frequently,
644   the representation is stored in coded form, transmitted directly, and
645   only decoded by the recipient.
646
647     content-coding   = token
648
649   All content-coding values are case-insensitive and SHOULD be
650   registered within the HTTP Content Coding registry, as defined in
651   Section 9.4.  They are used in the Accept-Encoding (Section 6.3.4)
652   and Content-Encoding (Section 3.1.2.2) header fields.
653
654   The following content-coding values are defined by this
655   specification:
656
657      compress (and x-compress): See Section 4.2.1 of [Part1].
658
659      deflate: See Section 4.2.2 of [Part1].
660
661      gzip (and x-gzip): See Section 4.2.3 of [Part1].
662
6633.1.2.2.  Content-Encoding
664
665   The "Content-Encoding" header field indicates what content codings
666   have been applied to the representation, beyond those inherent in the
667   media type, and thus what decoding mechanisms have to be applied in
668
669
670
671Fielding & Reschke        Expires April 7, 2013                [Page 12]
672
673Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
674
675
676   order to obtain data in the media type referenced by the Content-Type
677   header field.  Content-Encoding is primarily used to allow a
678   representation's data to be compressed without losing the identity of
679   its underlying media type.
680
681     Content-Encoding = 1#content-coding
682
683   An example of its use is
684
685     Content-Encoding: gzip
686
687   If multiple encodings have been applied to a representation, the
688   content codings MUST be listed in the order in which they were
689   applied.  Additional information about the encoding parameters MAY be
690   provided by other header fields not defined by this specification.
691
692   Unlike Transfer-Encoding (Section 3.3.1 of [Part1]), the codings
693   listed in Content-Encoding are a characteristic of the
694   representation; the representation is defined in terms of the coded
695   form, and all other metadata about the representation is about the
696   coded form unless otherwise noted in the metadata definition.
697   Typically, the representation is only decoded just prior to rendering
698   or analogous usage.
699
700   A transforming proxy MAY modify the content coding if the new coding
701   is known to be acceptable to the recipient, unless the "no-transform"
702   cache-control directive is present in the message.
703
704   If the media type includes an inherent encoding, such as a data
705   format that is always compressed, then that encoding would not be
706   restated as a Content-Encoding even if it happens to be the same
707   algorithm as one of the content codings.  Such a content coding would
708   only be listed if, for some bizarre reason, it is applied a second
709   time to form the representation.  Likewise, an origin server might
710   choose to publish the same payload data as multiple representations
711   that differ only in whether the coding is defined as part of Content-
712   Type or Content-Encoding, since some user agents will behave
713   differently in their handling of each response (e.g., open a "Save as
714   ..." dialog instead of automatic decompression and rendering of
715   content).
716
717   If the content-coding of a representation in a request message is not
718   acceptable to the origin server, the server SHOULD respond with a
719   status code of 415 (Unsupported Media Type).
720
721
722
723
724
725
726
727Fielding & Reschke        Expires April 7, 2013                [Page 13]
728
729Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
730
731
7323.1.3.  Audience Language
733
7343.1.3.1.  Language Tags
735
736   A language tag, as defined in [RFC5646], identifies a natural
737   language spoken, written, or otherwise conveyed by human beings for
738   communication of information to other human beings.  Computer
739   languages are explicitly excluded.  HTTP uses language tags within
740   the Accept-Language and Content-Language fields.
741
742   In summary, a language tag is composed of one or more parts: A
743   primary language subtag followed by a possibly empty series of
744   subtags:
745
746     language-tag = <Language-Tag, defined in [RFC5646], Section 2.1>
747
748   White space is not allowed within the tag and all tags are case-
749   insensitive.  The name space of language subtags is administered by
750   the IANA (see
751   <http://www.iana.org/assignments/language-subtag-registry>).
752
753   Example tags include:
754
755     en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN
756
757   See [RFC5646] for further information.
758
7593.1.3.2.  Content-Language
760
761   The "Content-Language" header field describes the natural language(s)
762   of the intended audience for the representation.  Note that this
763   might not be equivalent to all the languages used within the
764   representation.
765
766     Content-Language = 1#language-tag
767
768   Language tags are defined in Section 3.1.3.1.  The primary purpose of
769   Content-Language is to allow a user to identify and differentiate
770   representations according to the user's own preferred language.
771   Thus, if the content is intended only for a Danish-literate audience,
772   the appropriate field is
773
774     Content-Language: da
775
776   If no Content-Language is specified, the default is that the content
777   is intended for all language audiences.  This might mean that the
778   sender does not consider it to be specific to any natural language,
779   or that the sender does not know for which language it is intended.
780
781
782
783Fielding & Reschke        Expires April 7, 2013                [Page 14]
784
785Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
786
787
788   Multiple languages MAY be listed for content that is intended for
789   multiple audiences.  For example, a rendition of the "Treaty of
790   Waitangi", presented simultaneously in the original Maori and English
791   versions, would call for
792
793     Content-Language: mi, en
794
795   However, just because multiple languages are present within a
796   representation does not mean that it is intended for multiple
797   linguistic audiences.  An example would be a beginner's language
798   primer, such as "A First Lesson in Latin", which is clearly intended
799   to be used by an English-literate audience.  In this case, the
800   Content-Language would properly only include "en".
801
802   Content-Language MAY be applied to any media type -- it is not
803   limited to textual documents.
804
8053.1.4.  Identification
806
8073.1.4.1.  Identifying a Representation
808
809   When a complete or partial representation is transferred in a message
810   payload, it is often desirable for the sender to supply, or the
811   recipient to determine, an identifier for a resource corresponding to
812   that representation.
813
814   The following rules are used to determine such a URI for the payload
815   of a request message:
816
817   o  If the request has a Content-Location header field, then the
818      sender asserts that the payload is a representation of the
819      resource identified by the Content-Location field-value.  However,
820      such an assertion cannot be trusted unless it can be verified by
821      other means (not defined by HTTP).  The information might still be
822      useful for revision history links.
823
824   o  Otherwise, the payload is unidentified.
825
826   The following rules, to be applied in order until a match is found,
827   are used to determine such a URI for the payload of a response
828   message:
829
830   1.  If the request is GET or HEAD and the response status code is 200
831       (OK), 204 (No Content), 206 (Partial Content), or 304 (Not
832       Modified), the payload's identifier is the effective request URI
833       (Section 5.5 of [Part1]).
834
835
836
837
838
839Fielding & Reschke        Expires April 7, 2013                [Page 15]
840
841Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
842
843
844   2.  If the request is GET or HEAD and the response status code is 203
845       (Non-Authoritative Information), the payload is a potentially
846       modified representation of the target resource; as such, the
847       effective request URI might only act as an identifier for the
848       payload's representation when a request is made via the same
849       chain of intermediaries.
850
851   3.  If the response has a Content-Location header field and its
852       field-value is a reference to the same URI as the effective
853       request URI, the payload's identifier is the effective request
854       URI.
855
856   4.  If the response has a Content-Location header field and its
857       field-value is a reference to a URI different from the effective
858       request URI, then the sender asserts that the payload is a
859       representation of the resource identified by the Content-Location
860       field-value.  However, such an assertion cannot be trusted unless
861       it can be verified by other means (not defined by HTTP).
862
863   5.  Otherwise, the payload is unidentified.
864
8653.1.4.2.  Content-Location
866
867   The "Content-Location" header field references a URI that can be used
868   as a specific identifier for the representation in this message
869   payload.  In other words, if one were to perform a GET on this URI at
870   the time of this message's generation, then a 200 (OK) response would
871   contain the same representation that is enclosed as payload in this
872   message.
873
874     Content-Location = absolute-URI / partial-URI
875
876   The Content-Location value is not a replacement for the effective
877   Request URI (Section 5.5 of [Part1]).  It is representation metadata.
878   It has the same syntax and semantics as the header field of the same
879   name defined for MIME body parts in Section 4 of [RFC2557].  However,
880   its appearance in an HTTP message has some special implications for
881   HTTP recipients.
882
883   If Content-Location is included in a 2xx (Successful) response
884   message and its value refers (after conversion to absolute form) to a
885   URI that is the same as the effective request URI, then the response
886   payload SHOULD be considered a current representation of that
887   resource.  For a GET or HEAD request, this is the same as the default
888   semantics when no Content-Location is provided by the server.  For a
889   state-changing request like PUT or POST, it implies that the server's
890   response contains the new representation of that resource, thereby
891   distinguishing it from representations that might only report about
892
893
894
895Fielding & Reschke        Expires April 7, 2013                [Page 16]
896
897Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
898
899
900   the action (e.g., "It worked!").  This allows authoring applications
901   to update their local copies without the need for a subsequent GET
902   request.
903
904   If Content-Location is included in a 2xx (Successful) response
905   message and its field-value refers to a URI that differs from the
906   effective request URI, then the origin server claims that the field-
907   value is an identifier for the payload's representation.  Such a
908   claim can only be trusted if both identifiers share the same resource
909   owner, which cannot be programmatically determined via HTTP.
910
911   o  For a response to a GET or HEAD request, this is an indication
912      that the effective request URI identifies a resource that is
913      subject to content negotiation and the Content-Location field-
914      value is a more specific identifier for the selected
915      representation.
916
917   o  For a 201 (Created) response to a state-changing method, a
918      Content-Location field-value that is identical to the Location
919      field-value indicates that this payload is a current
920      representation of the newly created resource.
921
922   o  Otherwise, such a Content-Location indicates that this payload is
923      a representation reporting on the requested action's status and
924      that the same report is available (for future access with GET) at
925      the given URI.  For example, a purchase transaction made via a
926      POST request might include a receipt document as the payload of
927      the 200 (OK) response; the Content-Location field-value provides
928      an identifier for retrieving a copy of that same receipt in the
929      future.
930
931   If Content-Location is included in a request message, then it MAY be
932   interpreted by the origin server as an indication of where the user
933   agent originally obtained the content of the enclosed representation
934   (prior to any subsequent modification of the content by that user
935   agent).  In other words, the user agent is providing the same
936   representation metadata that it received with the original
937   representation.  However, such interpretation MUST NOT be used to
938   alter the semantics of the method requested by the client.  For
939   example, if a client makes a PUT request on a negotiated resource and
940   the origin server accepts that PUT (without redirection), then the
941   new set of values for that resource is expected to be consistent with
942   the one representation supplied in that PUT; the Content-Location
943   cannot be used as a form of reverse content selection that identifies
944   only one of the negotiated representations to be updated.  If the
945   user agent had wanted the latter semantics, it would have applied the
946   PUT directly to the Content-Location URI.
947
948
949
950
951Fielding & Reschke        Expires April 7, 2013                [Page 17]
952
953Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
954
955
956   A Content-Location field received in a request message is transitory
957   information that SHOULD NOT be saved with other representation
958   metadata for use in later responses.  The Content-Location's value
959   might be saved for use in other contexts, such as within source links
960   or other metadata.
961
962   A cache cannot assume that a representation with a Content-Location
963   different from the URI used to retrieve it can be used to respond to
964   later requests on that Content-Location URI.
965
9663.2.  Representation Data
967
968   The representation data associated with an HTTP message is either
969   provided as the payload body of the message or referred to by the
970   message semantics and the effective request URI.  The representation
971   data is in a format and encoding defined by the representation
972   metadata header fields.
973
974   The data type of the representation data is determined via the header
975   fields Content-Type and Content-Encoding.  These define a two-layer,
976   ordered encoding model:
977
978     representation-data := Content-Encoding( Content-Type( bits ) )
979
9803.3.  Payload Semantics
981
982   Some HTTP messages transfer a complete or partial representation as
983   the message "payload".  In some cases, a payload might only contain
984   the associated representation's header fields (e.g., responses to
985   HEAD) or only some part(s) of the representation data (e.g., the 206
986   (Partial Content) status code).
987
988   The purpose of a payload in a request is defined by the method
989   semantics.  In a response, the payload's purpose is defined by both
990   the request method and the response status code.
991
992   For example, a representation in the payload of a PUT request
993   (Section 5.3.4) represents the desired state of the target resource
994   if the request is successfully applied, whereas a representation in
995   the payload of a POST request (Section 5.3.3) represents an anonymous
996   resource for providing data to be processed, such as the information
997   that a user entered within an HTML form.
998
999   Likewise, the payload of a 200 (OK) response to GET (Section 5.3.1)
1000   contains a representation of the target resource, as observed at the
1001   time of the message origination date (Section 8.1.1.2), whereas the
1002   same status code in a response to POST might contain either a
1003   representation of the processing result or a current representation
1004
1005
1006
1007Fielding & Reschke        Expires April 7, 2013                [Page 18]
1008
1009Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
1010
1011
1012   of the target resource after applying the processing.  Response
1013   messages with an error status code usually contain a representation
1014   that describes the error and what next steps are suggested for
1015   resolving it.
1016
1017   Header fields that specifically describe the payload, rather than the
1018   associated representation, are referred to as "payload header
1019   fields".  Payload header fields are defined in other parts of this
1020   specification, due to their impact on message parsing.
1021
1022   +-------------------+--------------------------+
1023   | Header Field Name | Defined in...            |
1024   +-------------------+--------------------------+
1025   | Content-Length    | Section 3.3.2 of [Part1] |
1026   | Content-Range     | Section 5.2 of [Part5]   |
1027   | Transfer-Encoding | Section 3.3.1 of [Part1] |
1028   +-------------------+--------------------------+
1029
10303.4.  Content Negotiation
1031
1032   HTTP responses include a representation which contains information
1033   for interpretation, whether by a human user or for further
1034   processing.  Often, the server has different ways of representing the
1035   same information; for example, in different formats, languages, or
1036   using different character encodings.
1037
1038   HTTP clients and their users might have different or variable
1039   capabilities, characteristics or preferences which would influence
1040   which representation, among those available from the server, would be
1041   best for the server to deliver.  For this reason, HTTP provides
1042   mechanisms for "content negotiation" -- a process of allowing
1043   selection of a representation of a given resource, when more than one
1044   is available.
1045
1046   This specification defines two patterns of content negotiation;
1047   "proactive", where the server selects the representation based upon
1048   the client's stated preferences, and "reactive" negotiation, where
1049   the server provides a list of representations for the client to
1050   choose from, based upon their metadata.  In addition, there are other
1051   patterns: some applications use an "active content" pattern, where
1052   the server returns active content which runs on the client and, based
1053   on client available parameters, selects additional resources to
1054   invoke.  "Transparent Content Negotiation" ([RFC2295]) has also been
1055   proposed.
1056
1057   These patterns are all widely used, and have trade-offs in
1058   applicability and practicality.  In particular, when the number of
1059   preferences or capabilities to be expressed by a client are large
1060
1061
1062
1063Fielding & Reschke        Expires April 7, 2013                [Page 19]
1064
1065Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
1066
1067
1068   (such as when many different formats are supported by a user-agent),
1069   proactive negotiation becomes unwieldy, and might not be appropriate.
1070   Conversely, when the number of representations to choose from is very
1071   large, reactive negotiation might not be appropriate.
1072
1073   Note that, in all cases, the supplier of representations has the
1074   responsibility for determining which representations might be
1075   considered to be the "same information".
1076
10773.4.1.  Proactive Negotiation
1078
1079   If the selection of the best representation for a response is made by
1080   an algorithm located at the server, it is called proactive
1081   negotiation.  Selection is based on the available representations of
1082   the response (the dimensions over which it can vary; e.g., language,
1083   content-coding, etc.) and the contents of particular header fields in
1084   the request message or on other information pertaining to the request
1085   (such as the network address of the client).
1086
1087   Proactive negotiation is advantageous when the algorithm for
1088   selecting from among the available representations is difficult to
1089   describe to the user agent, or when the server desires to send its
1090   "best guess" to the client along with the first response (hoping to
1091   avoid the round-trip delay of a subsequent request if the "best
1092   guess" is good enough for the user).  In order to improve the
1093   server's guess, the user agent MAY include request header fields
1094   (Accept, Accept-Language, Accept-Encoding, etc.) which describe its
1095   preferences for such a response.
1096
1097   Proactive negotiation has disadvantages:
1098
1099   1.  It is impossible for the server to accurately determine what
1100       might be "best" for any given user, since that would require
1101       complete knowledge of both the capabilities of the user agent and
1102       the intended use for the response (e.g., does the user want to
1103       view it on screen or print it on paper?).
1104
1105   2.  Having the user agent describe its capabilities in every request
1106       can be both very inefficient (given that only a small percentage
1107       of responses have multiple representations) and a potential
1108       violation of the user's privacy.
1109
1110   3.  It complicates the implementation of an origin server and the
1111       algorithms for generating responses to a request.
1112
1113   4.  It might limit a public cache's ability to use the same response
1114       for multiple user's requests.
1115
1116
1117
1118
1119Fielding & Reschke        Expires April 7, 2013                [Page 20]
1120
1121Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
1122
1123
1124   Proactive negotiation allows the user agent to specify its
1125   preferences, but it cannot expect responses to always honor them.
1126   For example, the origin server might not implement proactive
1127   negotiation, or it might decide that sending a response that doesn't
1128   conform to them is better than sending a 406 (Not Acceptable)
1129   response.
1130
1131   HTTP/1.1 includes the following header fields for enabling proactive
1132   negotiation through description of user agent capabilities and user
1133   preferences: Accept (Section 6.3.2), Accept-Charset (Section 6.3.3),
1134   Accept-Encoding (Section 6.3.4), Accept-Language (Section 6.3.5), and
1135   User-Agent (Section 6.5.3).  However, an origin server is not limited
1136   to these dimensions and MAY vary the response based on any aspect of
1137   the request, including aspects of the connection (e.g., IP address)
1138   or information within extension header fields not defined by this
1139   specification.
1140
1141      Note: In practice, User-Agent based negotiation is fragile,
1142      because new clients might not be recognized.
1143
1144   The Vary header field (Section 8.2.1) can be used to express the
1145   parameters the server uses to select a representation that is subject
1146   to proactive negotiation.
1147
11483.4.2.  Reactive Negotiation
1149
1150   With reactive negotiation, selection of the best representation for a
1151   response is performed by the user agent after receiving an initial
1152   response from the origin server.  Selection is based on a list of the
1153   available representations of the response included within the header
1154   fields or body of the initial response, with each representation
1155   identified by its own URI.  Selection from among the representations
1156   can be performed automatically (if the user agent is capable of doing
1157   so) or manually by the user selecting from a generated (possibly
1158   hypertext) menu.
1159
1160   Reactive negotiation is advantageous when the response would vary
1161   over commonly-used dimensions (such as type, language, or encoding),
1162   when the origin server is unable to determine a user agent's
1163   capabilities from examining the request, and generally when public
1164   caches are used to distribute server load and reduce network usage.
1165
1166   Reactive negotiation suffers from the disadvantage of needing a
1167   second request to obtain the best alternate representation.  This
1168   second request is only efficient when caching is used.  In addition,
1169   this specification does not define any mechanism for supporting
1170   automatic selection, though it also does not prevent any such
1171   mechanism from being developed as an extension and used within
1172
1173
1174
1175Fielding & Reschke        Expires April 7, 2013                [Page 21]
1176
1177Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
1178
1179
1180   HTTP/1.1.
1181
1182   This specification defines the 300 (Multiple Choices) and 406 (Not
1183   Acceptable) status codes for enabling reactive negotiation when the
1184   server is unwilling or unable to provide a varying response using
1185   proactive negotiation.
1186
11874.  Product Tokens
1188
1189   Product tokens are used to allow communicating applications to
1190   identify themselves by software name and version.  Most fields using
1191   product tokens also allow sub-products which form a significant part
1192   of the application to be listed, separated by whitespace.  By
1193   convention, the products are listed in order of their significance
1194   for identifying the application.
1195
1196     product         = token ["/" product-version]
1197     product-version = token
1198
1199   Examples:
1200
1201     User-Agent: CERN-LineMode/2.15 libwww/2.17b3
1202     Server: Apache/0.8.4
1203
1204   Product tokens SHOULD be short and to the point.  They MUST NOT be
1205   used for advertising or other non-essential information.  Although
1206   any token octet MAY appear in a product-version, this token SHOULD
1207   only be used for a version identifier (i.e., successive versions of
1208   the same product SHOULD only differ in the product-version portion of
1209   the product value).
1210
12115.  Request Methods
1212
12135.1.  Overview
1214
1215   The request method token is the primary source of request semantics;
1216   it indicates the purpose for which the client has made this request
1217   and what is expected by the client as a successful result.  The
1218   request semantics MAY be further specialized by the semantics of some
1219   header fields when present in a request (Section 6) if those
1220   additional semantics do not conflict with the method.
1221
1222     method = token
1223
1224   HTTP was originally designed to be usable as an interface to
1225   distributed object systems.  The request method was envisioned as
1226   applying semantics to a target resource in much the same way as
1227   invoking a defined method on an identified object would apply
1228
1229
1230
1231Fielding & Reschke        Expires April 7, 2013                [Page 22]
1232
1233Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
1234
1235
1236   semantics.  The method token is case-sensitive because it might be
1237   used as a gateway to object-based systems with case-sensitive method
1238   names.
1239
1240   Unlike distributed objects, the standardized request methods in HTTP
1241   are not resource-specific, since uniform interfaces provide for
1242   better visibility and reuse in network-based systems [REST].  Once
1243   defined, a standardized method MUST have the same semantics when
1244   applied to any resource, though each resource determines for itself
1245   whether those semantics are implemented or allowed.
1246
1247   This specification defines a number of standardized methods that are
1248   commonly used in HTTP, as outlined by the following table.  By
1249   convention, standardized methods are defined in all-uppercase ASCII
1250   letters.
1251
1252   +---------+-------------------------------------------------+-------+
1253   | Method  | Description                                     | Sec.  |
1254   +---------+-------------------------------------------------+-------+
1255   | GET     | Transfer a current representation of the target | 5.3.1 |
1256   |         | resource.                                       |       |
1257   | HEAD    | Same as GET, but do not include a message body  | 5.3.2 |
1258   |         | in the response.                                |       |
1259   | POST    | Perform resource-specific processing on the     | 5.3.3 |
1260   |         | request payload.                                |       |
1261   | PUT     | Replace all current representations of the      | 5.3.4 |
1262   |         | target resource with the request payload.       |       |
1263   | DELETE  | Remove all current representations of the       | 5.3.5 |
1264   |         | target resource.                                |       |
1265   | CONNECT | Establish a tunnel to the server identified by  | 5.3.6 |
1266   |         | the target resource.                            |       |
1267   | OPTIONS | Describe the communication options for the      | 5.3.7 |
1268   |         | target resource.                                |       |
1269   | TRACE   | Perform a message loop-back test along the path | 5.3.8 |
1270   |         | to the target resource.                         |       |
1271   +---------+-------------------------------------------------+-------+
1272
1273   The methods GET and HEAD MUST be supported by all general-purpose
1274   servers.  All other methods are OPTIONAL.  When implemented, a server
1275   MUST implement the above methods according to the semantics defined
1276   for them in Section 5.3.
1277
1278   Additional methods MAY be used in HTTP; many have already been
1279   standardized outside the scope of this specification and registered
1280   within the HTTP Method Registry maintained by IANA, as defined in
1281   Section 9.1.
1282
1283   The set of methods allowed by a target resource can be listed in an
1284
1285
1286
1287Fielding & Reschke        Expires April 7, 2013                [Page 23]
1288
1289Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
1290
1291
1292   Allow header field (Section 8.4.1).  However, the set of allowed
1293   methods can change dynamically.  When a request message is received
1294   that is unrecognized or not implemented by an origin server, the
1295   origin server SHOULD respond with the 501 (Not Implemented) status
1296   code.  When a request message is received that is known by an origin
1297   server but not allowed for the target resource, the origin server
1298   SHOULD respond with the 405 (Method Not Allowed) status code.
1299
13005.2.  Common Method Properties
1301
13025.2.1.  Safe Methods
1303
1304   Request methods are considered "safe" if their defined semantics are
1305   essentially read-only; i.e., the client does not request, and does
1306   not expect, any state change on the origin server as a result of
1307   applying a safe method to a target resource.  Likewise, reasonable
1308   use of a safe method is not expected to cause any harm, loss of
1309   property, or unusual burden on the origin server.
1310
1311   This definition of safe methods does not prevent an implementation
1312   from including behavior that is potentially harmful, not entirely
1313   read-only, or which causes side-effects while invoking a safe method.
1314   What is important, however, is that the client did not request that
1315   additional behavior and cannot be held accountable for it.  For
1316   example, most servers append request information to access log files
1317   at the completion of every response, regardless of the method, and
1318   that is considered safe even though the log storage might become full
1319   and crash the server.  Likewise, a safe request initiated by
1320   selecting an advertisement on the Web will often have the side-effect
1321   of charging an advertising account.
1322
1323   The GET, HEAD, OPTIONS, and TRACE request methods are defined to be
1324   safe.
1325
1326   The purpose of distinguishing between safe and unsafe methods is to
1327   allow automated retrieval processes (spiders) and cache performance
1328   optimization (pre-fetching) to work without fear of causing harm.  In
1329   addition, it allows a user agent to apply appropriate constraints on
1330   the automated use of unsafe methods when processing potentially
1331   untrusted content.
1332
1333   A user agent SHOULD distinguish between safe and unsafe methods when
1334   presenting potential actions to a user, such that the user can be
1335   made aware of an unsafe action before it is requested.
1336
1337   When a resource is constructed such that parameters within the
1338   effective request URI have the effect of selecting an action, it is
1339   the resource owner's responsibility to ensure that the action is
1340
1341
1342
1343Fielding & Reschke        Expires April 7, 2013                [Page 24]
1344
1345Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
1346
1347
1348   consistent with the request method semantics.  For example, it is
1349   common for Web-based content editing software to use actions within
1350   query parameters, such as "page?do=delete".  If the purpose of such a
1351   resource is to perform an unsafe action, then the resource MUST
1352   disable or disallow that action when it is accessed using a safe
1353   request method.  Failure to do so will result in unfortunate side-
1354   effects when automated processes perform a GET on every URI reference
1355   for the sake of link maintenance, pre-fetching, building a search
1356   index, etc.
1357
13585.2.2.  Idempotent Methods
1359
1360   Request methods are considered "idempotent" if the intended effect of
1361   multiple identical requests is the same as for a single request.
1362   PUT, DELETE, and all safe request methods are idempotent.
1363
1364   Like the definition of safe, the idempotent property only applies to
1365   what has been requested by the user; a server is free to log each
1366   request separately, retain a revision control history, or implement
1367   other non-idempotent side-effects for each idempotent request.
1368
1369   Idempotent methods are distinguished because the request can be
1370   repeated automatically if a communication failure occurs before the
1371   client is able to read the server's response.  For example, if a
1372   client sends a PUT request and the underlying connection is closed
1373   before any response is received, then it can establish a new
1374   connection and retry the idempotent request because it knows that
1375   repeating the request will have the same effect even if the original
1376   request succeeded.  Note, however, that repeated failures would
1377   indicate a problem within the server.
1378
13795.2.3.  Cacheable Methods
1380
1381   Request methods are considered "cacheable" if it is possible and
1382   useful to answer a current client request with a stored response from
1383   a prior request.  GET and HEAD are defined to be cacheable.  In
1384   general, safe methods that do not depend on a current or
1385   authoritative response are cacheable, though the overwhelming
1386   majority of caches only support GET and HEAD.  HTTP requirements for
1387   cache behavior and cacheable responses are defined in [Part6].
1388
13895.3.  Method Definitions
1390
13915.3.1.  GET
1392
1393   The GET method requests transfer of a current representation of the
1394   target resource.
1395
1396
1397
1398
1399Fielding & Reschke        Expires April 7, 2013                [Page 25]
1400
1401Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
1402
1403
1404   If the target resource is a data-producing process, it is the
1405   produced data which shall be returned as the representation in the
1406   response and not the source text of the process, unless that text
1407   happens to be the output of the process.
1408
1409   The semantics of the GET method change to a "conditional GET" if the
1410   request message includes an If-Modified-Since, If-Unmodified-Since,
1411   If-Match, If-None-Match, or If-Range header field ([Part4]).  A
1412   conditional GET requests that the representation be transferred only
1413   under the circumstances described by the conditional header field(s).
1414   The conditional GET request is intended to reduce unnecessary network
1415   usage by allowing cached representations to be refreshed without
1416   requiring multiple requests or transferring data already held by the
1417   client.
1418
1419   The semantics of the GET method change to a "partial GET" if the
1420   request message includes a Range header field ([Part5]).  A partial
1421   GET requests that only part of the representation be transferred, as
1422   described in Section 5.4 of [Part5].  The partial GET request is
1423   intended to reduce unnecessary network usage by allowing partially-
1424   retrieved representations to be completed without transferring data
1425   already held by the client.
1426
1427   A payload within a GET request message has no defined semantics;
1428   sending a payload body on a GET request might cause some existing
1429   implementations to reject the request.
1430
1431   The response to a GET request is cacheable and MAY be used to satisfy
1432   subsequent GET and HEAD requests (see [Part6]).
1433
1434   See Section 10.2 for security considerations when used for forms.
1435
14365.3.2.  HEAD
1437
1438   The HEAD method is identical to GET except that the server MUST NOT
1439   return a message body in the response.  The metadata contained in the
1440   HTTP header fields in response to a HEAD request SHOULD be identical
1441   to the information sent in response to a GET request.  This method
1442   can be used for obtaining metadata about the representation implied
1443   by the request without transferring the representation data.  This
1444   method is often used for testing hypertext links for validity,
1445   accessibility, and recent modification.
1446
1447   The response to a HEAD request is cacheable and MAY be used to
1448   satisfy a subsequent HEAD request.  It also has potential side
1449   effects on previously stored responses to GET; see Section 5 of
1450   [Part6].
1451
1452
1453
1454
1455Fielding & Reschke        Expires April 7, 2013                [Page 26]
1456
1457Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
1458
1459
1460   A payload within a HEAD request message has no defined semantics;
1461   sending a payload body on a HEAD request might cause some existing
1462   implementations to reject the request.
1463
14645.3.3.  POST
1465
1466   The POST method requests that the origin server accept the
1467   representation enclosed in the request as data to be processed by the
1468   target resource.  POST is designed to allow a uniform method to cover
1469   the following functions:
1470
1471   o  Annotation of existing resources;
1472
1473   o  Posting a message to a bulletin board, newsgroup, mailing list, or
1474      similar group of articles;
1475
1476   o  Providing a block of data, such as the result of submitting a
1477      form, to a data-handling process;
1478
1479   o  Extending a database through an append operation.
1480
1481   The actual function performed by the POST method is determined by the
1482   server and is usually dependent on the effective request URI.
1483
1484   The action performed by the POST method might not result in a
1485   resource that can be identified by a URI.  In this case, either 200
1486   (OK) or 204 (No Content) is the appropriate response status code,
1487   depending on whether or not the response includes a representation
1488   that describes the result.
1489
1490   If a resource has been created on the origin server, the response
1491   SHOULD be 201 (Created) and contain a representation which describes
1492   the status of the request and refers to the new resource, and a
1493   Location header field (see Section 8.1.2).
1494
1495   Responses to POST requests are only cacheable when they include
1496   explicit freshness information (see Section 4.1.1 of [Part6]).  A
1497   cached POST response with a Content-Location header field (see
1498   Section 3.1.4.2) whose value is the effective Request URI MAY be used
1499   to satisfy subsequent GET and HEAD (not POST) requests.
1500
1501   Note that POST caching is not widely implemented.  However, the 303
1502   (See Other) response can be used to direct the user agent to retrieve
1503   a cacheable representation of the resource.
1504
1505
1506
1507
1508
1509
1510
1511Fielding & Reschke        Expires April 7, 2013                [Page 27]
1512
1513Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
1514
1515
15165.3.4.  PUT
1517
1518   The PUT method requests that the state of the target resource be
1519   created or replaced with the state defined by the representation
1520   enclosed in the request message payload.  A successful PUT of a given
1521   representation would suggest that a subsequent GET on that same
1522   target resource will result in an equivalent representation being
1523   returned in a 200 (OK) response.  However, there is no guarantee that
1524   such a state change will be observable, since the target resource
1525   might be acted upon by other user agents in parallel, or might be
1526   subject to dynamic processing by the origin server, before any
1527   subsequent GET is received.  A successful response only implies that
1528   the user agent's intent was achieved at the time of its processing by
1529   the origin server.
1530
1531   If the target resource does not have a current representation and the
1532   PUT successfully creates one, then the origin server MUST inform the
1533   user agent by sending a 201 (Created) response.  If the target
1534   resource does have a current representation and that representation
1535   is successfully modified in accordance with the state of the enclosed
1536   representation, then either a 200 (OK) or 204 (No Content) response
1537   SHOULD be sent to indicate successful completion of the request.
1538
1539   Unrecognized header fields SHOULD be ignored (i.e., not saved as part
1540   of the resource state).
1541
1542   An origin server SHOULD verify that the PUT representation is
1543   consistent with any constraints which the server has for the target
1544   resource that cannot or will not be changed by the PUT.  This is
1545   particularly important when the origin server uses internal
1546   configuration information related to the URI in order to set the
1547   values for representation metadata on GET responses.  When a PUT
1548   representation is inconsistent with the target resource, the origin
1549   server SHOULD either make them consistent, by transforming the
1550   representation or changing the resource configuration, or respond
1551   with an appropriate error message containing sufficient information
1552   to explain why the representation is unsuitable.  The 409 (Conflict)
1553   or 415 (Unsupported Media Type) status codes are suggested, with the
1554   latter being specific to constraints on Content-Type values.
1555
1556   For example, if the target resource is configured to always have a
1557   Content-Type of "text/html" and the representation being PUT has a
1558   Content-Type of "image/jpeg", then the origin server SHOULD do one
1559   of:
1560
1561   a.  reconfigure the target resource to reflect the new media type;
1562
1563
1564
1565
1566
1567Fielding & Reschke        Expires April 7, 2013                [Page 28]
1568
1569Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
1570
1571
1572   b.  transform the PUT representation to a format consistent with that
1573       of the resource before saving it as the new resource state; or,
1574
1575   c.  reject the request with a 415 (Unsupported Media Type) response
1576       indicating that the target resource is limited to "text/html",
1577       perhaps including a link to a different resource that would be a
1578       suitable target for the new representation.
1579
1580   HTTP does not define exactly how a PUT method affects the state of an
1581   origin server beyond what can be expressed by the intent of the user
1582   agent request and the semantics of the origin server response.  It
1583   does not define what a resource might be, in any sense of that word,
1584   beyond the interface provided via HTTP.  It does not define how
1585   resource state is "stored", nor how such storage might change as a
1586   result of a change in resource state, nor how the origin server
1587   translates resource state into representations.  Generally speaking,
1588   all implementation details behind the resource interface are
1589   intentionally hidden by the server.
1590
1591   The fundamental difference between the POST and PUT methods is
1592   highlighted by the different intent for the target resource.  The
1593   target resource in a POST request is intended to handle the enclosed
1594   representation as a data-accepting process, such as for a gateway to
1595   some other protocol or a document that accepts annotations.  In
1596   contrast, the target resource in a PUT request is intended to take
1597   the enclosed representation as a new or replacement value.  Hence,
1598   the intent of PUT is idempotent and visible to intermediaries, even
1599   though the exact effect is only known by the origin server.
1600
1601   Proper interpretation of a PUT request presumes that the user agent
1602   knows what target resource is desired.  A service that is intended to
1603   select a proper URI on behalf of the client, after receiving a state-
1604   changing request, SHOULD be implemented using the POST method rather
1605   than PUT.  If the origin server will not make the requested PUT state
1606   change to the target resource and instead wishes to have it applied
1607   to a different resource, such as when the resource has been moved to
1608   a different URI, then the origin server MUST send a 301 (Moved
1609   Permanently) response; the user agent MAY then make its own decision
1610   regarding whether or not to redirect the request.
1611
1612   A PUT request applied to the target resource MAY have side-effects on
1613   other resources.  For example, an article might have a URI for
1614   identifying "the current version" (a resource) which is separate from
1615   the URIs identifying each particular version (different resources
1616   that at one point shared the same state as the current version
1617   resource).  A successful PUT request on "the current version" URI
1618   might therefore create a new version resource in addition to changing
1619   the state of the target resource, and might also cause links to be
1620
1621
1622
1623Fielding & Reschke        Expires April 7, 2013                [Page 29]
1624
1625Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
1626
1627
1628   added between the related resources.
1629
1630   An origin server SHOULD reject any PUT request that contains a
1631   Content-Range header field (Section 5.2 of [Part5]), since it might
1632   be misinterpreted as partial content (or might be partial content
1633   that is being mistakenly PUT as a full representation).  Partial
1634   content updates are possible by targeting a separately identified
1635   resource with state that overlaps a portion of the larger resource,
1636   or by using a different method that has been specifically defined for
1637   partial updates (for example, the PATCH method defined in [RFC5789]).
1638
1639   Responses to the PUT method are not cacheable.  If a PUT request
1640   passes through a cache that has one or more stored responses for the
1641   effective request URI, those stored responses will be invalidated
1642   (see Section 6 of [Part6]).
1643
16445.3.5.  DELETE
1645
1646   The DELETE method requests that the origin server delete the target
1647   resource.  This method MAY be overridden by human intervention (or
1648   other means) on the origin server.  The client cannot be guaranteed
1649   that the operation has been carried out, even if the status code
1650   returned from the origin server indicates that the action has been
1651   completed successfully.  However, the server SHOULD NOT indicate
1652   success unless, at the time the response is given, it intends to
1653   delete the resource or move it to an inaccessible location.
1654
1655   A successful response SHOULD be 200 (OK) if the response includes a
1656   representation describing the status, 202 (Accepted) if the action
1657   has not yet been enacted, or 204 (No Content) if the action has been
1658   enacted but the response does not include a representation.
1659
1660   A payload within a DELETE request message has no defined semantics;
1661   sending a payload body on a DELETE request might cause some existing
1662   implementations to reject the request.
1663
1664   Responses to the DELETE method are not cacheable.  If a DELETE
1665   request passes through a cache that has one or more stored responses
1666   for the effective request URI, those stored responses will be
1667   invalidated (see Section 6 of [Part6]).
1668
16695.3.6.  CONNECT
1670
1671   The CONNECT method requests that the proxy establish a tunnel to the
1672   request-target and, if successful, thereafter restrict its behavior
1673   to blind forwarding of packets until the connection is closed.
1674
1675   When using CONNECT, the request-target MUST use the authority form
1676
1677
1678
1679Fielding & Reschke        Expires April 7, 2013                [Page 30]
1680
1681Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
1682
1683
1684   (Section 5.3 of [Part1]); i.e., the request-target consists of only
1685   the host name and port number of the tunnel destination, separated by
1686   a colon.  For example,
1687
1688     CONNECT server.example.com:80 HTTP/1.1
1689     Host: server.example.com:80
1690
1691
1692   Any 2xx (Successful) response to a CONNECT request indicates that the
1693   proxy has established a connection to the requested host and port,
1694   and has switched to tunneling the current connection to that server
1695   connection.  The tunneled data from the server begins immediately
1696   after the blank line that concludes the successful response's header
1697   block.
1698
1699   A server SHOULD NOT send any Transfer-Encoding or Content-Length
1700   header fields in a successful response.  A client MUST ignore any
1701   Content-Length or Transfer-Encoding header fields received in a
1702   successful response.
1703
1704   Any response other than a successful response indicates that the
1705   tunnel has not yet been formed and that the connection remains
1706   governed by HTTP.
1707
1708   Proxy authentication might be used to establish the authority to
1709   create a tunnel:
1710
1711     CONNECT server.example.com:80 HTTP/1.1
1712     Host: server.example.com:80
1713     Proxy-Authorization: basic aGVsbG86d29ybGQ=
1714
1715
1716   A payload within a CONNECT request message has no defined semantics;
1717   sending a payload body on a CONNECT request might cause some existing
1718   implementations to reject the request.
1719
1720   Similar to a pipelined HTTP/1.1 request, data to be tunneled from
1721   client to server MAY be sent immediately after the request (before a
1722   response is received).  The usual caveats also apply: data can be
1723   discarded if the eventual response is negative, and the connection
1724   can be reset with no response if more than one TCP segment is
1725   outstanding.
1726
1727   It might be the case that the proxy itself can only reach the
1728   requested origin server through another proxy.  In this case, the
1729   first proxy SHOULD make a CONNECT request of that next proxy,
1730   requesting a tunnel to the authority.  A proxy MUST NOT respond with
1731   any 2xx status code unless it has either a direct or tunnel
1732
1733
1734
1735Fielding & Reschke        Expires April 7, 2013                [Page 31]
1736
1737Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
1738
1739
1740   connection established to the authority.
1741
1742   If at any point either one of the peers gets disconnected, any
1743   outstanding data that came from that peer will be passed to the other
1744   one, and after that also the other connection will be terminated by
1745   the proxy.  If there is outstanding data to that peer undelivered,
1746   that data will be discarded.
1747
1748   An origin server which receives a CONNECT request for itself MAY
1749   respond with a 2xx status code to indicate that a connection is
1750   established.  However, most origin servers do not implement CONNECT.
1751
17525.3.7.  OPTIONS
1753
1754   The OPTIONS method requests information about the communication
1755   options available on the request/response chain identified by the
1756   effective request URI.  This method allows a client to determine the
1757   options and/or requirements associated with a resource, or the
1758   capabilities of a server, without implying a resource action or
1759   initiating a resource retrieval.
1760
1761   Responses to the OPTIONS method are not cacheable.
1762
1763   If the OPTIONS request includes a payload, then the media type MUST
1764   be indicated by a Content-Type field.  Although this specification
1765   does not define any use for such a body, future extensions to HTTP
1766   might use the OPTIONS body to make more detailed queries on the
1767   server.
1768
1769   If the request-target (Section 5.3 of [Part1]) is an asterisk ("*"),
1770   the OPTIONS request is intended to apply to the server in general
1771   rather than to a specific resource.  Since a server's communication
1772   options typically depend on the resource, the "*" request is only
1773   useful as a "ping" or "no-op" type of method; it does nothing beyond
1774   allowing the client to test the capabilities of the server.  For
1775   example, this can be used to test a proxy for HTTP/1.1 conformance
1776   (or lack thereof).
1777
1778   If the request-target is not an asterisk, the OPTIONS request applies
1779   only to the options that are available when communicating with that
1780   resource.
1781
1782   A 200 (OK) response SHOULD include any header fields that indicate
1783   optional features implemented by the server and applicable to that
1784   resource (e.g., Allow), possibly including extensions not defined by
1785   this specification.  The response payload, if any, SHOULD also
1786   include information about the communication options.  The format for
1787   such a payload is not defined by this specification, but might be
1788
1789
1790
1791Fielding & Reschke        Expires April 7, 2013                [Page 32]
1792
1793Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
1794
1795
1796   defined by future extensions to HTTP.  Content negotiation MAY be
1797   used to select the appropriate representation.  If no payload body is
1798   included, the response MUST include a Content-Length field with a
1799   field-value of "0".
1800
1801   The Max-Forwards header field MAY be used to target a specific proxy
1802   in the request chain (see Section 6.1.1).  If no Max-Forwards field
1803   is present in the request, then the forwarded request MUST NOT
1804   include a Max-Forwards field.
1805
18065.3.8.  TRACE
1807
1808   The TRACE method requests a remote, application-level loop-back of
1809   the request message.  The final recipient of the request SHOULD
1810   reflect the message received back to the client as the message body
1811   of a 200 (OK) response.  The final recipient is either the origin
1812   server or the first proxy to receive a Max-Forwards value of zero (0)
1813   in the request (see Section 6.1.1).  A TRACE request MUST NOT include
1814   a message body.
1815
1816   TRACE allows the client to see what is being received at the other
1817   end of the request chain and use that data for testing or diagnostic
1818   information.  The value of the Via header field (Section 5.7 of
1819   [Part1]) is of particular interest, since it acts as a trace of the
1820   request chain.  Use of the Max-Forwards header field allows the
1821   client to limit the length of the request chain, which is useful for
1822   testing a chain of proxies forwarding messages in an infinite loop.
1823
1824   If the request is valid, the response SHOULD have a Content-Type of
1825   "message/http" (see Section 7.3.1 of [Part1]) and contain a message
1826   body that encloses a copy of the entire request message.  Responses
1827   to the TRACE method are not cacheable.
1828
18296.  Request Header Fields
1830
1831   A client sends request header fields to provide more information
1832   about the request context, make the request conditional based on the
1833   target resource state, suggest preferred formats for the response,
1834   supply authentication credentials, or modify the expected request
1835   processing.  These fields act as request modifiers, similar to the
1836   parameters on a programming language method invocation.
1837
18386.1.  Controls
1839
1840   Controls are request header fields that direct specific handling of
1841   the request.
1842
1843
1844
1845
1846
1847Fielding & Reschke        Expires April 7, 2013                [Page 33]
1848
1849Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
1850
1851
1852   +-------------------+------------------------+
1853   | Header Field Name | Defined in...          |
1854   +-------------------+------------------------+
1855   | Host              | Section 5.4 of [Part1] |
1856   | Max-Forwards      | Section 6.1.1          |
1857   | Expect            | Section 6.1.2          |
1858   | Range             | Section 5.4 of [Part5] |
1859   +-------------------+------------------------+
1860
18616.1.1.  Max-Forwards
1862
1863   The "Max-Forwards" header field provides a mechanism with the TRACE
1864   (Section 5.3.8) and OPTIONS (Section 5.3.7) methods to limit the
1865   number of times that the request is forwarded by proxies.  This can
1866   be useful when the client is attempting to trace a request which
1867   appears to be failing or looping mid-chain.
1868
1869     Max-Forwards = 1*DIGIT
1870
1871   The Max-Forwards value is a decimal integer indicating the remaining
1872   number of times this request message can be forwarded.
1873
1874   Each recipient of a TRACE or OPTIONS request containing a Max-
1875   Forwards header field MUST check and update its value prior to
1876   forwarding the request.  If the received value is zero (0), the
1877   recipient MUST NOT forward the request; instead, it MUST respond as
1878   the final recipient.  If the received Max-Forwards value is greater
1879   than zero, then the forwarded message MUST contain an updated Max-
1880   Forwards field with a value decremented by one (1).
1881
1882   The Max-Forwards header field MAY be ignored for all other request
1883   methods.
1884
18856.1.2.  Expect
1886
1887   The "Expect" header field is used to indicate that particular server
1888   behaviors are required by the client.
1889
1890     Expect       = 1#expectation
1891
1892     expectation  = expect-name [ BWS "=" BWS expect-value ]
1893                                *( OWS ";" [ OWS expect-param ] )
1894     expect-param = expect-name [ BWS "=" BWS expect-value ]
1895
1896     expect-name  = token
1897     expect-value = token / quoted-string
1898
1899   If all received Expect header field(s) are syntactically valid but
1900
1901
1902
1903Fielding & Reschke        Expires April 7, 2013                [Page 34]
1904
1905Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
1906
1907
1908   contain an expectation that the recipient does not understand or
1909   cannot comply with, the recipient MUST respond with a 417
1910   (Expectation Failed) status code.  A recipient of a syntactically
1911   invalid Expectation header field MUST respond with a 4xx status code
1912   other than 417.
1913
1914   The only expectation defined by this specification is:
1915
1916   100-continue
1917
1918      The "100-continue" expectation is defined below.  It does not
1919      support any expect-params.
1920
1921   Comparison is case-insensitive for names (expect-name), and case-
1922   sensitive for values (expect-value).
1923
1924   The Expect mechanism is hop-by-hop: the above requirements apply to
1925   any server, including proxies.  However, the Expect header field
1926   itself is end-to-end; it MUST be forwarded if the request is
1927   forwarded.
1928
1929   Many older HTTP/1.0 and HTTP/1.1 applications do not understand the
1930   Expect header field.
1931
19326.1.2.1.  Use of the 100 (Continue) Status
1933
1934   The purpose of the 100 (Continue) status code (Section 7.2.1) is to
1935   allow a client that is sending a request message with a payload to
1936   determine if the origin server is willing to accept the request
1937   (based on the request header fields) before the client sends the
1938   payload body.  In some cases, it might either be inappropriate or
1939   highly inefficient for the client to send the payload body if the
1940   server will reject the message without looking at the body.
1941
1942   Requirements for HTTP/1.1 clients:
1943
1944   o  If a client will wait for a 100 (Continue) response before sending
1945      the payload body, it MUST send an Expect header field with the
1946      "100-continue" expectation.
1947
1948   o  A client MUST NOT send an Expect header field with the "100-
1949      continue" expectation if it does not intend to send a payload
1950      body.
1951
1952   Because of the presence of older implementations, the protocol allows
1953   ambiguous situations in which a client might send "Expect: 100-
1954   continue" without receiving either a 417 (Expectation Failed) or a
1955   100 (Continue) status code.  Therefore, when a client sends this
1956
1957
1958
1959Fielding & Reschke        Expires April 7, 2013                [Page 35]
1960
1961Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
1962
1963
1964   header field to an origin server (possibly via a proxy) from which it
1965   has never seen a 100 (Continue) status code, the client SHOULD NOT
1966   wait for an indefinite period before sending the payload body.
1967
1968   Requirements for HTTP/1.1 origin servers:
1969
1970   o  Upon receiving a request which includes an Expect header field
1971      with the "100-continue" expectation, an origin server MUST either
1972      respond with 100 (Continue) status code and continue to read from
1973      the input stream, or respond with a final status code.  The origin
1974      server MUST NOT wait for the payload body before sending the 100
1975      (Continue) response.  If it responds with a final status code, it
1976      MAY close the transport connection or it MAY continue to read and
1977      discard the rest of the request.  It MUST NOT perform the request
1978      method if it returns a final status code.
1979
1980   o  An origin server SHOULD NOT send a 100 (Continue) response if the
1981      request message does not include an Expect header field with the
1982      "100-continue" expectation, and MUST NOT send a 100 (Continue)
1983      response if such a request comes from an HTTP/1.0 (or earlier)
1984      client.  There is an exception to this rule: for compatibility
1985      with [RFC2068], a server MAY send a 100 (Continue) status code in
1986      response to an HTTP/1.1 PUT or POST request that does not include
1987      an Expect header field with the "100-continue" expectation.  This
1988      exception, the purpose of which is to minimize any client
1989      processing delays associated with an undeclared wait for 100
1990      (Continue) status code, applies only to HTTP/1.1 requests, and not
1991      to requests with any other HTTP-version value.
1992
1993   o  An origin server MAY omit a 100 (Continue) response if it has
1994      already received some or all of the payload body for the
1995      corresponding request.
1996
1997   o  An origin server that sends a 100 (Continue) response MUST
1998      ultimately send a final status code, once the payload body is
1999      received and processed, unless it terminates the transport
2000      connection prematurely.
2001
2002   o  If an origin server receives a request that does not include an
2003      Expect header field with the "100-continue" expectation, the
2004      request includes a payload body, and the server responds with a
2005      final status code before reading the entire payload body from the
2006      transport connection, then the server SHOULD NOT close the
2007      transport connection until it has read the entire request, or
2008      until the client closes the connection.  Otherwise, the client
2009      might not reliably receive the response message.  However, this
2010      requirement ought not be construed as preventing a server from
2011      defending itself against denial-of-service attacks, or from badly
2012
2013
2014
2015Fielding & Reschke        Expires April 7, 2013                [Page 36]
2016
2017Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
2018
2019
2020      broken client implementations.
2021
2022   Requirements for HTTP/1.1 proxies:
2023
2024   o  If a proxy receives a request that includes an Expect header field
2025      with the "100-continue" expectation, and the proxy either knows
2026      that the next-hop server complies with HTTP/1.1 or higher, or does
2027      not know the HTTP version of the next-hop server, it MUST forward
2028      the request, including the Expect header field.
2029
2030   o  If the proxy knows that the version of the next-hop server is
2031      HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST
2032      respond with a 417 (Expectation Failed) status code.
2033
2034   o  Proxies SHOULD maintain a record of the HTTP version numbers
2035      received from recently-referenced next-hop servers.
2036
2037   o  A proxy MUST NOT forward a 100 (Continue) response if the request
2038      message was received from an HTTP/1.0 (or earlier) client and did
2039      not include an Expect header field with the "100-continue"
2040      expectation.  This requirement overrides the general rule for
2041      forwarding of 1xx responses (see Section 7.2.1).
2042
20436.2.  Conditionals
2044
2045   Conditionals are request header fields that indicate a precondition
2046   to be tested before applying the method semantics to the target
2047   resource.  Each precondition is based on metadata that is expected to
2048   change if the selected representation of the target resource is
2049   changed.  The HTTP/1.1 conditional request mechanisms are defined in
2050   [Part4].
2051
2052   +---------------------+------------------------+
2053   | Header Field Name   | Defined in...          |
2054   +---------------------+------------------------+
2055   | If-Match            | Section 3.1 of [Part4] |
2056   | If-None-Match       | Section 3.2 of [Part4] |
2057   | If-Modified-Since   | Section 3.3 of [Part4] |
2058   | If-Unmodified-Since | Section 3.4 of [Part4] |
2059   | If-Range            | Section 5.3 of [Part5] |
2060   +---------------------+------------------------+
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071Fielding & Reschke        Expires April 7, 2013                [Page 37]
2072
2073Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
2074
2075
20766.3.  Content Negotiation
2077
2078   +-------------------+---------------+
2079   | Header Field Name | Defined in... |
2080   +-------------------+---------------+
2081   | Accept            | Section 6.3.2 |
2082   | Accept-Charset    | Section 6.3.3 |
2083   | Accept-Encoding   | Section 6.3.4 |
2084   | Accept-Language   | Section 6.3.5 |
2085   +-------------------+---------------+
2086
20876.3.1.  Quality Values
2088
2089   Many of the request header fields for proactive content negotiation
2090   use a common parameter, named "q" (case-insensitive), to assign a
2091   relative "weight" to the preference for that associated kind of
2092   content.  This weight is referred to as a "quality value" (or
2093   "qvalue") because the same parameter name is often used within server
2094   configurations to assign a weight to the relative quality of the
2095   various representations that can be selected for a resource.
2096
2097   The weight is normalized to a real number in the range 0 through 1,
2098   where 0.001 is the least preferred and 1 is the most preferred; a
2099   value of 0 means "not acceptable".  If no "q" parameter is present,
2100   the default weight is 1.
2101
2102     weight = OWS ";" OWS "q=" qvalue
2103     qvalue = ( "0" [ "." 0*3DIGIT ] )
2104            / ( "1" [ "." 0*3("0") ] )
2105
2106   A sender of qvalue MUST NOT generate more than three digits after the
2107   decimal point.  User configuration of these values ought to be
2108   limited in the same fashion.
2109
21106.3.2.  Accept
2111
2112   The "Accept" header field can be used by user agents to specify
2113   response media types that are acceptable.  Accept header fields can
2114   be used to indicate that the request is specifically limited to a
2115   small set of desired types, as in the case of a request for an in-
2116   line image.
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127Fielding & Reschke        Expires April 7, 2013                [Page 38]
2128
2129Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
2130
2131
2132     Accept = #( media-range [ accept-params ] )
2133
2134     media-range    = ( "*/*"
2135                      / ( type "/" "*" )
2136                      / ( type "/" subtype )
2137                      ) *( OWS ";" OWS parameter )
2138     accept-params  = weight *( accept-ext )
2139     accept-ext     = OWS ";" OWS token [ "=" word ]
2140
2141   The asterisk "*" character is used to group media types into ranges,
2142   with "*/*" indicating all media types and "type/*" indicating all
2143   subtypes of that type.  The media-range MAY include media type
2144   parameters that are applicable to that range.
2145
2146   Each media-range MAY be followed by one or more accept-params,
2147   beginning with the "q" parameter for indicating a relative weight, as
2148   defined in Section 6.3.1.  The first "q" parameter (if any) separates
2149   the media-range parameter(s) from the accept-params.
2150
2151      Note: Use of the "q" parameter name to separate media type
2152      parameters from Accept extension parameters is due to historical
2153      practice.  Although this prevents any media type parameter named
2154      "q" from being used with a media range, such an event is believed
2155      to be unlikely given the lack of any "q" parameters in the IANA
2156      media type registry and the rare usage of any media type
2157      parameters in Accept.  Future media types are discouraged from
2158      registering any parameter named "q".
2159
2160   The example
2161
2162     Accept: audio/*; q=0.2, audio/basic
2163
2164   SHOULD be interpreted as "I prefer audio/basic, but send me any audio
2165   type if it is the best available after an 80% mark-down in quality".
2166
2167   A request without any Accept header field implies that the user agent
2168   will accept any media type in response.  If an Accept header field is
2169   present in a request and none of the available representations for
2170   the response have a media type that is listed as acceptable, the
2171   origin server MAY either honor the Accept header field by sending a
2172   406 (Not Acceptable) response or disregard the Accept header field by
2173   treating the response as if it is not subject to content negotiation.
2174
2175   A more elaborate example is
2176
2177     Accept: text/plain; q=0.5, text/html,
2178             text/x-dvi; q=0.8, text/x-c
2179
2180
2181
2182
2183Fielding & Reschke        Expires April 7, 2013                [Page 39]
2184
2185Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
2186
2187
2188   Verbally, this would be interpreted as "text/html and text/x-c are
2189   the preferred media types, but if they do not exist, then send the
2190   text/x-dvi representation, and if that does not exist, send the text/
2191   plain representation".
2192
2193   Media ranges can be overridden by more specific media ranges or
2194   specific media types.  If more than one media range applies to a
2195   given type, the most specific reference has precedence.  For example,
2196
2197     Accept: text/*, text/plain, text/plain;format=flowed, */*
2198
2199   have the following precedence:
2200
2201   1.  text/plain;format=flowed
2202
2203   2.  text/plain
2204
2205   3.  text/*
2206
2207   4.  */*
2208
2209   The media type quality factor associated with a given type is
2210   determined by finding the media range with the highest precedence
2211   which matches that type.  For example,
2212
2213     Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
2214             text/html;level=2;q=0.4, */*;q=0.5
2215
2216   would cause the following values to be associated:
2217
2218   +-------------------+---------------+
2219   | Media Type        | Quality Value |
2220   +-------------------+---------------+
2221   | text/html;level=1 | 1             |
2222   | text/html         | 0.7           |
2223   | text/plain        | 0.3           |
2224   | image/jpeg        | 0.5           |
2225   | text/html;level=2 | 0.4           |
2226   | text/html;level=3 | 0.7           |
2227   +-------------------+---------------+
2228
2229   Note: A user agent might be provided with a default set of quality
2230   values for certain media ranges.  However, unless the user agent is a
2231   closed system which cannot interact with other rendering agents, this
2232   default set ought to be configurable by the user.
2233
2234
2235
2236
2237
2238
2239Fielding & Reschke        Expires April 7, 2013                [Page 40]
2240
2241Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
2242
2243
22446.3.3.  Accept-Charset
2245
2246   The "Accept-Charset" header field can be used by user agents to
2247   indicate what character encodings are acceptable in a response
2248   payload.  This field allows clients capable of understanding more
2249   comprehensive or special-purpose character encodings to signal that
2250   capability to a server which is capable of representing documents in
2251   those character encodings.
2252
2253     Accept-Charset = 1#( ( charset / "*" ) [ weight ] )
2254
2255   Character encoding values (a.k.a., charsets) are described in
2256   Section 3.1.1.2.  Each charset MAY be given an associated quality
2257   value which represents the user's preference for that charset, as
2258   defined in Section 6.3.1.  An example is
2259
2260     Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
2261
2262   The special value "*", if present in the Accept-Charset field,
2263   matches every character encoding which is not mentioned elsewhere in
2264   the Accept-Charset field.  If no "*" is present in an Accept-Charset
2265   field, then any character encodings not explicitly mentioned in the
2266   field are considered "not acceptable" to the client.
2267
2268   A request without any Accept-Charset header field implies that the
2269   user agent will accept any character encoding in response.
2270
2271   If an Accept-Charset header field is present in a request and none of
2272   the available representations for the response have a character
2273   encoding that is listed as acceptable, the origin server MAY either
2274   honor the Accept-Charset header field by sending a 406 (Not
2275   Acceptable) response or disregard the Accept-Charset header field by
2276   treating the response as if it is not subject to content negotiation.
2277
22786.3.4.  Accept-Encoding
2279
2280   The "Accept-Encoding" header field can be used by user agents to
2281   indicate what response content-codings (Section 3.1.2.1) are
2282   acceptable in the response.  An "identity" token is used as a synonym
2283   for "no encoding" in order to communicate when no encoding is
2284   preferred.
2285
2286     Accept-Encoding  = #( codings [ weight ] )
2287     codings          = content-coding / "identity" / "*"
2288
2289   Each codings value MAY be given an associated quality value which
2290   represents the preference for that encoding, as defined in
2291   Section 6.3.1.
2292
2293
2294
2295Fielding & Reschke        Expires April 7, 2013                [Page 41]
2296
2297Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
2298
2299
2300   For example,
2301
2302     Accept-Encoding: compress, gzip
2303     Accept-Encoding:
2304     Accept-Encoding: *
2305     Accept-Encoding: compress;q=0.5, gzip;q=1.0
2306     Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
2307
2308   A server tests whether a content-coding for a given representation is
2309   acceptable, according to an Accept-Encoding field, using these rules:
2310
2311   1.  The special "*" symbol in an Accept-Encoding field matches any
2312       available content-coding not explicitly listed in the header
2313       field.
2314
2315   2.  If the representation has no content-coding, then it is
2316       acceptable by default unless specifically excluded by the Accept-
2317       Encoding field stating either "identity;q=0" or "*;q=0" without a
2318       more specific entry for "identity".
2319
2320   3.  If the representation's content-coding is one of the content-
2321       codings listed in the Accept-Encoding field, then it is
2322       acceptable unless it is accompanied by a qvalue of 0.  (As
2323       defined in Section 6.3.1, a qvalue of 0 means "not acceptable".)
2324
2325   4.  If multiple content-codings are acceptable, then the acceptable
2326       content-coding with the highest non-zero qvalue is preferred.
2327
2328   An Accept-Encoding header field with a combined field-value that is
2329   empty implies that the user agent does not want any content-coding in
2330   response.  If an Accept-Encoding header field is present in a request
2331   and none of the available representations for the response have a
2332   content-coding that is listed as acceptable, the origin server SHOULD
2333   send a response without any content-coding.
2334
2335   A request without an Accept-Encoding header field implies that the
2336   user agent will accept any content-coding in response.
2337
2338      Note: Most HTTP/1.0 applications do not recognize or obey qvalues
2339      associated with content-codings.  This means that qvalues will not
2340      work and are not permitted with x-gzip or x-compress.
2341
23426.3.5.  Accept-Language
2343
2344   The "Accept-Language" header field can be used by user agents to
2345   indicate the set of natural languages that are preferred in the
2346   response.  Language tags are defined in Section 3.1.3.1.
2347
2348
2349
2350
2351Fielding & Reschke        Expires April 7, 2013                [Page 42]
2352
2353Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
2354
2355
2356     Accept-Language = 1#( language-range [ weight ] )
2357     language-range  =
2358               <language-range, defined in [RFC4647], Section 2.1>
2359
2360   Each language-range can be given an associated quality value which
2361   represents an estimate of the user's preference for the languages
2362   specified by that range, as defined in Section 6.3.1.  For example,
2363
2364     Accept-Language: da, en-gb;q=0.8, en;q=0.7
2365
2366   would mean: "I prefer Danish, but will accept British English and
2367   other types of English". (see also Section 2.3 of [RFC4647])
2368
2369   For matching, Section 3 of [RFC4647] defines several matching
2370   schemes.  Implementations can offer the most appropriate matching
2371   scheme for their requirements.
2372
2373      Note: The "Basic Filtering" scheme ([RFC4647], Section 3.3.1) is
2374      identical to the matching scheme that was previously defined in
2375      Section 14.4 of [RFC2616].
2376
2377   It might be contrary to the privacy expectations of the user to send
2378   an Accept-Language header field with the complete linguistic
2379   preferences of the user in every request.  For a discussion of this
2380   issue, see Section 10.5.
2381
2382   As intelligibility is highly dependent on the individual user, it is
2383   recommended that client applications make the choice of linguistic
2384   preference available to the user.  If the choice is not made
2385   available, then the Accept-Language header field MUST NOT be given in
2386   the request.
2387
2388      Note: When making the choice of linguistic preference available to
2389      the user, we remind implementers of the fact that users are not
2390      familiar with the details of language matching as described above,
2391      and ought to be provided appropriate guidance.  As an example,
2392      users might assume that on selecting "en-gb", they will be served
2393      any kind of English document if British English is not available.
2394      A user agent might suggest in such a case to add "en" to get the
2395      best matching behavior.
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407Fielding & Reschke        Expires April 7, 2013                [Page 43]
2408
2409Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
2410
2411
24126.4.  Authentication Credentials
2413
2414   +---------------------+------------------------+
2415   | Header Field Name   | Defined in...          |
2416   +---------------------+------------------------+
2417   | Authorization       | Section 4.1 of [Part7] |
2418   | Proxy-Authorization | Section 4.3 of [Part7] |
2419   +---------------------+------------------------+
2420
24216.5.  Context
2422
2423   +-------------------+------------------------+
2424   | Header Field Name | Defined in...          |
2425   +-------------------+------------------------+
2426   | From              | Section 6.5.1          |
2427   | Referer           | Section 6.5.2          |
2428   | TE                | Section 4.3 of [Part1] |
2429   | User-Agent        | Section 6.5.3          |
2430   +-------------------+------------------------+
2431
24326.5.1.  From
2433
2434   The "From" header field, if given, SHOULD contain an Internet e-mail
2435   address for the human user who controls the requesting user agent.
2436   The address SHOULD be machine-usable, as defined by "mailbox" in
2437   Section 3.4 of [RFC5322]:
2438
2439     From    = mailbox
2440
2441     mailbox = <mailbox, defined in [RFC5322], Section 3.4>
2442
2443   An example is:
2444
2445     From: webmaster@example.org
2446
2447   This header field MAY be used for logging purposes and as a means for
2448   identifying the source of invalid or unwanted requests.  It SHOULD
2449   NOT be used as an insecure form of access protection.  The
2450   interpretation of this field is that the request is being performed
2451   on behalf of the person given, who accepts responsibility for the
2452   method performed.  In particular, robot agents SHOULD include this
2453   header field so that the person responsible for running the robot can
2454   be contacted if problems occur on the receiving end.
2455
2456   The Internet e-mail address in this field MAY be separate from the
2457   Internet host which issued the request.  For example, when a request
2458   is passed through a proxy the original issuer's address SHOULD be
2459   used.
2460
2461
2462
2463Fielding & Reschke        Expires April 7, 2013                [Page 44]
2464
2465Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
2466
2467
2468   The client SHOULD NOT send the From header field without the user's
2469   approval, as it might conflict with the user's privacy interests or
2470   their site's security policy.  It is strongly recommended that the
2471   user be able to disable, enable, and modify the value of this field
2472   at any time prior to a request.
2473
24746.5.2.  Referer
2475
2476   The "Referer" [sic] header field allows the client to specify the URI
2477   of the resource from which the target URI was obtained (the
2478   "referrer", although the header field is misspelled.).
2479
2480   The Referer header field allows servers to generate lists of back-
2481   links to resources for interest, logging, optimized caching, etc.  It
2482   also allows obsolete or mistyped links to be traced for maintenance.
2483   Some servers use Referer as a means of controlling where they allow
2484   links from (so-called "deep linking"), but legitimate requests do not
2485   always contain a Referer header field.
2486
2487   If the target URI was obtained from a source that does not have its
2488   own URI (e.g., input from the user keyboard), the Referer field MUST
2489   either be sent with the value "about:blank", or not be sent at all.
2490   Note that this requirement does not apply to sources with non-HTTP
2491   URIs (e.g., FTP).
2492
2493     Referer = absolute-URI / partial-URI
2494
2495   Example:
2496
2497     Referer: http://www.example.org/hypertext/Overview.html
2498
2499   If the field value is a relative URI, it SHOULD be interpreted
2500   relative to the effective request URI.  The URI MUST NOT include a
2501   fragment.  See Section 10.2 for security considerations.
2502
25036.5.3.  User-Agent
2504
2505   The "User-Agent" header field contains information about the user
2506   agent originating the request.  User agents SHOULD include this field
2507   with requests.
2508
2509   Typically, it is used for statistical purposes, the tracing of
2510   protocol violations, and tailoring responses to avoid particular user
2511   agent limitations.
2512
2513   The field can contain multiple product tokens (Section 4) and
2514   comments (Section 3.2 of [Part1]) identifying the agent and its
2515   significant subproducts.  By convention, the product tokens are
2516
2517
2518
2519Fielding & Reschke        Expires April 7, 2013                [Page 45]
2520
2521Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
2522
2523
2524   listed in order of their significance for identifying the
2525   application.
2526
2527   Because this field is usually sent on every request a user agent
2528   makes, implementations are encouraged not to include needlessly fine-
2529   grained detail, and to limit (or even prohibit) the addition of
2530   subproducts by third parties.  Overly long and detailed User-Agent
2531   field values make requests larger and can also be used to identify
2532   ("fingerprint") the user against their wishes.
2533
2534   Likewise, implementations are encouraged not to use the product
2535   tokens of other implementations in order to declare compatibility
2536   with them, as this circumvents the purpose of the field.  Finally,
2537   they are encouraged not to use comments to identify products; doing
2538   so makes the field value more difficult to parse.
2539
2540     User-Agent = product *( RWS ( product / comment ) )
2541
2542   Example:
2543
2544     User-Agent: CERN-LineMode/2.15 libwww/2.17b3
2545
25467.  Response Status Codes
2547
2548   The status-code element is a 3-digit integer result code of the
2549   attempt to understand and satisfy the request.
2550
2551   HTTP status codes are extensible.  HTTP applications are not required
2552   to understand the meaning of all registered status codes, though such
2553   understanding is obviously desirable.  However, applications MUST
2554   understand the class of any status code, as indicated by the first
2555   digit, and treat any unrecognized response as being equivalent to the
2556   x00 status code of that class, with the exception that an
2557   unrecognized response MUST NOT be cached.  For example, if an
2558   unrecognized status code of 431 is received by the client, it can
2559   safely assume that there was something wrong with its request and
2560   treat the response as if it had received a 400 status code.  In such
2561   cases, user agents SHOULD present to the user the representation
2562   enclosed with the response, since that representation is likely to
2563   include human-readable information which will explain the unusual
2564   status.
2565
2566   The first digit of the status-code defines the class of response.
2567   The last two digits do not have any categorization role.  There are 5
2568   values for the first digit:
2569
2570   o  1xx (Informational): Request received, continuing process
2571
2572
2573
2574
2575Fielding & Reschke        Expires April 7, 2013                [Page 46]
2576
2577Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
2578
2579
2580   o  2xx (Successful): The action was successfully received,
2581      understood, and accepted
2582
2583   o  3xx (Redirection): Further action needs to be taken in order to
2584      complete the request
2585
2586   o  4xx (Client Error): The request contains bad syntax or cannot be
2587      fulfilled
2588
2589   o  5xx (Server Error): The server failed to fulfill an apparently
2590      valid request
2591
2592   For most status codes the response can carry a payload, in which case
2593   a Content-Type header field indicates the payload's media type
2594   (Section 3.1.1.5).
2595
25967.1.  Overview of Status Codes
2597
2598   The status codes listed below are defined in this specification,
2599   Section 4 of [Part4], Section 3 of [Part5], and Section 3 of [Part7].
2600   The reason phrases listed here are only recommendations -- they can
2601   be replaced by local equivalents without affecting the protocol.
2602
2603
2604
2605
2606
2607
2608
2609
2610
2611
2612
2613
2614
2615
2616
2617
2618
2619
2620
2621
2622
2623
2624
2625
2626
2627
2628
2629
2630
2631Fielding & Reschke        Expires April 7, 2013                [Page 47]
2632
2633Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
2634
2635
2636   +-------------+------------------------------+----------------------+
2637   | status-code | reason-phrase                | Defined in...        |
2638   +-------------+------------------------------+----------------------+
2639   | 100         | Continue                     | Section 7.2.1        |
2640   | 101         | Switching Protocols          | Section 7.2.2        |
2641   | 200         | OK                           | Section 7.3.1        |
2642   | 201         | Created                      | Section 7.3.2        |
2643   | 202         | Accepted                     | Section 7.3.3        |
2644   | 203         | Non-Authoritative            | Section 7.3.4        |
2645   |             | Information                  |                      |
2646   | 204         | No Content                   | Section 7.3.5        |
2647   | 205         | Reset Content                | Section 7.3.6        |
2648   | 206         | Partial Content              | Section 3.1 of       |
2649   |             |                              | [Part5]              |
2650   | 300         | Multiple Choices             | Section 7.4.1        |
2651   | 301         | Moved Permanently            | Section 7.4.2        |
2652   | 302         | Found                        | Section 7.4.3        |
2653   | 303         | See Other                    | Section 7.4.4        |
2654   | 304         | Not Modified                 | Section 4.1 of       |
2655   |             |                              | [Part4]              |
2656   | 305         | Use Proxy                    | Section 7.4.5        |
2657   | 307         | Temporary Redirect           | Section 7.4.7        |
2658   | 400         | Bad Request                  | Section 7.5.1        |
2659   | 401         | Unauthorized                 | Section 3.1 of       |
2660   |             |                              | [Part7]              |
2661   | 402         | Payment Required             | Section 7.5.2        |
2662   | 403         | Forbidden                    | Section 7.5.3        |
2663   | 404         | Not Found                    | Section 7.5.4        |
2664   | 405         | Method Not Allowed           | Section 7.5.5        |
2665   | 406         | Not Acceptable               | Section 7.5.6        |
2666   | 407         | Proxy Authentication         | Section 3.2 of       |
2667   |             | Required                     | [Part7]              |
2668   | 408         | Request Time-out             | Section 7.5.7        |
2669   | 409         | Conflict                     | Section 7.5.8        |
2670   | 410         | Gone                         | Section 7.5.9        |
2671   | 411         | Length Required              | Section 7.5.10       |
2672   | 412         | Precondition Failed          | Section 4.2 of       |
2673   |             |                              | [Part4]              |
2674   | 413         | Request Representation Too   | Section 7.5.11       |
2675   |             | Large                        |                      |
2676   | 414         | URI Too Long                 | Section 7.5.12       |
2677   | 415         | Unsupported Media Type       | Section 7.5.13       |
2678   | 416         | Requested range not          | Section 3.2 of       |
2679   |             | satisfiable                  | [Part5]              |
2680   | 417         | Expectation Failed           | Section 7.5.14       |
2681   | 426         | Upgrade Required             | Section 7.5.15       |
2682   | 500         | Internal Server Error        | Section 7.6.1        |
2683   | 501         | Not Implemented              | Section 7.6.2        |
2684
2685
2686
2687Fielding & Reschke        Expires April 7, 2013                [Page 48]
2688
2689Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
2690
2691
2692   | 502         | Bad Gateway                  | Section 7.6.3        |
2693   | 503         | Service Unavailable          | Section 7.6.4        |
2694   | 504         | Gateway Time-out             | Section 7.6.5        |
2695   | 505         | HTTP Version not supported   | Section 7.6.6        |
2696   +-------------+------------------------------+----------------------+
2697
2698   Note that this list is not exhaustive -- it does not include
2699   extension status codes defined in other specifications.
2700
27017.2.  Informational 1xx
2702
2703   This class of status code indicates a provisional response,
2704   consisting only of the status-line and optional header fields, and is
2705   terminated by an empty line.  There are no required header fields for
2706   this class of status code.  Since HTTP/1.0 did not define any 1xx
2707   status codes, servers MUST NOT send a 1xx response to an HTTP/1.0
2708   client except under experimental conditions.
2709
2710   A client MUST be prepared to accept one or more 1xx status responses
2711   prior to a regular response, even if the client does not expect a 100
2712   (Continue) status message.  Unexpected 1xx status responses MAY be
2713   ignored by a user agent.
2714
2715   Proxies MUST forward 1xx responses, unless the connection between the
2716   proxy and its client has been closed, or unless the proxy itself
2717   requested the generation of the 1xx response.  (For example, if a
2718   proxy adds an "Expect: 100-continue" field when it forwards a
2719   request, then it need not forward the corresponding 100 (Continue)
2720   response(s).)
2721
27227.2.1.  100 Continue
2723
2724   The client SHOULD continue with its request.  This interim response
2725   is used to inform the client that the initial part of the request has
2726   been received and has not yet been rejected by the server.  The
2727   client SHOULD continue by sending the remainder of the request or, if
2728   the request has already been completed, ignore this response.  The
2729   server MUST send a final response after the request has been
2730   completed.  See Section 6.1.2.1 for detailed discussion of the use
2731   and handling of this status code.
2732
27337.2.2.  101 Switching Protocols
2734
2735   The server understands and is willing to comply with the client's
2736   request, via the Upgrade message header field (Section 6.3 of
2737   [Part1]), for a change in the application protocol being used on this
2738   connection.  The server will switch protocols to those defined by the
2739   response's Upgrade header field immediately after the empty line
2740
2741
2742
2743Fielding & Reschke        Expires April 7, 2013                [Page 49]
2744
2745Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
2746
2747
2748   which terminates the 101 response.
2749
2750   The protocol SHOULD be switched only when it is advantageous to do
2751   so.  For example, switching to a newer version of HTTP is
2752   advantageous over older versions, and switching to a real-time,
2753   synchronous protocol might be advantageous when delivering resources
2754   that use such features.
2755
27567.3.  Successful 2xx
2757
2758   This class of status code indicates that the client's request was
2759   successfully received, understood, and accepted.
2760
27617.3.1.  200 OK
2762
2763   The request has succeeded.  The payload returned with the response is
2764   dependent on the method used in the request, for example:
2765
2766   GET  a representation of the target resource is sent in the response;
2767
2768   HEAD  the same representation as GET, except without the message
2769      body;
2770
2771   POST  a representation describing or containing the result of the
2772      action;
2773
2774   TRACE  a representation containing the request message as received by
2775      the end server.
2776
2777   Caches MAY use a heuristic (see Section 4.1.2 of [Part6]) to
2778   determine freshness for 200 responses.
2779
27807.3.2.  201 Created
2781
2782   The request has been fulfilled and has resulted in one or more new
2783   resources being created.
2784
2785   Newly created resources are typically linked to from the response
2786   payload, with the most relevant URI also being carried in the
2787   Location header field.  If the newly created resource's URI is the
2788   same as the Effective Request URI, this information can be omitted
2789   (e.g., in the case of a response to a PUT request).
2790
2791   The origin server MUST create the resource(s) before returning the
2792   201 status code.  If the action cannot be carried out immediately,
2793   the server SHOULD respond with 202 (Accepted) response instead.
2794
2795   A 201 response MAY contain an ETag response header field indicating
2796
2797
2798
2799Fielding & Reschke        Expires April 7, 2013                [Page 50]
2800
2801Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
2802
2803
2804   the current value of the entity-tag for the representation of the
2805   resource identified by the Location header field or, in case the
2806   Location header field was omitted, by the Effective Request URI (see
2807   Section 2.3 of [Part4]).
2808
28097.3.3.  202 Accepted
2810
2811   The request has been accepted for processing, but the processing has
2812   not been completed.  The request might or might not eventually be
2813   acted upon, as it might be disallowed when processing actually takes
2814   place.  There is no facility for re-sending a status code from an
2815   asynchronous operation such as this.
2816
2817   The 202 response is intentionally non-committal.  Its purpose is to
2818   allow a server to accept a request for some other process (perhaps a
2819   batch-oriented process that is only run once per day) without
2820   requiring that the user agent's connection to the server persist
2821   until the process is completed.  The representation returned with
2822   this response SHOULD include an indication of the request's current
2823   status and either a pointer to a status monitor or some estimate of
2824   when the user can expect the request to be fulfilled.
2825
28267.3.4.  203 Non-Authoritative Information
2827
2828   The representation in the response has been transformed or otherwise
2829   modified by a transforming proxy (Section 2.3 of [Part1]).  Note that
2830   the behavior of transforming intermediaries is controlled by the no-
2831   transform Cache-Control directive (Section 7.2 of [Part6]).
2832
2833   This status code is only appropriate when the response status code
2834   would have been 200 (OK) otherwise.  When the status code before
2835   transformation would have been different, the 214 Transformation
2836   Applied warn-code (Section 7.5 of [Part6]) is appropriate.
2837
2838   Caches MAY use a heuristic (see Section 4.1.2 of [Part6]) to
2839   determine freshness for 203 responses.
2840
28417.3.5.  204 No Content
2842
2843   The 204 (No Content) status code indicates that the server has
2844   successfully fulfilled the request and that there is no additional
2845   content to return in the response payload body.  Metadata in the
2846   response header fields refer to the target resource and its current
2847   representation after the requested action.
2848
2849   For example, if a 204 status code is received in response to a PUT
2850   request and the response contains an ETag header field, then the PUT
2851   was successful and the ETag field-value contains the entity-tag for
2852
2853
2854
2855Fielding & Reschke        Expires April 7, 2013                [Page 51]
2856
2857Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
2858
2859
2860   the new representation of that target resource.
2861
2862   The 204 response allows a server to indicate that the action has been
2863   successfully applied to the target resource while implying that the
2864   user agent SHOULD NOT traverse away from its current "document view"
2865   (if any).  The server assumes that the user agent will provide some
2866   indication of the success to its user, in accord with its own
2867   interface, and apply any new or updated metadata in the response to
2868   the active representation.
2869
2870   For example, a 204 status code is commonly used with document editing
2871   interfaces corresponding to a "save" action, such that the document
2872   being saved remains available to the user for editing.  It is also
2873   frequently used with interfaces that expect automated data transfers
2874   to be prevalent, such as within distributed version control systems.
2875
2876   The 204 response MUST NOT include a message body, and thus is always
2877   terminated by the first empty line after the header fields.
2878
28797.3.6.  205 Reset Content
2880
2881   The server has fulfilled the request and the user agent SHOULD reset
2882   the document view which caused the request to be sent.  This response
2883   is primarily intended to allow input for actions to take place via
2884   user input, followed by a clearing of the form in which the input is
2885   given so that the user can easily initiate another input action.
2886
2887   The message body included with the response MUST be empty.  Note that
2888   receivers still need to parse the response according to the algorithm
2889   defined in Section 3.3 of [Part1].
2890
28917.4.  Redirection 3xx
2892
2893   This class of status code indicates that further action needs to be
2894   taken by the user agent in order to fulfill the request.  If the
2895   required action involves a subsequent HTTP request, it MAY be carried
2896   out by the user agent without interaction with the user if and only
2897   if the method used in the second request is known to be "safe", as
2898   defined in Section 5.2.1.
2899
2900   There are several types of redirects:
2901
2902   1.  Redirects of the request to another URI, either temporarily or
2903       permanently.  The new URI is specified in the Location header
2904       field.  In this specification, the status codes 301 (Moved
2905       Permanently), 302 (Found), and 307 (Temporary Redirect) fall
2906       under this category.
2907
2908
2909
2910
2911Fielding & Reschke        Expires April 7, 2013                [Page 52]
2912
2913Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
2914
2915
2916   2.  Redirection to a new location that represents an indirect
2917       response to the request, such as the result of a POST operation
2918       to be retrieved with a subsequent GET request.  This is status
2919       code 303 (See Other).
2920
2921   3.  Redirection offering a choice of matching resources for use by
2922       reactive content negotiation (Section 3.4.2).  This is status
2923       code 300 (Multiple Choices).
2924
2925   4.  Other kinds of redirection, such as to a cached result (status
2926       code 304 (Not Modified), see Section 4.1 of [Part4]).
2927
2928      Note: In HTTP/1.0, only the status codes 301 (Moved Permanently)
2929      and 302 (Found) were defined for the first type of redirect, and
2930      the second type did not exist at all ([RFC1945], Section 9.3).
2931      However it turned out that web forms using POST expected redirects
2932      to change the operation for the subsequent request to retrieval
2933      (GET).  To address this use case, HTTP/1.1 introduced the second
2934      type of redirect with the status code 303 (See Other) ([RFC2068],
2935      Section 10.3.4).  As user agents did not change their behavior to
2936      maintain backwards compatibility, the first revision of HTTP/1.1
2937      added yet another status code, 307 (Temporary Redirect), for which
2938      the backwards compatibility problems did not apply ([RFC2616],
2939      Section 10.3.8).  Over 10 years later, most user agents still do
2940      method rewriting for status codes 301 and 302, therefore this
2941      specification makes that behavior conformant in case the original
2942      request was POST.
2943
2944   A Location header field on a 3xx response indicates that a client MAY
2945   automatically redirect to the URI provided; see Section 8.1.2.
2946
2947   Note that for methods not known to be "safe", as defined in
2948   Section 5.2.1, automatic redirection needs to done with care, since
2949   the redirect might change the conditions under which the request was
2950   issued.
2951
2952   Clients SHOULD detect and intervene in cyclical redirections (i.e.,
2953   "infinite" redirection loops).
2954
2955      Note: An earlier version of this specification recommended a
2956      maximum of five redirections ([RFC2068], Section 10.3).  Content
2957      developers need to be aware that some clients might implement such
2958      a fixed limitation.
2959
2960
2961
2962
2963
2964
2965
2966
2967Fielding & Reschke        Expires April 7, 2013                [Page 53]
2968
2969Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
2970
2971
29727.4.1.  300 Multiple Choices
2973
2974   The target resource has more than one representation, each with its
2975   own specific location, and reactive negotiation information
2976   (Section 3.4) is being provided so that the user (or user agent) can
2977   select a preferred representation by redirecting its request to that
2978   location.
2979
2980   Unless it was a HEAD request, the response SHOULD include a
2981   representation containing a list of representation metadata and
2982   location(s) from which the user or user agent can choose the one most
2983   appropriate.  Depending upon the format and the capabilities of the
2984   user agent, selection of the most appropriate choice MAY be performed
2985   automatically.  However, this specification does not define any
2986   standard for such automatic selection.
2987
2988   If the server has a preferred choice of representation, it SHOULD
2989   include the specific URI for that representation in the Location
2990   field; user agents MAY use the Location field value for automatic
2991   redirection.
2992
2993   Caches MAY use a heuristic (see Section 4.1.2 of [Part6]) to
2994   determine freshness for 300 responses.
2995
29967.4.2.  301 Moved Permanently
2997
2998   The target resource has been assigned a new permanent URI and any
2999   future references to this resource SHOULD use one of the returned
3000   URIs.  Clients with link editing capabilities ought to automatically
3001   re-link references to the effective request URI to one or more of the
3002   new references returned by the server, where possible.
3003
3004   Caches MAY use a heuristic (see Section 4.1.2 of [Part6]) to
3005   determine freshness for 301 responses.
3006
3007   The new permanent URI SHOULD be given by the Location field in the
3008   response.  A response payload can contain a short hypertext note with
3009   a hyperlink to the new URI(s).
3010
3011      Note: For historic reasons, user agents MAY change the request
3012      method from POST to GET for the subsequent request.  If this
3013      behavior is undesired, status code 307 (Temporary Redirect) can be
3014      used instead.
3015
3016
3017
3018
3019
3020
3021
3022
3023Fielding & Reschke        Expires April 7, 2013                [Page 54]
3024
3025Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
3026
3027
30287.4.3.  302 Found
3029
3030   The target resource resides temporarily under a different URI.  Since
3031   the redirection might be altered on occasion, the client SHOULD
3032   continue to use the effective request URI for future requests.
3033
3034   The temporary URI SHOULD be given by the Location field in the
3035   response.  A response payload can contain a short hypertext note with
3036   a hyperlink to the new URI(s).
3037
3038      Note: For historic reasons, user agents MAY change the request
3039      method from POST to GET for the subsequent request.  If this
3040      behavior is undesired, status code 307 (Temporary Redirect) can be
3041      used instead.
3042
30437.4.4.  303 See Other
3044
3045   The 303 status code indicates that the server is redirecting the user
3046   agent to a different resource, as indicated by a URI in the Location
3047   header field, that is intended to provide an indirect response to the
3048   original request.  In order to satisfy the original request, a user
3049   agent SHOULD perform a retrieval request using the Location URI (a
3050   GET or HEAD request if using HTTP), which can itself be redirected
3051   further, and present the eventual result as an answer to the original
3052   request.  Note that the new URI in the Location header field is not
3053   considered equivalent to the effective request URI.
3054
3055   This status code is generally applicable to any HTTP method.  It is
3056   primarily used to allow the output of a POST action to redirect the
3057   user agent to a selected resource, since doing so provides the
3058   information corresponding to the POST response in a form that can be
3059   separately identified, bookmarked, and cached independent of the
3060   original request.
3061
3062   A 303 response to a GET request indicates that the requested resource
3063   does not have a representation of its own that can be transferred by
3064   the server over HTTP.  The Location URI indicates a resource that is
3065   descriptive of the target resource, such that the follow-on
3066   representation might be useful to recipients without implying that it
3067   adequately represents the target resource.  Note that answers to the
3068   questions of what can be represented, what representations are
3069   adequate, and what might be a useful description are outside the
3070   scope of HTTP and thus entirely determined by the URI owner(s).
3071
3072   Except for responses to a HEAD request, the representation of a 303
3073   response SHOULD contain a short hypertext note with a hyperlink to
3074   the Location URI.
3075
3076
3077
3078
3079Fielding & Reschke        Expires April 7, 2013                [Page 55]
3080
3081Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
3082
3083
30847.4.5.  305 Use Proxy
3085
3086   The 305 status code was defined in a previous version of this
3087   specification (see Appendix C), and is now deprecated.
3088
30897.4.6.  306 (Unused)
3090
3091   The 306 status code was used in a previous version of the
3092   specification, is no longer used, and the code is reserved.
3093
30947.4.7.  307 Temporary Redirect
3095
3096   The target resource resides temporarily under a different URI.  Since
3097   the redirection can change over time, the client SHOULD continue to
3098   use the effective request URI for future requests.
3099
3100   The temporary URI SHOULD be given by the Location field in the
3101   response.  A response payload can contain a short hypertext note with
3102   a hyperlink to the new URI(s).
3103
3104      Note: This status code is similar to 302 (Found), except that it
3105      does not allow rewriting the request method from POST to GET.
3106      This specification defines no equivalent counterpart for 301
3107      (Moved Permanently) ([status-308], however, defines the status
3108      code 308 (Permanent Redirect) for this purpose).
3109
31107.5.  Client Error 4xx
3111
3112   The 4xx class of status code is intended for cases in which the
3113   client seems to have erred.  Except when responding to a HEAD
3114   request, the server SHOULD include a representation containing an
3115   explanation of the error situation, and whether it is a temporary or
3116   permanent condition.  These status codes are applicable to any
3117   request method.  User agents SHOULD display any included
3118   representation to the user.
3119
31207.5.1.  400 Bad Request
3121
3122   The server cannot or will not process the request, due to a client
3123   error (e.g., malformed syntax).
3124
31257.5.2.  402 Payment Required
3126
3127   This code is reserved for future use.
3128
3129
3130
3131
3132
3133
3134
3135Fielding & Reschke        Expires April 7, 2013                [Page 56]
3136
3137Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
3138
3139
31407.5.3.  403 Forbidden
3141
3142   The server understood the request, but refuses to authorize it.
3143   Providing different user authentication credentials might be
3144   successful, but any credentials that were provided in the request are
3145   insufficient.  The request SHOULD NOT be repeated with the same
3146   credentials.
3147
3148   If the request method was not HEAD and the server wishes to make
3149   public why the request has not been fulfilled, it SHOULD describe the
3150   reason for the refusal in the representation.  If the server does not
3151   wish to make this information available to the client, the status
3152   code 404 (Not Found) MAY be used instead.
3153
31547.5.4.  404 Not Found
3155
3156   The server has not found anything matching the effective request URI.
3157   No indication is given of whether the condition is temporary or
3158   permanent.  The 410 (Gone) status code SHOULD be used if the server
3159   knows, through some internally configurable mechanism, that an old
3160   resource is permanently unavailable and has no forwarding address.
3161   This status code is commonly used when the server does not wish to
3162   reveal exactly why the request has been refused, or when no other
3163   response is applicable.
3164
31657.5.5.  405 Method Not Allowed
3166
3167   The method specified in the request-line is not allowed for the
3168   target resource.  The response MUST include an Allow header field
3169   containing a list of valid methods for the requested resource.
3170
31717.5.6.  406 Not Acceptable
3172
3173   The resource identified by the request is only capable of generating
3174   response representations which have content characteristics not
3175   acceptable according to the Accept and Accept-* header fields sent in
3176   the request.
3177
3178   Unless it was a HEAD request, the response SHOULD include a
3179   representation containing a list of available representation
3180   characteristics and location(s) from which the user or user agent can
3181   choose the one most appropriate.  Depending upon the format and the
3182   capabilities of the user agent, selection of the most appropriate
3183   choice MAY be performed automatically.  However, this specification
3184   does not define any standard for such automatic selection.
3185
3186
3187
3188
3189
3190
3191Fielding & Reschke        Expires April 7, 2013                [Page 57]
3192
3193Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
3194
3195
3196      Note: HTTP/1.1 servers are allowed to return responses which are
3197      not acceptable according to the accept header fields sent in the
3198      request.  In some cases, this might even be preferable to sending
3199      a 406 response.  User agents are encouraged to inspect the header
3200      fields of an incoming response to determine if it is acceptable.
3201
3202   If the response could be unacceptable, a user agent SHOULD
3203   temporarily stop receipt of more data and query the user for a
3204   decision on further actions.
3205
32067.5.7.  408 Request Timeout
3207
3208   The client did not produce a request within the time that the server
3209   was prepared to wait.  The client MAY repeat the request without
3210   modifications at any later time.
3211
32127.5.8.  409 Conflict
3213
3214   The request could not be completed due to a conflict with the current
3215   state of the resource.  This code is only allowed in situations where
3216   it is expected that the user might be able to resolve the conflict
3217   and resubmit the request.  The payload SHOULD include enough
3218   information for the user to recognize the source of the conflict.
3219   Ideally, the response representation would include enough information
3220   for the user or user agent to fix the problem; however, that might
3221   not be possible and is not required.
3222
3223   Conflicts are most likely to occur in response to a PUT request.  For
3224   example, if versioning were being used and the representation being
3225   PUT included changes to a resource which conflict with those made by
3226   an earlier (third-party) request, the server might use the 409
3227   response to indicate that it can't complete the request.  In this
3228   case, the response representation would likely contain a list of the
3229   differences between the two versions.
3230
32317.5.9.  410 Gone
3232
3233   The target resource is no longer available at the server and no
3234   forwarding address is known.  This condition is expected to be
3235   considered permanent.  Clients with link editing capabilities SHOULD
3236   delete references to the effective request URI after user approval.
3237   If the server does not know, or has no facility to determine, whether
3238   or not the condition is permanent, the status code 404 (Not Found)
3239   SHOULD be used instead.
3240
3241   The 410 response is primarily intended to assist the task of web
3242   maintenance by notifying the recipient that the resource is
3243   intentionally unavailable and that the server owners desire that
3244
3245
3246
3247Fielding & Reschke        Expires April 7, 2013                [Page 58]
3248
3249Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
3250
3251
3252   remote links to that resource be removed.  Such an event is common
3253   for limited-time, promotional services and for resources belonging to
3254   individuals no longer working at the server's site.  It is not
3255   necessary to mark all permanently unavailable resources as "gone" or
3256   to keep the mark for any length of time -- that is left to the
3257   discretion of the server owner.
3258
3259   Caches MAY use a heuristic (see Section 4.1.2 of [Part6]) to
3260   determine freshness for 410 responses.
3261
32627.5.10.  411 Length Required
3263
3264   The server refuses to accept the request without a defined Content-
3265   Length.  The client MAY repeat the request if it adds a valid
3266   Content-Length header field containing the length of the message body
3267   in the request message.
3268
32697.5.11.  413 Request Representation Too Large
3270
3271   The server is refusing to process a request because the request
3272   representation is larger than the server is willing or able to
3273   process.  The server MAY close the connection to prevent the client
3274   from continuing the request.
3275
3276   If the condition is temporary, the server SHOULD include a Retry-
3277   After header field to indicate that it is temporary and after what
3278   time the client MAY try again.
3279
32807.5.12.  414 URI Too Long
3281
3282   The server is refusing to service the request because the effective
3283   request URI is longer than the server is willing to interpret.  This
3284   rare condition is only likely to occur when a client has improperly
3285   converted a POST request to a GET request with long query
3286   information, when the client has descended into a URI "black hole" of
3287   redirection (e.g., a redirected URI prefix that points to a suffix of
3288   itself), or when the server is under attack by a client attempting to
3289   exploit security holes present in some servers using fixed-length
3290   buffers for reading or manipulating the request-target.
3291
32927.5.13.  415 Unsupported Media Type
3293
3294   The server is refusing to service the request because the request
3295   payload is in a format not supported by this request method on the
3296   target resource.
3297
3298
3299
3300
3301
3302
3303Fielding & Reschke        Expires April 7, 2013                [Page 59]
3304
3305Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
3306
3307
33087.5.14.  417 Expectation Failed
3309
3310   The expectation given in an Expect header field (see Section 6.1.2)
3311   could not be met by this server, or, if the server is a proxy, the
3312   server has unambiguous evidence that the request could not be met by
3313   the next-hop server.
3314
33157.5.15.  426 Upgrade Required
3316
3317   The request can not be completed without a prior protocol upgrade.
3318   This response MUST include an Upgrade header field (Section 6.3 of
3319   [Part1]) specifying the required protocols.
3320
3321   Example:
3322
3323     HTTP/1.1 426 Upgrade Required
3324     Upgrade: HTTP/3.0
3325     Connection: Upgrade
3326     Content-Length: 53
3327     Content-Type: text/plain
3328
3329     This service requires use of the HTTP/3.0 protocol.
3330
3331   The server SHOULD include a message body in the 426 response which
3332   indicates in human readable form the reason for the error and
3333   describes any alternative courses which might be available to the
3334   user.
3335
33367.6.  Server Error 5xx
3337
3338   Response status codes beginning with the digit "5" indicate cases in
3339   which the server is aware that it has erred or is incapable of
3340   performing the request.  Except when responding to a HEAD request,
3341   the server SHOULD include a representation containing an explanation
3342   of the error situation, and whether it is a temporary or permanent
3343   condition.  User agents SHOULD display any included representation to
3344   the user.  These response codes are applicable to any request method.
3345
33467.6.1.  500 Internal Server Error
3347
3348   The server encountered an unexpected condition which prevented it
3349   from fulfilling the request.
3350
33517.6.2.  501 Not Implemented
3352
3353   The server does not support the functionality required to fulfill the
3354   request.  This is the appropriate response when the server does not
3355   recognize the request method and is not capable of supporting it for
3356
3357
3358
3359Fielding & Reschke        Expires April 7, 2013                [Page 60]
3360
3361Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
3362
3363
3364   any resource.
3365
33667.6.3.  502 Bad Gateway
3367
3368   The server, while acting as a gateway or proxy, received an invalid
3369   response from the upstream server it accessed in attempting to
3370   fulfill the request.
3371
33727.6.4.  503 Service Unavailable
3373
3374   The server is currently unable to handle the request due to a
3375   temporary overloading or maintenance of the server.
3376
3377   The implication is that this is a temporary condition which will be
3378   alleviated after some delay.  If known, the length of the delay MAY
3379   be indicated in a Retry-After header field (Section 8.1.3).  If no
3380   Retry-After is given, the client SHOULD handle the response as it
3381   would for a 500 (Internal Server Error) response.
3382
3383      Note: The existence of the 503 status code does not imply that a
3384      server has to use it when becoming overloaded.  Some servers might
3385      wish to simply refuse the connection.
3386
33877.6.5.  504 Gateway Timeout
3388
3389   The server, while acting as a gateway or proxy, did not receive a
3390   timely response from the upstream server specified by the URI (e.g.,
3391   HTTP, FTP, LDAP) or some other auxiliary server (e.g., DNS) it needed
3392   to access in attempting to complete the request.
3393
3394      Note to implementers: some deployed proxies are known to return
3395      400 (Bad Request) or 500 (Internal Server Error) when DNS lookups
3396      time out.
3397
33987.6.6.  505 HTTP Version Not Supported
3399
3400   The server does not support, or refuses to support, the protocol
3401   version that was used in the request message.  The server is
3402   indicating that it is unable or unwilling to complete the request
3403   using the same major version as the client, as described in Section
3404   2.6 of [Part1], other than with this error message.  The response
3405   SHOULD contain a representation describing why that version is not
3406   supported and what other protocols are supported by that server.
3407
34088.  Response Header Fields
3409
3410   The response header fields allow the server to pass additional
3411   information about the response which cannot be placed in the status-
3412
3413
3414
3415Fielding & Reschke        Expires April 7, 2013                [Page 61]
3416
3417Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
3418
3419
3420   line.  These header fields give information about the server and
3421   about further access to the target resource (Section 5.5 of [Part1]).
3422
34238.1.  Control Data
3424
3425   Response header fields can supply control data that supplements the
3426   status code or instructs the client where to go next.
3427
3428   +-------------------+------------------------+
3429   | Header Field Name | Defined in...          |
3430   +-------------------+------------------------+
3431   | Age               | Section 7.1 of [Part6] |
3432   | Date              | Section 8.1.1.2        |
3433   | Location          | Section 8.1.2          |
3434   | Retry-After       | Section 8.1.3          |
3435   +-------------------+------------------------+
3436
34378.1.1.  Origination Date
3438
34398.1.1.1.  Date/Time Formats
3440
3441   HTTP applications have historically allowed three different formats
3442   for date/time stamps.  However, the preferred format is a fixed-
3443   length subset of that defined by [RFC1123]:
3444
3445     Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 1123
3446
3447   The other formats are described here only for compatibility with
3448   obsolete implementations.
3449
3450     Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
3451     Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format
3452
3453   HTTP/1.1 clients and servers that parse a date value MUST accept all
3454   three formats (for compatibility with HTTP/1.0), though they MUST
3455   only generate the RFC 1123 format for representing HTTP-date values
3456   in header fields.
3457
3458   All HTTP date/time stamps MUST be represented in Greenwich Mean Time
3459   (GMT), without exception.  For the purposes of HTTP, GMT is exactly
3460   equal to UTC (Coordinated Universal Time).  This is indicated in the
3461   first two formats by the inclusion of "GMT" as the three-letter
3462   abbreviation for time zone, and MUST be assumed when reading the
3463   asctime format.  HTTP-date is case sensitive and MUST NOT include
3464   additional whitespace beyond that specifically included as SP in the
3465   grammar.
3466
3467     HTTP-date    = rfc1123-date / obs-date
3468
3469
3470
3471Fielding & Reschke        Expires April 7, 2013                [Page 62]
3472
3473Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
3474
3475
3476   Preferred format:
3477
3478     rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT
3479     ; fixed length subset of the format defined in
3480     ; Section 5.2.14 of [RFC1123]
3481
3482     day-name     = %x4D.6F.6E ; "Mon", case-sensitive
3483                  / %x54.75.65 ; "Tue", case-sensitive
3484                  / %x57.65.64 ; "Wed", case-sensitive
3485                  / %x54.68.75 ; "Thu", case-sensitive
3486                  / %x46.72.69 ; "Fri", case-sensitive
3487                  / %x53.61.74 ; "Sat", case-sensitive
3488                  / %x53.75.6E ; "Sun", case-sensitive
3489
3490     date1        = day SP month SP year
3491                  ; e.g., 02 Jun 1982
3492
3493     day          = 2DIGIT
3494     month        = %x4A.61.6E ; "Jan", case-sensitive
3495                  / %x46.65.62 ; "Feb", case-sensitive
3496                  / %x4D.61.72 ; "Mar", case-sensitive
3497                  / %x41.70.72 ; "Apr", case-sensitive
3498                  / %x4D.61.79 ; "May", case-sensitive
3499                  / %x4A.75.6E ; "Jun", case-sensitive
3500                  / %x4A.75.6C ; "Jul", case-sensitive
3501                  / %x41.75.67 ; "Aug", case-sensitive
3502                  / %x53.65.70 ; "Sep", case-sensitive
3503                  / %x4F.63.74 ; "Oct", case-sensitive
3504                  / %x4E.6F.76 ; "Nov", case-sensitive
3505                  / %x44.65.63 ; "Dec", case-sensitive
3506     year         = 4DIGIT
3507
3508     GMT   = %x47.4D.54 ; "GMT", case-sensitive
3509
3510     time-of-day  = hour ":" minute ":" second
3511                    ; 00:00:00 - 23:59:59
3512
3513     hour         = 2DIGIT
3514     minute       = 2DIGIT
3515     second       = 2DIGIT
3516
3517   The semantics of day-name, day, month, year, and time-of-day are the
3518   same as those defined for the RFC 5322 constructs with the
3519   corresponding name ([RFC5322], Section 3.3).
3520
3521   Obsolete formats:
3522
3523     obs-date     = rfc850-date / asctime-date
3524
3525
3526
3527Fielding & Reschke        Expires April 7, 2013                [Page 63]
3528
3529Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
3530
3531
3532     rfc850-date  = day-name-l "," SP date2 SP time-of-day SP GMT
3533     date2        = day "-" month "-" 2DIGIT
3534                    ; day-month-year (e.g., 02-Jun-82)
3535
3536     day-name-l   = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive
3537            / %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive
3538            / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive
3539            / %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive
3540            / %x46.72.69.64.61.79 ; "Friday", case-sensitive
3541            / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive
3542            / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive
3543
3544
3545     asctime-date = day-name SP date3 SP time-of-day SP year
3546     date3        = month SP ( 2DIGIT / ( SP 1DIGIT ))
3547                    ; month day (e.g., Jun  2)
3548
3549      Note: Recipients of date values are encouraged to be robust in
3550      accepting date values that might have been sent by non-HTTP
3551      applications, as is sometimes the case when retrieving or posting
3552      messages via proxies/gateways to SMTP or NNTP.
3553
3554      Note: HTTP requirements for the date/time stamp format apply only
3555      to their usage within the protocol stream.  Clients and servers
3556      are not required to use these formats for user presentation,
3557      request logging, etc.
3558
35598.1.1.2.  Date
3560
3561   The "Date" header field represents the date and time at which the
3562   message was originated, having the same semantics as the Origination
3563   Date Field (orig-date) defined in Section 3.6.1 of [RFC5322].  The
3564   field value is an HTTP-date, as defined in Section 8.1.1.1; it MUST
3565   be sent in rfc1123-date format.
3566
3567     Date = HTTP-date
3568
3569   An example is
3570
3571     Date: Tue, 15 Nov 1994 08:12:31 GMT
3572
3573   Origin servers MUST include a Date header field in all responses,
3574   except in these cases:
3575
3576   1.  If the response status code is 100 (Continue) or 101 (Switching
3577       Protocols), the response MAY include a Date header field, at the
3578       server's option.
3579
3580
3581
3582
3583Fielding & Reschke        Expires April 7, 2013                [Page 64]
3584
3585Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
3586
3587
3588   2.  If the response status code conveys a server error, e.g., 500
3589       (Internal Server Error) or 503 (Service Unavailable), and it is
3590       inconvenient or impossible to generate a valid Date.
3591
3592   3.  If the server does not have a clock that can provide a reasonable
3593       approximation of the current time, its responses MUST NOT include
3594       a Date header field.
3595
3596   A received message that does not have a Date header field MUST be
3597   assigned one by the recipient if the message will be cached by that
3598   recipient.
3599
3600   Clients can use the Date header field as well; in order to keep
3601   request messages small, they are advised not to include it when it
3602   doesn't convey any useful information (as is usually the case for
3603   requests that do not contain a payload).
3604
3605   The HTTP-date sent in a Date header field SHOULD NOT represent a date
3606   and time subsequent to the generation of the message.  It SHOULD
3607   represent the best available approximation of the date and time of
3608   message generation, unless the implementation has no means of
3609   generating a reasonably accurate date and time.  In theory, the date
3610   ought to represent the moment just before the payload is generated.
3611   In practice, the date can be generated at any time during the message
3612   origination without affecting its semantic value.
3613
36148.1.2.  Location
3615
3616   The "Location" header field MAY be sent in responses to refer to a
3617   specific resource in accordance with the semantics of the status
3618   code.
3619
3620     Location = URI-reference
3621
3622   For 201 (Created) responses, the Location is the URI of the new
3623   resource which was created by the request.  For 3xx (Redirection)
3624   responses, the location SHOULD indicate the server's preferred URI
3625   for automatic redirection to the resource.
3626
3627   The field value consists of a single URI-reference.  When it has the
3628   form of a relative reference ([RFC3986], Section 4.2), the final
3629   value is computed by resolving it against the effective request URI
3630   ([RFC3986], Section 5).  If the original URI, as navigated to by the
3631   user agent, did contain a fragment identifier, and the final value
3632   does not, then the original URI's fragment identifier is added to the
3633   final value.
3634
3635
3636
3637
3638
3639Fielding & Reschke        Expires April 7, 2013                [Page 65]
3640
3641Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
3642
3643
3644   For example, the original URI "http://www.example.org/~tim", combined
3645   with a field value given as:
3646
3647     Location: /pub/WWW/People.html#tim
3648
3649   would result in a final value of
3650   "http://www.example.org/pub/WWW/People.html#tim"
3651
3652   An original URI "http://www.example.org/index.html#larry", combined
3653   with a field value given as:
3654
3655     Location: http://www.example.net/index.html
3656
3657   would result in a final value of
3658   "http://www.example.net/index.html#larry", preserving the original
3659   fragment identifier.
3660
3661      Note: Some recipients attempt to recover from Location fields that
3662      are not valid URI references.  This specification does not mandate
3663      or define such processing, but does allow it.
3664
3665   There are circumstances in which a fragment identifier in a Location
3666   URI would not be appropriate.  For instance, when it appears in a 201
3667   (Created) response, where the Location header field specifies the URI
3668   for the entire created resource.
3669
3670      Note: The Content-Location header field (Section 3.1.4.2) differs
3671      from Location in that the Content-Location identifies the most
3672      specific resource corresponding to the enclosed representation.
3673      It is therefore possible for a response to contain header fields
3674      for both Location and Content-Location.
3675
36768.1.3.  Retry-After
3677
3678   The header "Retry-After" field can be used with a 503 (Service
3679   Unavailable) response to indicate how long the service is expected to
3680   be unavailable to the requesting client.  This field MAY also be used
3681   with any 3xx (Redirection) response to indicate the minimum time the
3682   user-agent is asked to wait before issuing the redirected request.
3683
3684   The value of this field can be either an HTTP-date or an integer
3685   number of seconds (in decimal) after the time of the response.
3686
3687     Retry-After = HTTP-date / delta-seconds
3688
3689   Time spans are non-negative decimal integers, representing time in
3690   seconds.
3691
3692
3693
3694
3695Fielding & Reschke        Expires April 7, 2013                [Page 66]
3696
3697Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
3698
3699
3700     delta-seconds  = 1*DIGIT
3701
3702   Two examples of its use are
3703
3704     Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
3705     Retry-After: 120
3706
3707   In the latter example, the delay is 2 minutes.
3708
37098.2.  Selected Representation Header Fields
3710
3711   We use the term "selected representation" to refer to the the current
3712   representation of a target resource that would have been selected in
3713   a successful response if the same request had used the method GET and
3714   excluded any conditional request header fields.
3715
3716   Additional header fields define metadata about the selected
3717   representation, which might differ from the representation included
3718   in the message for responses to some state-changing methods.  The
3719   following header fields are defined as selected representation
3720   metadata:
3721
3722   +-------------------+------------------------+
3723   | Header Field Name | Defined in...          |
3724   +-------------------+------------------------+
3725   | ETag              | Section 2.3 of [Part4] |
3726   | Last-Modified     | Section 2.2 of [Part4] |
3727   | Vary              | Section 8.2.1          |
3728   +-------------------+------------------------+
3729
37308.2.1.  Vary
3731
3732   The "Vary" header field conveys the set of header fields that were
3733   used to select the representation.
3734
3735   Caches use this information as part of determining whether a stored
3736   response can be used to satisfy a given request (Section 4.3 of
3737   [Part6]).
3738
3739   In uncacheable or stale responses, the Vary field value advises the
3740   user agent about the criteria that were used to select the
3741   representation.
3742
3743     Vary = "*" / 1#field-name
3744
3745   The set of header fields named by the Vary field value is known as
3746   the selecting header fields.
3747
3748
3749
3750
3751Fielding & Reschke        Expires April 7, 2013                [Page 67]
3752
3753Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
3754
3755
3756   A server SHOULD include a Vary header field with any cacheable
3757   response that is subject to proactive negotiation.  Doing so allows a
3758   cache to properly interpret future requests on that resource and
3759   informs the user agent about the presence of negotiation on that
3760   resource.  A server MAY include a Vary header field with a non-
3761   cacheable response that is subject to proactive negotiation, since
3762   this might provide the user agent with useful information about the
3763   dimensions over which the response varies at the time of the
3764   response.
3765
3766   A Vary field value of "*" signals that unspecified parameters not
3767   limited to the header fields (e.g., the network address of the
3768   client), play a role in the selection of the response representation;
3769   therefore, a cache cannot determine whether this response is
3770   appropriate.  A proxy MUST NOT generate the "*" value.
3771
3772   The field-names given are not limited to the set of standard header
3773   fields defined by this specification.  Field names are case-
3774   insensitive.
3775
37768.3.  Authentication Challenges
3777
3778   Authentication challenges indicate what mechanisms are available for
3779   the client to provide authentication credentials in future requests.
3780
3781   +--------------------+------------------------+
3782   | Header Field Name  | Defined in...          |
3783   +--------------------+------------------------+
3784   | WWW-Authenticate   | Section 4.4 of [Part7] |
3785   | Proxy-Authenticate | Section 4.2 of [Part7] |
3786   +--------------------+------------------------+
3787
37888.4.  Informative
3789
3790   The remaining response header fields provide more information about
3791   the target resource for potential use in later requests.
3792
3793   +-------------------+------------------------+
3794   | Header Field Name | Defined in...          |
3795   +-------------------+------------------------+
3796   | Accept-Ranges     | Section 5.1 of [Part5] |
3797   | Allow             | Section 8.4.1          |
3798   | Server            | Section 8.4.2          |
3799   +-------------------+------------------------+
3800
3801
3802
3803
3804
3805
3806
3807Fielding & Reschke        Expires April 7, 2013                [Page 68]
3808
3809Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
3810
3811
38128.4.1.  Allow
3813
3814   The "Allow" header field lists the set of methods advertised as
3815   supported by the target resource.  The purpose of this field is
3816   strictly to inform the recipient of valid request methods associated
3817   with the resource.
3818
3819     Allow = #method
3820
3821   Example of use:
3822
3823     Allow: GET, HEAD, PUT
3824
3825   The actual set of allowed methods is defined by the origin server at
3826   the time of each request.
3827
3828   A proxy MUST NOT modify the Allow header field -- it does not need to
3829   understand all the methods specified in order to handle them
3830   according to the generic message handling rules.
3831
38328.4.2.  Server
3833
3834   The "Server" header field contains information about the software
3835   used by the origin server to handle the request.
3836
3837   The field can contain multiple product tokens (Section 4) and
3838   comments (Section 3.2 of [Part1]) identifying the server and any
3839   significant subproducts.  The product tokens are listed in order of
3840   their significance for identifying the application.
3841
3842     Server = product *( RWS ( product / comment ) )
3843
3844   Example:
3845
3846     Server: CERN/3.0 libwww/2.17
3847
3848   If the response is being forwarded through a proxy, the proxy
3849   application MUST NOT modify the Server header field.  Instead, it
3850   MUST include a Via field (as described in Section 5.7 of [Part1]).
3851
3852      Note: Revealing the specific software version of the server might
3853      allow the server machine to become more vulnerable to attacks
3854      against software that is known to contain security holes.  Server
3855      implementers are encouraged to make this field a configurable
3856      option.
3857
3858
3859
3860
3861
3862
3863Fielding & Reschke        Expires April 7, 2013                [Page 69]
3864
3865Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
3866
3867
38689.  IANA Considerations
3869
38709.1.  Method Registry
3871
3872   The HTTP Method Registry defines the name space for the request
3873   method token (Section 5).  The method registry is maintained at
3874   <http://www.iana.org/assignments/http-methods>.
3875
38769.1.1.  Procedure
3877
3878   HTTP method registrations MUST include the following fields:
3879
3880   o  Method Name (see Section 5)
3881
3882   o  Safe ("yes" or "no", see Section 5.2.1)
3883
3884   o  Idempotent ("yes" or "no", see Section 5.2.2)
3885
3886   o  Pointer to specification text
3887
3888   Values to be added to this name space require IETF Review (see
3889   [RFC5226], Section 4.1).
3890
38919.1.2.  Considerations for New Methods
3892
3893   Standardized methods are generic; that is, they are potentially
3894   applicable to any resource, not just one particular media type, kind
3895   of resource, or application.  As such, it is preferred that new
3896   methods be registered in a document that isn't specific to a single
3897   application or data format, since orthogonal technologies deserve
3898   orthogonal specification.
3899
3900   Since message parsing (Section 3.3 of [Part1]) needs to be
3901   independent of method semantics (aside from responses to HEAD),
3902   definitions of new methods cannot change the parsing algorithm or
3903   prohibit the presence of a message body on either the request or the
3904   response message.  Definitions of new methods can specify that only a
3905   zero-length message body is allowed by requiring a Content-Length
3906   header field with a value of "0".
3907
3908   New method definitions need to indicate whether they are safe
3909   (Section 5.2.1), idempotent (Section 5.2.2), cacheable
3910   (Section 5.2.3), and what semantics are to be associated with the
3911   payload body if any is present in the request.  If a method is
3912   cacheable, the method definition ought to describe how, and under
3913   what conditions, a cache can store a response and use it to satisfy a
3914   subsequent request.
3915
3916
3917
3918
3919Fielding & Reschke        Expires April 7, 2013                [Page 70]
3920
3921Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
3922
3923
39249.1.3.  Registrations
3925
3926   The HTTP Method Registry shall be populated with the registrations
3927   below:
3928
3929   +---------+------+------------+---------------+
3930   | Method  | Safe | Idempotent | Reference     |
3931   +---------+------+------------+---------------+
3932   | CONNECT | no   | no         | Section 5.3.6 |
3933   | DELETE  | no   | yes        | Section 5.3.5 |
3934   | GET     | yes  | yes        | Section 5.3.1 |
3935   | HEAD    | yes  | yes        | Section 5.3.2 |
3936   | OPTIONS | yes  | yes        | Section 5.3.7 |
3937   | POST    | no   | no         | Section 5.3.3 |
3938   | PUT     | no   | yes        | Section 5.3.4 |
3939   | TRACE   | yes  | yes        | Section 5.3.8 |
3940   +---------+------+------------+---------------+
3941
39429.2.  Status Code Registry
3943
3944   The HTTP Status Code Registry defines the name space for the response
3945   status-code token (Section 7).  The status code registry is
3946   maintained at <http://www.iana.org/assignments/http-status-codes>.
3947
3948   This section replaces the registration procedure for HTTP Status
3949   Codes previously defined in Section 7.1 of [RFC2817].
3950
39519.2.1.  Procedure
3952
3953   Values to be added to the HTTP status code name space require IETF
3954   Review (see [RFC5226], Section 4.1).
3955
39569.2.2.  Considerations for New Status Codes
3957
3958   When it is necessary to express semantics for a response that are not
3959   defined by current status codes, a new status code can be registered.
3960   HTTP status codes are generic; they are potentially applicable to any
3961   resource, not just one particular media type, "type" of resource, or
3962   application.  As such, it is preferred that new status codes be
3963   registered in a document that isn't specific to a single application.
3964
3965   New status codes are required to fall under one of the categories
3966   defined in Section 7.  To allow existing parsers to properly handle
3967   them, new status codes cannot disallow a payload, although they can
3968   mandate a zero-length payload body.
3969
3970   A definition for a new status code ought to explain the request
3971   conditions that produce a response containing that status code (e.g.,
3972
3973
3974
3975Fielding & Reschke        Expires April 7, 2013                [Page 71]
3976
3977Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
3978
3979
3980   combinations of request header fields and/or method(s)) along with
3981   any dependencies on response header fields (e.g., what fields are
3982   required and what fields can modify the semantics).  A response that
3983   can transfer a payload ought to specify expected cache behavior
3984   (e.g., cacheability and freshness criteria, as described in [Part6])
3985   and whether the payload has any implied association with an
3986   identified resource (Section 3.1.4.1).
3987
39889.2.3.  Registrations
3989
3990   The HTTP Status Code Registry shall be updated with the registrations
3991   below:
3992
3993
3994
3995
3996
3997
3998
3999
4000
4001
4002
4003
4004
4005
4006
4007
4008
4009
4010
4011
4012
4013
4014
4015
4016
4017
4018
4019
4020
4021
4022
4023
4024
4025
4026
4027
4028
4029
4030
4031Fielding & Reschke        Expires April 7, 2013                [Page 72]
4032
4033Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
4034
4035
4036   +-------+----------------------------------+----------------+
4037   | Value | Description                      | Reference      |
4038   +-------+----------------------------------+----------------+
4039   | 100   | Continue                         | Section 7.2.1  |
4040   | 101   | Switching Protocols              | Section 7.2.2  |
4041   | 200   | OK                               | Section 7.3.1  |
4042   | 201   | Created                          | Section 7.3.2  |
4043   | 202   | Accepted                         | Section 7.3.3  |
4044   | 203   | Non-Authoritative Information    | Section 7.3.4  |
4045   | 204   | No Content                       | Section 7.3.5  |
4046   | 205   | Reset Content                    | Section 7.3.6  |
4047   | 300   | Multiple Choices                 | Section 7.4.1  |
4048   | 301   | Moved Permanently                | Section 7.4.2  |
4049   | 302   | Found                            | Section 7.4.3  |
4050   | 303   | See Other                        | Section 7.4.4  |
4051   | 305   | Use Proxy                        | Section 7.4.5  |
4052   | 306   | (Unused)                         | Section 7.4.6  |
4053   | 307   | Temporary Redirect               | Section 7.4.7  |
4054   | 400   | Bad Request                      | Section 7.5.1  |
4055   | 402   | Payment Required                 | Section 7.5.2  |
4056   | 403   | Forbidden                        | Section 7.5.3  |
4057   | 404   | Not Found                        | Section 7.5.4  |
4058   | 405   | Method Not Allowed               | Section 7.5.5  |
4059   | 406   | Not Acceptable                   | Section 7.5.6  |
4060   | 408   | Request Timeout                  | Section 7.5.7  |
4061   | 409   | Conflict                         | Section 7.5.8  |
4062   | 410   | Gone                             | Section 7.5.9  |
4063   | 411   | Length Required                  | Section 7.5.10 |
4064   | 413   | Request Representation Too Large | Section 7.5.11 |
4065   | 414   | URI Too Long                     | Section 7.5.12 |
4066   | 415   | Unsupported Media Type           | Section 7.5.13 |
4067   | 417   | Expectation Failed               | Section 7.5.14 |
4068   | 426   | Upgrade Required                 | Section 7.5.15 |
4069   | 500   | Internal Server Error            | Section 7.6.1  |
4070   | 501   | Not Implemented                  | Section 7.6.2  |
4071   | 502   | Bad Gateway                      | Section 7.6.3  |
4072   | 503   | Service Unavailable              | Section 7.6.4  |
4073   | 504   | Gateway Timeout                  | Section 7.6.5  |
4074   | 505   | HTTP Version Not Supported       | Section 7.6.6  |
4075   +-------+----------------------------------+----------------+
4076
40779.3.  Header Field Registry
4078
4079   HTTP header fields are registered within the Message Header Field
4080   Registry located at <http://www.iana.org/assignments/message-headers/
4081   message-header-index.html>, as defined by [RFC3864].
4082
4083
4084
4085
4086
4087Fielding & Reschke        Expires April 7, 2013                [Page 73]
4088
4089Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
4090
4091
40929.3.1.  Considerations for New Header Fields
4093
4094   Header fields are key:value pairs that can be used to communicate
4095   data about the message, its payload, the target resource, or the
4096   connection (i.e., control data).  See Section 3.2 of [Part1] for a
4097   general definition of header field syntax in HTTP messages.
4098
4099   The requirements for header field names are defined in Section 4.1 of
4100   [RFC3864].  Authors of specifications defining new fields are advised
4101   to keep the name as short as practical, and not to prefix them with
4102   "X-" if they are to be registered (either immediately or in the
4103   future).
4104
4105   New header field values typically have their syntax defined using
4106   ABNF ([RFC5234]), using the extension defined in Appendix B of
4107   [Part1] as necessary, and are usually constrained to the range of
4108   ASCII characters.  Header fields needing a greater range of
4109   characters can use an encoding such as the one defined in [RFC5987].
4110
4111   Because commas (",") are used as a generic delimiter between field-
4112   values, they need to be treated with care if they are allowed in the
4113   field-value's payload.  Typically, components that might contain a
4114   comma are protected with double-quotes using the quoted-string ABNF
4115   production (Section 3.2.4 of [Part1]).
4116
4117   For example, a textual date and a URI (either of which might contain
4118   a comma) could be safely carried in field-values like these:
4119
4120     Example-URI-Field: "http://example.com/a.html,foo",
4121                        "http://without-a-comma.example.com/"
4122     Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005"
4123
4124   Note that double-quote delimiters almost always are used with the
4125   quoted-string production; using a different syntax inside double-
4126   quotes will likely cause unnecessary confusion.
4127
4128   Many header fields use a format including (case-insensitively) named
4129   parameters (for instance, Content-Type, defined in Section 3.1.1.5).
4130   Allowing both unquoted (token) and quoted (quoted-string) syntax for
4131   the parameter value enables recipients to use existing parser
4132   components.  When allowing both forms, the meaning of a parameter
4133   value ought to be independent of the syntax used for it (for an
4134   example, see the notes on parameter handling for media types in
4135   Section 3.1.1.1).
4136
4137   Authors of specifications defining new header fields are advised to
4138   consider documenting:
4139
4140
4141
4142
4143Fielding & Reschke        Expires April 7, 2013                [Page 74]
4144
4145Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
4146
4147
4148   o  Whether the field is a single value, or whether it can be a list
4149      (delimited by commas; see Section 3.2 of [Part1]).
4150
4151      If it does not use the list syntax, document how to treat messages
4152      where the header field occurs multiple times (a sensible default
4153      would be to ignore the header field, but this might not always be
4154      the right choice).
4155
4156      Note that intermediaries and software libraries might combine
4157      multiple header field instances into a single one, despite the
4158      header field not allowing this.  A robust format enables
4159      recipients to discover these situations (good example: "Content-
4160      Type", as the comma can only appear inside quoted strings; bad
4161      example: "Location", as a comma can occur inside a URI).
4162
4163   o  Under what conditions the header field can be used; e.g., only in
4164      responses or requests, in all messages, only on responses to a
4165      particular request method.
4166
4167   o  Whether it is appropriate to list the field-name in the Connection
4168      header field (i.e., if the header field is to be hop-by-hop, see
4169      Section 6.1 of [Part1]).
4170
4171   o  Under what conditions intermediaries are allowed to modify the
4172      header field's value, insert or delete it.
4173
4174   o  How the header field might interact with caching (see [Part6]).
4175
4176   o  Whether the header field is useful or allowable in trailers (see
4177      Section 4.1 of [Part1]).
4178
4179   o  Whether the header field ought to be preserved across redirects.
4180
41819.3.2.  Registrations
4182
4183   The Message Header Field Registry shall be updated with the following
4184   permanent registrations:
4185
4186
4187
4188
4189
4190
4191
4192
4193
4194
4195
4196
4197
4198
4199Fielding & Reschke        Expires April 7, 2013                [Page 75]
4200
4201Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
4202
4203
4204   +-------------------+----------+----------+-----------------+
4205   | Header Field Name | Protocol | Status   | Reference       |
4206   +-------------------+----------+----------+-----------------+
4207   | Accept            | http     | standard | Section 6.3.2   |
4208   | Accept-Charset    | http     | standard | Section 6.3.3   |
4209   | Accept-Encoding   | http     | standard | Section 6.3.4   |
4210   | Accept-Language   | http     | standard | Section 6.3.5   |
4211   | Allow             | http     | standard | Section 8.4.1   |
4212   | Content-Encoding  | http     | standard | Section 3.1.2.2 |
4213   | Content-Language  | http     | standard | Section 3.1.3.2 |
4214   | Content-Location  | http     | standard | Section 3.1.4.2 |
4215   | Content-Type      | http     | standard | Section 3.1.1.5 |
4216   | Date              | http     | standard | Section 8.1.1.2 |
4217   | Expect            | http     | standard | Section 6.1.2   |
4218   | From              | http     | standard | Section 6.5.1   |
4219   | Location          | http     | standard | Section 8.1.2   |
4220   | MIME-Version      | http     | standard | Appendix A.1    |
4221   | Max-Forwards      | http     | standard | Section 6.1.1   |
4222   | Referer           | http     | standard | Section 6.5.2   |
4223   | Retry-After       | http     | standard | Section 8.1.3   |
4224   | Server            | http     | standard | Section 8.4.2   |
4225   | User-Agent        | http     | standard | Section 6.5.3   |
4226   | Vary              | http     | standard | Section 8.2.1   |
4227   +-------------------+----------+----------+-----------------+
4228
4229   The change controller for the above registrations is: "IETF
4230   (iesg@ietf.org) - Internet Engineering Task Force".
4231
42329.4.  Content Coding Registry
4233
4234   The HTTP Content Coding Registry defines the name space for content
4235   coding names (Section 4.2 of [Part1]).  The content coding registry
4236   is maintained at <http://www.iana.org/assignments/http-parameters>.
4237
42389.4.1.  Procedure
4239
4240   Content Coding registrations MUST include the following fields:
4241
4242   o  Name
4243
4244   o  Description
4245
4246   o  Pointer to specification text
4247
4248   Names of content codings MUST NOT overlap with names of transfer
4249   codings (Section 4 of [Part1]), unless the encoding transformation is
4250   identical (as is the case for the compression codings defined in
4251   Section 4.2 of [Part1]).
4252
4253
4254
4255Fielding & Reschke        Expires April 7, 2013                [Page 76]
4256
4257Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
4258
4259
4260   Values to be added to this name space require IETF Review (see
4261   Section 4.1 of [RFC5226]), and MUST conform to the purpose of content
4262   coding defined in this section.
4263
42649.4.2.  Registrations
4265
4266   The HTTP Content Codings Registry shall be updated with the
4267   registrations below:
4268
4269   +----------+----------------------------------------+---------------+
4270   | Name     | Description                            | Reference     |
4271   +----------+----------------------------------------+---------------+
4272   | compress | UNIX "compress" program method         | Section 4.2.1 |
4273   |          |                                        | of [Part1]    |
4274   | deflate  | "deflate" compression mechanism        | Section 4.2.2 |
4275   |          | ([RFC1951]) used inside the "zlib"     | of [Part1]    |
4276   |          | data format ([RFC1950])                |               |
4277   | gzip     | Same as GNU zip [RFC1952]              | Section 4.2.3 |
4278   |          |                                        | of [Part1]    |
4279   | identity | reserved (synonym for "no encoding" in | Section 6.3.4 |
4280   |          | Accept-Encoding header field)          |               |
4281   +----------+----------------------------------------+---------------+
4282
428310.  Security Considerations
4284
4285   This section is meant to inform application developers, information
4286   providers, and users of the security limitations in HTTP/1.1 as
4287   described by this document.  The discussion does not include
4288   definitive solutions to the problems revealed, though it does make
4289   some suggestions for reducing security risks.
4290
429110.1.  Transfer of Sensitive Information
4292
4293   Like any generic data transfer protocol, HTTP cannot regulate the
4294   content of the data that is transferred, nor is there any a priori
4295   method of determining the sensitivity of any particular piece of
4296   information within the context of any given request.  Therefore,
4297   applications SHOULD supply as much control over this information as
4298   possible to the provider of that information.  Four header fields are
4299   worth special mention in this context: Server, Via, Referer and From.
4300
4301   Revealing the specific software version of the server might allow the
4302   server machine to become more vulnerable to attacks against software
4303   that is known to contain security holes.  Implementers SHOULD make
4304   the Server header field a configurable option.
4305
4306   Proxies which serve as a portal through a network firewall SHOULD
4307   take special precautions regarding the transfer of header information
4308
4309
4310
4311Fielding & Reschke        Expires April 7, 2013                [Page 77]
4312
4313Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
4314
4315
4316   that identifies the hosts behind the firewall.  In particular, they
4317   SHOULD remove, or replace with sanitized versions, any Via fields
4318   generated behind the firewall.
4319
4320   The Referer header field allows reading patterns to be studied and
4321   reverse links drawn.  Although it can be very useful, its power can
4322   be abused if user details are not separated from the information
4323   contained in the Referer.  Even when the personal information has
4324   been removed, the Referer header field might indicate a private
4325   document's URI whose publication would be inappropriate.
4326
4327   The information sent in the From field might conflict with the user's
4328   privacy interests or their site's security policy, and hence it
4329   SHOULD NOT be transmitted without the user being able to disable,
4330   enable, and modify the contents of the field.  The user MUST be able
4331   to set the contents of this field within a user preference or
4332   application defaults configuration.
4333
4334   We suggest, though do not require, that a convenient toggle interface
4335   be provided for the user to enable or disable the sending of From and
4336   Referer information.
4337
4338   The User-Agent (Section 6.5.3) or Server (Section 8.4.2) header
4339   fields can sometimes be used to determine that a specific client or
4340   server has a particular security hole which might be exploited.
4341   Unfortunately, this same information is often used for other valuable
4342   purposes for which HTTP currently has no better mechanism.
4343
4344   Furthermore, the User-Agent header field might contain enough entropy
4345   to be used, possibly in conjunction with other material, to uniquely
4346   identify the user.
4347
4348   Some request methods, like TRACE (Section 5.3.8), expose information
4349   that was sent in request header fields within the body of their
4350   response.  Clients SHOULD be careful with sensitive information, like
4351   Cookies, Authorization credentials, and other header fields that
4352   might be used to collect data from the client.
4353
435410.2.  Encoding Sensitive Information in URIs
4355
4356   Because the source of a link might be private information or might
4357   reveal an otherwise private information source, it is strongly
4358   recommended that the user be able to select whether or not the
4359   Referer field is sent.  For example, a browser client could have a
4360   toggle switch for browsing openly/anonymously, which would
4361   respectively enable/disable the sending of Referer and From
4362   information.
4363
4364
4365
4366
4367Fielding & Reschke        Expires April 7, 2013                [Page 78]
4368
4369Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
4370
4371
4372   Clients SHOULD NOT include a Referer header field in a (non-secure)
4373   HTTP request if the referring page was transferred with a secure
4374   protocol.
4375
4376   Authors of services SHOULD NOT use GET-based forms for the submission
4377   of sensitive data because that data will be placed in the request-
4378   target.  Many existing servers, proxies, and user agents log or
4379   display the request-target in places where it might be visible to
4380   third parties.  Such services can use POST-based form submission
4381   instead.
4382
438310.3.  Location Header Fields: Spoofing and Information Leakage
4384
4385   If a single server supports multiple organizations that do not trust
4386   one another, then it MUST check the values of Location and Content-
4387   Location header fields in responses that are generated under control
4388   of said organizations to make sure that they do not attempt to
4389   invalidate resources over which they have no authority.
4390
4391   Furthermore, appending the fragment identifier from one URI to
4392   another one obtained from a Location header field might leak
4393   confidential information to the target server -- although the
4394   fragment identifier is not transmitted in the final request, it might
4395   be visible to the user agent through other means, such as scripting.
4396
439710.4.  Security Considerations for CONNECT
4398
4399   Since tunneled data is opaque to the proxy, there are additional
4400   risks to tunneling to other well-known or reserved ports.  A HTTP
4401   client CONNECTing to port 25 could relay spam via SMTP, for example.
4402   As such, proxies SHOULD restrict CONNECT access to a small number of
4403   known ports.
4404
440510.5.  Privacy Issues Connected to Accept Header Fields
4406
4407   Accept header fields can reveal information about the user to all
4408   servers which are accessed.  The Accept-Language header field in
4409   particular can reveal information the user would consider to be of a
4410   private nature, because the understanding of particular languages is
4411   often strongly correlated to the membership of a particular ethnic
4412   group.  User agents which offer the option to configure the contents
4413   of an Accept-Language header field to be sent in every request are
4414   strongly encouraged to let the configuration process include a
4415   message which makes the user aware of the loss of privacy involved.
4416
4417   An approach that limits the loss of privacy would be for a user agent
4418   to omit the sending of Accept-Language header fields by default, and
4419   to ask the user whether or not to start sending Accept-Language
4420
4421
4422
4423Fielding & Reschke        Expires April 7, 2013                [Page 79]
4424
4425Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
4426
4427
4428   header fields to a server if it detects, by looking for any Vary
4429   header fields generated by the server, that such sending could
4430   improve the quality of service.
4431
4432   Elaborate user-customized accept header fields sent in every request,
4433   in particular if these include quality values, can be used by servers
4434   as relatively reliable and long-lived user identifiers.  Such user
4435   identifiers would allow content providers to do click-trail tracking,
4436   and would allow collaborating content providers to match cross-server
4437   click-trails or form submissions of individual users.  Note that for
4438   many users not behind a proxy, the network address of the host
4439   running the user agent will also serve as a long-lived user
4440   identifier.  In environments where proxies are used to enhance
4441   privacy, user agents ought to be conservative in offering accept
4442   header field configuration options to end users.  As an extreme
4443   privacy measure, proxies could filter the accept header fields in
4444   relayed requests.  General purpose user agents which provide a high
4445   degree of header field configurability SHOULD warn users about the
4446   loss of privacy which can be involved.
4447
444811.  Acknowledgments
4449
4450   See Section 9 of [Part1].
4451
445212.  References
4453
445412.1.  Normative References
4455
4456   [Part1]       Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
4457                 Transfer Protocol (HTTP/1.1): Message Syntax and
4458                 Routing", draft-ietf-httpbis-p1-messaging-21 (work in
4459                 progress), October 2012.
4460
4461   [Part4]       Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
4462                 Transfer Protocol (HTTP/1.1): Conditional Requests",
4463                 draft-ietf-httpbis-p4-conditional-21 (work in
4464                 progress), October 2012.
4465
4466   [Part5]       Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
4467                 "Hypertext Transfer Protocol (HTTP/1.1): Range
4468                 Requests", draft-ietf-httpbis-p5-range-21 (work in
4469                 progress), October 2012.
4470
4471   [Part6]       Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
4472                 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
4473                 draft-ietf-httpbis-p6-cache-21 (work in progress),
4474                 October 2012.
4475
4476
4477
4478
4479Fielding & Reschke        Expires April 7, 2013                [Page 80]
4480
4481Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
4482
4483
4484   [Part7]       Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
4485                 Transfer Protocol (HTTP/1.1): Authentication",
4486                 draft-ietf-httpbis-p7-auth-21 (work in progress),
4487                 October 2012.
4488
4489   [RFC1950]     Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
4490                 Format Specification version 3.3", RFC 1950, May 1996.
4491
4492   [RFC1951]     Deutsch, P., "DEFLATE Compressed Data Format
4493                 Specification version 1.3", RFC 1951, May 1996.
4494
4495   [RFC1952]     Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and
4496                 G. Randers-Pehrson, "GZIP file format specification
4497                 version 4.3", RFC 1952, May 1996.
4498
4499   [RFC2045]     Freed, N. and N. Borenstein, "Multipurpose Internet
4500                 Mail Extensions (MIME) Part One: Format of Internet
4501                 Message Bodies", RFC 2045, November 1996.
4502
4503   [RFC2046]     Freed, N. and N. Borenstein, "Multipurpose Internet
4504                 Mail Extensions (MIME) Part Two: Media Types",
4505                 RFC 2046, November 1996.
4506
4507   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
4508                 Requirement Levels", BCP 14, RFC 2119, March 1997.
4509
4510   [RFC3986]     Berners-Lee, T., Fielding, R., and L. Masinter,
4511                 "Uniform Resource Identifier (URI): Generic Syntax",
4512                 STD 66, RFC 3986, January 2005.
4513
4514   [RFC4647]     Phillips, A., Ed. and M. Davis, Ed., "Matching of
4515                 Language Tags", BCP 47, RFC 4647, September 2006.
4516
4517   [RFC5234]     Crocker, D., Ed. and P. Overell, "Augmented BNF for
4518                 Syntax Specifications: ABNF", STD 68, RFC 5234,
4519                 January 2008.
4520
4521   [RFC5646]     Phillips, A., Ed. and M. Davis, Ed., "Tags for
4522                 Identifying Languages", BCP 47, RFC 5646,
4523                 September 2009.
4524
452512.2.  Informative References
4526
4527   [REST]        Fielding, R., "Architectural Styles and the Design of
4528                 Network-based Software Architectures", Doctoral
4529                 Dissertation, University of California, Irvine ,
4530                 September 2000,
4531                 <http://roy.gbiv.com/pubs/dissertation/top.htm>.
4532
4533
4534
4535Fielding & Reschke        Expires April 7, 2013                [Page 81]
4536
4537Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
4538
4539
4540   [RFC1123]     Braden, R., "Requirements for Internet Hosts -
4541                 Application and Support", STD 3, RFC 1123,
4542                 October 1989.
4543
4544   [RFC1945]     Berners-Lee, T., Fielding, R., and H. Nielsen,
4545                 "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,
4546                 May 1996.
4547
4548   [RFC2049]     Freed, N. and N. Borenstein, "Multipurpose Internet
4549                 Mail Extensions (MIME) Part Five: Conformance Criteria
4550                 and Examples", RFC 2049, November 1996.
4551
4552   [RFC2068]     Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and
4553                 T. Berners-Lee, "Hypertext Transfer Protocol --
4554                 HTTP/1.1", RFC 2068, January 1997.
4555
4556   [RFC2076]     Palme, J., "Common Internet Message Headers", RFC 2076,
4557                 February 1997.
4558
4559   [RFC2277]     Alvestrand, H., "IETF Policy on Character Sets and
4560                 Languages", BCP 18, RFC 2277, January 1998.
4561
4562   [RFC2295]     Holtman, K. and A. Mutz, "Transparent Content
4563                 Negotiation in HTTP", RFC 2295, March 1998.
4564
4565   [RFC2388]     Masinter, L., "Returning Values from Forms:  multipart/
4566                 form-data", RFC 2388, August 1998.
4567
4568   [RFC2557]     Palme, F., Hopmann, A., Shelness, N., and E. Stefferud,
4569                 "MIME Encapsulation of Aggregate Documents, such as
4570                 HTML (MHTML)", RFC 2557, March 1999.
4571
4572   [RFC2616]     Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
4573                 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
4574                 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
4575
4576   [RFC2817]     Khare, R. and S. Lawrence, "Upgrading to TLS Within
4577                 HTTP/1.1", RFC 2817, May 2000.
4578
4579   [RFC3629]     Yergeau, F., "UTF-8, a transformation format of ISO
4580                 10646", STD 63, RFC 3629, November 2003.
4581
4582   [RFC3864]     Klyne, G., Nottingham, M., and J. Mogul, "Registration
4583                 Procedures for Message Header Fields", BCP 90,
4584                 RFC 3864, September 2004.
4585
4586   [RFC4288]     Freed, N. and J. Klensin, "Media Type Specifications
4587                 and Registration Procedures", BCP 13, RFC 4288,
4588
4589
4590
4591Fielding & Reschke        Expires April 7, 2013                [Page 82]
4592
4593Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
4594
4595
4596                 December 2005.
4597
4598   [RFC5226]     Narten, T. and H. Alvestrand, "Guidelines for Writing
4599                 an IANA Considerations Section in RFCs", BCP 26,
4600                 RFC 5226, May 2008.
4601
4602   [RFC5322]     Resnick, P., "Internet Message Format", RFC 5322,
4603                 October 2008.
4604
4605   [RFC5789]     Dusseault, L. and J. Snell, "PATCH Method for HTTP",
4606                 RFC 5789, March 2010.
4607
4608   [RFC5987]     Reschke, J., "Character Set and Language Encoding for
4609                 Hypertext Transfer Protocol (HTTP) Header Field
4610                 Parameters", RFC 5987, August 2010.
4611
4612   [RFC6151]     Turner, S. and L. Chen, "Updated Security
4613                 Considerations for the MD5 Message-Digest and the HMAC-
4614                 MD5 Algorithms", RFC 6151, March 2011.
4615
4616   [RFC6266]     Reschke, J., "Use of the Content-Disposition Header
4617                 Field in the Hypertext Transfer Protocol (HTTP)",
4618                 RFC 6266, June 2011.
4619
4620   [status-308]  Reschke, J., "The Hypertext Transfer Protocol (HTTP)
4621                 Status Code 308 (Permanent Redirect)",
4622                 draft-reschke-http-status-308-07 (work in progress),
4623                 March 2012.
4624
4625Appendix A.  Differences between HTTP and MIME
4626
4627   HTTP/1.1 uses many of the constructs defined for Internet Mail
4628   ([RFC5322]) and the Multipurpose Internet Mail Extensions (MIME
4629   [RFC2045]) to allow a message body to be transmitted in an open
4630   variety of representations and with extensible mechanisms.  However,
4631   RFC 2045 discusses mail, and HTTP has a few features that are
4632   different from those described in MIME.  These differences were
4633   carefully chosen to optimize performance over binary connections, to
4634   allow greater freedom in the use of new media types, to make date
4635   comparisons easier, and to acknowledge the practice of some early
4636   HTTP servers and clients.
4637
4638   This appendix describes specific areas where HTTP differs from MIME.
4639   Proxies and gateways to strict MIME environments SHOULD be aware of
4640   these differences and provide the appropriate conversions where
4641   necessary.  Proxies and gateways from MIME environments to HTTP also
4642   need to be aware of the differences because some conversions might be
4643   required.
4644
4645
4646
4647Fielding & Reschke        Expires April 7, 2013                [Page 83]
4648
4649Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
4650
4651
4652A.1.  MIME-Version
4653
4654   HTTP is not a MIME-compliant protocol.  However, HTTP/1.1 messages
4655   MAY include a single MIME-Version header field to indicate what
4656   version of the MIME protocol was used to construct the message.  Use
4657   of the MIME-Version header field indicates that the message is in
4658   full conformance with the MIME protocol (as defined in [RFC2045]).
4659   Proxies/gateways are responsible for ensuring full conformance (where
4660   possible) when exporting HTTP messages to strict MIME environments.
4661
4662     MIME-Version = 1*DIGIT "." 1*DIGIT
4663
4664   MIME version "1.0" is the default for use in HTTP/1.1.  However,
4665   HTTP/1.1 message parsing and semantics are defined by this document
4666   and not the MIME specification.
4667
4668A.2.  Conversion to Canonical Form
4669
4670   MIME requires that an Internet mail body-part be converted to
4671   canonical form prior to being transferred, as described in Section 4
4672   of [RFC2049].  Section 3.1.1.3 of this document describes the forms
4673   allowed for subtypes of the "text" media type when transmitted over
4674   HTTP.  [RFC2046] requires that content with a type of "text"
4675   represent line breaks as CRLF and forbids the use of CR or LF outside
4676   of line break sequences.  HTTP allows CRLF, bare CR, and bare LF to
4677   indicate a line break within text content when a message is
4678   transmitted over HTTP.
4679
4680   Where it is possible, a proxy or gateway from HTTP to a strict MIME
4681   environment SHOULD translate all line breaks within the text media
4682   types described in Section 3.1.1.3 of this document to the RFC 2049
4683   canonical form of CRLF.  Note, however, that this might be
4684   complicated by the presence of a Content-Encoding and by the fact
4685   that HTTP allows the use of some character encodings which do not use
4686   octets 13 and 10 to represent CR and LF, respectively, as is the case
4687   for some multi-byte character encodings.
4688
4689   Conversion will break any cryptographic checksums applied to the
4690   original content unless the original content is already in canonical
4691   form.  Therefore, the canonical form is recommended for any content
4692   that uses such checksums in HTTP.
4693
4694A.3.  Conversion of Date Formats
4695
4696   HTTP/1.1 uses a restricted set of date formats (Section 8.1.1.1) to
4697   simplify the process of date comparison.  Proxies and gateways from
4698   other protocols SHOULD ensure that any Date header field present in a
4699   message conforms to one of the HTTP/1.1 formats and rewrite the date
4700
4701
4702
4703Fielding & Reschke        Expires April 7, 2013                [Page 84]
4704
4705Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
4706
4707
4708   if necessary.
4709
4710A.4.  Introduction of Content-Encoding
4711
4712   MIME does not include any concept equivalent to HTTP/1.1's Content-
4713   Encoding header field.  Since this acts as a modifier on the media
4714   type, proxies and gateways from HTTP to MIME-compliant protocols MUST
4715   either change the value of the Content-Type header field or decode
4716   the representation before forwarding the message.  (Some experimental
4717   applications of Content-Type for Internet mail have used a media-type
4718   parameter of ";conversions=<content-coding>" to perform a function
4719   equivalent to Content-Encoding.  However, this parameter is not part
4720   of the MIME standards).
4721
4722A.5.  No Content-Transfer-Encoding
4723
4724   HTTP does not use the Content-Transfer-Encoding field of MIME.
4725   Proxies and gateways from MIME-compliant protocols to HTTP MUST
4726   remove any Content-Transfer-Encoding prior to delivering the response
4727   message to an HTTP client.
4728
4729   Proxies and gateways from HTTP to MIME-compliant protocols are
4730   responsible for ensuring that the message is in the correct format
4731   and encoding for safe transport on that protocol, where "safe
4732   transport" is defined by the limitations of the protocol being used.
4733   Such a proxy or gateway SHOULD label the data with an appropriate
4734   Content-Transfer-Encoding if doing so will improve the likelihood of
4735   safe transport over the destination protocol.
4736
4737A.6.  MHTML and Line Length Limitations
4738
4739   HTTP implementations which share code with MHTML [RFC2557]
4740   implementations need to be aware of MIME line length limitations.
4741   Since HTTP does not have this limitation, HTTP does not fold long
4742   lines.  MHTML messages being transported by HTTP follow all
4743   conventions of MHTML, including line length limitations and folding,
4744   canonicalization, etc., since HTTP transports all message-bodies as
4745   payload (see Section 3.1.1.4) and does not interpret the content or
4746   any MIME header lines that might be contained therein.
4747
4748Appendix B.  Additional Features
4749
4750   [RFC1945] and [RFC2068] document protocol elements used by some
4751   existing HTTP implementations, but not consistently and correctly
4752   across most HTTP/1.1 applications.  Implementers are advised to be
4753   aware of these features, but cannot rely upon their presence in, or
4754   interoperability with, other HTTP/1.1 applications.  Some of these
4755   describe proposed experimental features, and some describe features
4756
4757
4758
4759Fielding & Reschke        Expires April 7, 2013                [Page 85]
4760
4761Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
4762
4763
4764   that experimental deployment found lacking that are now addressed in
4765   the base HTTP/1.1 specification.
4766
4767   A number of other header fields, such as Content-Disposition and
4768   Title, from SMTP and MIME are also often implemented (see [RFC6266]
4769   and [RFC2076]).
4770
4771Appendix C.  Changes from RFC 2616
4772
4773   Remove base URI setting semantics for "Content-Location" due to poor
4774   implementation support, which was caused by too many broken servers
4775   emitting bogus Content-Location header fields, and also the
4776   potentially undesirable effect of potentially breaking relative links
4777   in content-negotiated resources.  (Section 3.1.4.2)
4778
4779   Clarify definition of POST.  (Section 5.3.3)
4780
4781   Remove requirement to handle all Content-* header fields; ban use of
4782   Content-Range with PUT.  (Section 5.3.4)
4783
4784   Take over definition of CONNECT method from [RFC2817].
4785   (Section 5.3.6)
4786
4787   Restrict "Max-Forwards" header field to OPTIONS and TRACE
4788   (previously, extension methods could have used it as well).
4789   (Section 6.1.1)
4790
4791   The ABNF for the "Expect" header field has been both fixed (allowing
4792   parameters for value-less expectations as well) and simplified
4793   (allowing trailing semicolons after "100-continue" when they were
4794   invalid before).  (Section 6.1.2)
4795
4796   Remove ISO-8859-1 special-casing in Accept-Charset.  (Section 6.3.3)
4797
4798   Allow "Referer" field value of "about:blank" as alternative to not
4799   specifying it.  (Section 6.5.2)
4800
4801   Broadened the definition of 203 (Non-Authoritative Information) to
4802   include cases of payload transformations as well.  (Section 7.3.4)
4803
4804   Status codes 301, 302, and 307: removed the normative requirements on
4805   both response payloads and user interaction.  (Section 7.4)
4806
4807   Failed to consider that there are many other request methods that are
4808   safe to automatically redirect, and further that the user agent is
4809   able to make that determination based on the request method
4810   semantics.  Furthermore, allow user agents to rewrite the method from
4811   POST to GET for status codes 301 and 302.  (Sections 7.4.2, 7.4.3 and
4812
4813
4814
4815Fielding & Reschke        Expires April 7, 2013                [Page 86]
4816
4817Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
4818
4819
4820   7.4.7)
4821
4822   Deprecate 305 (Use Proxy) status code, because user agents did not
4823   implement it.  It used to indicate that the target resource needs to
4824   be accessed through the proxy given by the Location field.  The
4825   Location field gave the URI of the proxy.  The recipient was expected
4826   to repeat this single request via the proxy.  (Section 7.4.5)
4827
4828   Define status 426 (Upgrade Required) (this was incorporated from
4829   [RFC2817]).  (Section 7.5.15)
4830
4831   Correct syntax of "Location" header field to allow URI references
4832   (including relative references and fragments), as referred symbol
4833   "absoluteURI" wasn't what was expected, and add some clarifications
4834   as to when use of fragments would not be appropriate.
4835   (Section 8.1.2)
4836
4837   Reclassify "Allow" as response header field, removing the option to
4838   specify it in a PUT request.  Relax the server requirement on the
4839   contents of the Allow header field and remove requirement on clients
4840   to always trust the header field value.  (Section 8.4.1)
4841
4842   In the description of the "Server" header field, the "Via" field was
4843   described as a SHOULD.  The requirement was and is stated correctly
4844   in the description of the Via header field in Section 5.7 of [Part1].
4845   (Section 8.4.2)
4846
4847   Clarify contexts that charset is used in.  (Section 3.1.1.2)
4848
4849   Remove the default character encoding of "ISO-8859-1" for text media
4850   types; the default now is whatever the media type definition says.
4851   (Section 3.1.1.3)
4852
4853   Registration of Content Codings now requires IETF Review
4854   (Section 9.4)
4855
4856   Remove definition of "Content-MD5 header" field because it was
4857   inconsistently implemented with respect to partial responses, and
4858   also because of known deficiencies in the hash algorithm itself (see
4859   [RFC6151] for details).
4860
4861   Introduce Method Registry.  (Section 9.1)
4862
4863   Take over the Status Code Registry, previously defined in Section 7.1
4864   of [RFC2817].  (Section 9.2)
4865
4866   Remove reference to non-existant identity transfer-coding value
4867   tokens.  (Appendix A.5)
4868
4869
4870
4871Fielding & Reschke        Expires April 7, 2013                [Page 87]
4872
4873Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
4874
4875
4876   Remove discussion of Content-Disposition header field, it is now
4877   defined by [RFC6266].  (Appendix B)
4878
4879Appendix D.  Imported ABNF
4880
4881   The following core rules are included by reference, as defined in
4882   Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return),
4883   CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double
4884   quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF
4885   (line feed), OCTET (any 8-bit sequence of data), SP (space), and
4886   VCHAR (any visible US-ASCII character).
4887
4888   The rules below are defined in [Part1]:
4889
4890     BWS           = <BWS, defined in [Part1], Section 3.2.1>
4891     OWS           = <OWS, defined in [Part1], Section 3.2.1>
4892     RWS           = <RWS, defined in [Part1], Section 3.2.1>
4893     URI-reference = <URI-reference, defined in [Part1], Section 2.7>
4894     absolute-URI  = <absolute-URI, defined in [Part1], Section 2.7>
4895     comment       = <comment, defined in [Part1], Section 3.2.4>
4896     field-name    = <comment, defined in [Part1], Section 3.2>
4897     partial-URI   = <partial-URI, defined in [Part1], Section 2.7>
4898     quoted-string = <quoted-string, defined in [Part1], Section 3.2.4>
4899     token         = <token, defined in [Part1], Section 3.2.4>
4900     word          = <word, defined in [Part1], Section 3.2.4>
4901
4902Appendix E.  Collected ABNF
4903
4904   Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
4905    OWS ( media-range [ accept-params ] ) ] ) ]
4906   Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS
4907    "," [ OWS ( ( charset / "*" ) [ weight ] ) ] )
4908   Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS
4909    ( codings [ weight ] ) ] ) ]
4910   Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS
4911    "," [ OWS ( language-range [ weight ] ) ] )
4912   Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ]
4913
4914   BWS = <BWS, defined in [Part1], Section 3.2.1>
4915
4916   Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS
4917    content-coding ] )
4918   Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS
4919    language-tag ] )
4920   Content-Location = absolute-URI / partial-URI
4921   Content-Type = media-type
4922
4923   Date = HTTP-date
4924
4925
4926
4927Fielding & Reschke        Expires April 7, 2013                [Page 88]
4928
4929Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
4930
4931
4932   Expect = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] )
4933
4934   From = mailbox
4935
4936   GMT = %x47.4D.54 ; GMT
4937
4938   HTTP-date = rfc1123-date / obs-date
4939
4940   Location = URI-reference
4941
4942   MIME-Version = 1*DIGIT "." 1*DIGIT
4943   Max-Forwards = 1*DIGIT
4944
4945   OWS = <OWS, defined in [Part1], Section 3.2.1>
4946
4947   RWS = <RWS, defined in [Part1], Section 3.2.1>
4948   Referer = absolute-URI / partial-URI
4949   Retry-After = HTTP-date / delta-seconds
4950
4951   Server = product *( RWS ( product / comment ) )
4952
4953   URI-reference = <URI-reference, defined in [Part1], Section 2.7>
4954   User-Agent = product *( RWS ( product / comment ) )
4955
4956   Vary = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name ]
4957    ) )
4958
4959   absolute-URI = <absolute-URI, defined in [Part1], Section 2.7>
4960   accept-ext = OWS ";" OWS token [ "=" word ]
4961   accept-params = weight *accept-ext
4962   asctime-date = day-name SP date3 SP time-of-day SP year
4963   attribute = token
4964
4965   charset = token
4966   codings = content-coding / "identity" / "*"
4967   comment = <comment, defined in [Part1], Section 3.2.4>
4968   content-coding = token
4969
4970   date1 = day SP month SP year
4971   date2 = day "-" month "-" 2DIGIT
4972   date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
4973   day = 2DIGIT
4974
4975
4976
4977
4978
4979
4980
4981
4982
4983Fielding & Reschke        Expires April 7, 2013                [Page 89]
4984
4985Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
4986
4987
4988   day-name = %x4D.6F.6E ; Mon
4989    / %x54.75.65 ; Tue
4990    / %x57.65.64 ; Wed
4991    / %x54.68.75 ; Thu
4992    / %x46.72.69 ; Fri
4993    / %x53.61.74 ; Sat
4994    / %x53.75.6E ; Sun
4995   day-name-l = %x4D.6F.6E.64.61.79 ; Monday
4996    / %x54.75.65.73.64.61.79 ; Tuesday
4997    / %x57.65.64.6E.65.73.64.61.79 ; Wednesday
4998    / %x54.68.75.72.73.64.61.79 ; Thursday
4999    / %x46.72.69.64.61.79 ; Friday
5000    / %x53.61.74.75.72.64.61.79 ; Saturday
5001    / %x53.75.6E.64.61.79 ; Sunday
5002   delta-seconds = 1*DIGIT
5003
5004   expect-name = token
5005   expect-param = expect-name [ BWS "=" BWS expect-value ]
5006   expect-value = token / quoted-string
5007   expectation = expect-name [ BWS "=" BWS expect-value ] *( OWS ";" [
5008    OWS expect-param ] )
5009
5010   field-name = <comment, defined in [Part1], Section 3.2>
5011
5012   hour = 2DIGIT
5013
5014   language-range = <language-range, defined in [RFC4647], Section 2.1>
5015   language-tag = <Language-Tag, defined in [RFC5646], Section 2.1>
5016
5017   mailbox = <mailbox, defined in [RFC5322], Section 3.4>
5018   media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS
5019    ";" OWS parameter )
5020   media-type = type "/" subtype *( OWS ";" OWS parameter )
5021   method = token
5022   minute = 2DIGIT
5023   month = %x4A.61.6E ; Jan
5024    / %x46.65.62 ; Feb
5025    / %x4D.61.72 ; Mar
5026    / %x41.70.72 ; Apr
5027    / %x4D.61.79 ; May
5028    / %x4A.75.6E ; Jun
5029    / %x4A.75.6C ; Jul
5030    / %x41.75.67 ; Aug
5031    / %x53.65.70 ; Sep
5032    / %x4F.63.74 ; Oct
5033    / %x4E.6F.76 ; Nov
5034    / %x44.65.63 ; Dec
5035
5036
5037
5038
5039Fielding & Reschke        Expires April 7, 2013                [Page 90]
5040
5041Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
5042
5043
5044   obs-date = rfc850-date / asctime-date
5045
5046   parameter = attribute "=" value
5047   partial-URI = <partial-URI, defined in [Part1], Section 2.7>
5048   product = token [ "/" product-version ]
5049   product-version = token
5050
5051   quoted-string = <quoted-string, defined in [Part1], Section 3.2.4>
5052   qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
5053
5054   rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT
5055   rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
5056
5057   second = 2DIGIT
5058   subtype = token
5059
5060   time-of-day = hour ":" minute ":" second
5061   token = <token, defined in [Part1], Section 3.2.4>
5062   type = token
5063
5064   value = word
5065
5066   weight = OWS ";" OWS "q=" qvalue
5067   word = <word, defined in [Part1], Section 3.2.4>
5068
5069   year = 4DIGIT
5070
5071Appendix F.  Change Log (to be removed by RFC Editor before publication)
5072
5073F.1.  Since RFC 2616
5074
5075   Extracted relevant partitions from [RFC2616].
5076
5077F.2.  Since draft-ietf-httpbis-p2-semantics-00
5078
5079   Closed issues:
5080
5081   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/5>: "Via is a MUST"
5082      (<http://purl.org/NET/http-errata#via-must>)
5083
5084   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/6>: "Fragments
5085      allowed in Location"
5086      (<http://purl.org/NET/http-errata#location-fragments>)
5087
5088   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/10>: "Safe Methods
5089      vs Redirection" (<http://purl.org/NET/http-errata#saferedirect>)
5090
5091
5092
5093
5094
5095Fielding & Reschke        Expires April 7, 2013                [Page 91]
5096
5097Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
5098
5099
5100   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/17>: "Revise
5101      description of the POST method"
5102      (<http://purl.org/NET/http-errata#post>)
5103
5104   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
5105      Informative references"
5106
5107   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/42>: "RFC2606
5108      Compliance"
5109
5110   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/65>: "Informative
5111      references"
5112
5113   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/84>: "Redundant
5114      cross-references"
5115
5116   Other changes:
5117
5118   o  Move definitions of 304 and 412 condition codes to [Part4]
5119
5120F.3.  Since draft-ietf-httpbis-p3-payload-00
5121
5122   Closed issues:
5123
5124   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/8>: "Media Type
5125      Registrations" (<http://purl.org/NET/http-errata#media-reg>)
5126
5127   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/14>: "Clarification
5128      regarding quoting of charset values"
5129      (<http://purl.org/NET/http-errata#charactersets>)
5130
5131   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/16>: "Remove
5132      'identity' token references"
5133      (<http://purl.org/NET/http-errata#identity>)
5134
5135   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/25>: "Accept-
5136      Encoding BNF"
5137
5138   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
5139      Informative references"
5140
5141   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/46>: "RFC1700
5142      references"
5143
5144   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating to
5145      RFC4288"
5146
5147
5148
5149
5150
5151Fielding & Reschke        Expires April 7, 2013                [Page 92]
5152
5153Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
5154
5155
5156   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/65>: "Informative
5157      references"
5158
5159   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/66>: "ISO-8859-1
5160      Reference"
5161
5162   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/68>: "Encoding
5163      References Normative"
5164
5165   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative up-
5166      to-date references"
5167
5168F.4.  Since draft-ietf-httpbis-p2-semantics-01
5169
5170   Closed issues:
5171
5172   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/21>: "PUT side
5173      effects"
5174
5175   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/91>: "Duplicate Host
5176      header requirements"
5177
5178   Ongoing work on ABNF conversion
5179   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
5180
5181   o  Move "Product Tokens" section (back) into Part 1, as "token" is
5182      used in the definition of the Upgrade header field.
5183
5184   o  Add explicit references to BNF syntax and rules imported from
5185      other parts of the specification.
5186
5187   o  Copy definition of delta-seconds from Part6 instead of referencing
5188      it.
5189
5190F.5.  Since draft-ietf-httpbis-p3-payload-01
5191
5192   Ongoing work on ABNF conversion
5193   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
5194
5195   o  Add explicit references to BNF syntax and rules imported from
5196      other parts of the specification.
5197
5198F.6.  Since draft-ietf-httpbis-p2-semantics-02
5199
5200   Closed issues:
5201
5202   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/24>: "Requiring
5203      Allow in 405 responses"
5204
5205
5206
5207Fielding & Reschke        Expires April 7, 2013                [Page 93]
5208
5209Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
5210
5211
5212   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/59>: "Status Code
5213      Registry"
5214
5215   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/61>: "Redirection
5216      vs. Location"
5217
5218   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/70>: "Cacheability
5219      of 303 response"
5220
5221   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/76>: "305 Use Proxy"
5222
5223   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/105>:
5224      "Classification for Allow header field"
5225
5226   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/112>: "PUT - 'store
5227      under' vs 'store at'"
5228
5229   Ongoing work on IANA Message Header Field Registration
5230   (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
5231
5232   o  Reference RFC 3984, and update header field registrations for
5233      header fields defined in this document.
5234
5235   Ongoing work on ABNF conversion
5236   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
5237
5238   o  Replace string literals when the string really is case-sensitive
5239      (method).
5240
5241F.7.  Since draft-ietf-httpbis-p3-payload-02
5242
5243   Closed issues:
5244
5245   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/67>: "Quoting
5246      Charsets"
5247
5248   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/105>:
5249      "Classification for Allow header field"
5250
5251   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/115>: "missing
5252      default for qvalue in description of Accept-Encoding"
5253
5254   Ongoing work on IANA Message Header Field Registration
5255   (<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
5256
5257   o  Reference RFC 3984, and update header field registrations for
5258      header fields defined in this document.
5259
5260
5261
5262
5263Fielding & Reschke        Expires April 7, 2013                [Page 94]
5264
5265Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
5266
5267
5268F.8.  Since draft-ietf-httpbis-p2-semantics-03
5269
5270   Closed issues:
5271
5272   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/98>: "OPTIONS
5273      payload bodies"
5274
5275   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/119>: "Description
5276      of CONNECT should refer to RFC2817"
5277
5278   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/125>: "Location
5279      Content-Location reference request/response mixup"
5280
5281   Ongoing work on Method Registry
5282   (<http://tools.ietf.org/wg/httpbis/trac/ticket/72>):
5283
5284   o  Added initial proposal for registration process, plus initial
5285      content (non-HTTP/1.1 methods to be added by a separate
5286      specification).
5287
5288F.9.  Since draft-ietf-httpbis-p3-payload-03
5289
5290   Closed issues:
5291
5292   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/67>: "Quoting
5293      Charsets"
5294
5295   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/113>: "language tag
5296      matching (Accept-Language) vs RFC4647"
5297
5298   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/121>: "RFC 1806 has
5299      been replaced by RFC2183"
5300
5301   Other changes:
5302
5303   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/68>: "Encoding
5304      References Normative" -- rephrase the annotation and reference
5305      BCP97.
5306
5307F.10.  Since draft-ietf-httpbis-p2-semantics-04
5308
5309   Closed issues:
5310
5311   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/103>: "Content-*"
5312
5313   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is
5314      updated by RFC 5322"
5315
5316
5317
5318
5319Fielding & Reschke        Expires April 7, 2013                [Page 95]
5320
5321Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
5322
5323
5324   Ongoing work on ABNF conversion
5325   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
5326
5327   o  Use "/" instead of "|" for alternatives.
5328
5329   o  Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
5330      whitespace ("OWS") and required whitespace ("RWS").
5331
5332   o  Rewrite ABNFs to spell out whitespace rules, factor out header
5333      field value format definitions.
5334
5335F.11.  Since draft-ietf-httpbis-p3-payload-04
5336
5337   Closed issues:
5338
5339   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/132>: "RFC 2822 is
5340      updated by RFC 5322"
5341
5342   Ongoing work on ABNF conversion
5343   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
5344
5345   o  Use "/" instead of "|" for alternatives.
5346
5347   o  Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
5348      whitespace ("OWS") and required whitespace ("RWS").
5349
5350   o  Rewrite ABNFs to spell out whitespace rules, factor out header
5351      field value format definitions.
5352
5353F.12.  Since draft-ietf-httpbis-p2-semantics-05
5354
5355   Closed issues:
5356
5357   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/94>: "reason-phrase
5358      BNF"
5359
5360   Final work on ABNF conversion
5361   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
5362
5363   o  Add appendix containing collected and expanded ABNF, reorganize
5364      ABNF introduction.
5365
5366F.13.  Since draft-ietf-httpbis-p3-payload-05
5367
5368   Closed issues:
5369
5370   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/118>: "Join
5371      "Differences Between HTTP Entities and RFC 2045 Entities"?"
5372
5373
5374
5375Fielding & Reschke        Expires April 7, 2013                [Page 96]
5376
5377Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
5378
5379
5380   Final work on ABNF conversion
5381   (<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
5382
5383   o  Add appendix containing collected and expanded ABNF, reorganize
5384      ABNF introduction.
5385
5386   Other changes:
5387
5388   o  Move definition of quality values into Part 1.
5389
5390F.14.  Since draft-ietf-httpbis-p2-semantics-06
5391
5392   Closed issues:
5393
5394   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/144>: "Clarify when
5395      Referer is sent"
5396
5397   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/164>: "status codes
5398      vs methods"
5399
5400   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/170>: "Do not
5401      require "updates" relation for specs that register status codes or
5402      method names"
5403
5404F.15.  Since draft-ietf-httpbis-p3-payload-06
5405
5406   Closed issues:
5407
5408   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/80>: "Content-
5409      Location isn't special"
5410
5411   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/155>: "Content
5412      Sniffing"
5413
5414F.16.  Since draft-ietf-httpbis-p2-semantics-07
5415
5416   Closed issues:
5417
5418   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/27>: "Idempotency"
5419
5420   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/33>: "TRACE security
5421      considerations"
5422
5423   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/110>: "Clarify rules
5424      for determining what entities a response carries"
5425
5426   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/140>: "update note
5427      citing RFC 1945 and 2068"
5428
5429
5430
5431Fielding & Reschke        Expires April 7, 2013                [Page 97]
5432
5433Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
5434
5435
5436   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/182>: "update note
5437      about redirect limit"
5438
5439   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/191>: "Location
5440      header field ABNF should use 'URI'"
5441
5442   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/192>: "fragments in
5443      Location vs status 303"
5444
5445   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA
5446      registrations for optional status codes"
5447
5448   Partly resolved issues:
5449
5450   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/171>: "Are OPTIONS
5451      and TRACE safe?"
5452
5453F.17.  Since draft-ietf-httpbis-p3-payload-07
5454
5455   Closed issues:
5456
5457   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/13>: "Updated
5458      reference for language tags"
5459
5460   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/110>: "Clarify rules
5461      for determining what entities a response carries"
5462
5463   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/154>: "Content-
5464      Location base-setting problems"
5465
5466   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/155>: "Content
5467      Sniffing"
5468
5469   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/188>: "pick IANA
5470      policy (RFC5226) for Transfer Coding / Content Coding"
5471
5472   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/189>: "move
5473      definitions of gzip/deflate/compress to part 1"
5474
5475   Partly resolved issues:
5476
5477   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/148>: "update IANA
5478      requirements wrt Transfer-Coding values" (add the IANA
5479      Considerations subsection)
5480
5481   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/149>: "update IANA
5482      requirements wrt Content-Coding values" (add the IANA
5483      Considerations subsection)
5484
5485
5486
5487Fielding & Reschke        Expires April 7, 2013                [Page 98]
5488
5489Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
5490
5491
5492F.18.  Since draft-ietf-httpbis-p2-semantics-08
5493
5494   Closed issues:
5495
5496   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/10>: "Safe Methods
5497      vs Redirection" (we missed the introduction to the 3xx status
5498      codes when fixing this previously)
5499
5500F.19.  Since draft-ietf-httpbis-p3-payload-08
5501
5502   Closed issues:
5503
5504   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/81>: "Content
5505      Negotiation for media types"
5506
5507   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/181>: "Accept-
5508      Language: which RFC4647 filtering?"
5509
5510F.20.  Since draft-ietf-httpbis-p2-semantics-09
5511
5512   Closed issues:
5513
5514   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/43>: "Fragment
5515      combination / precedence during redirects"
5516
5517   Partly resolved issues:
5518
5519   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/185>: "Location
5520      header field payload handling"
5521
5522   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the
5523      requested resource's URI"
5524
5525F.21.  Since draft-ietf-httpbis-p3-payload-09
5526
5527   Closed issues:
5528
5529   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/122>: "MIME-Version
5530      not listed in P1, general header fields"
5531
5532   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/143>: "IANA registry
5533      for content/transfer encodings"
5534
5535   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/155>: "Content
5536      Sniffing"
5537
5538   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/200>: "use of term
5539      "word" when talking about header field structure"
5540
5541
5542
5543Fielding & Reschke        Expires April 7, 2013                [Page 99]
5544
5545Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
5546
5547
5548   Partly resolved issues:
5549
5550   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/196>: "Term for the
5551      requested resource's URI"
5552
5553F.22.  Since draft-ietf-httpbis-p2-semantics-10
5554
5555   Closed issues:
5556
5557   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/69>: "Clarify
5558      'Requested Variant'"
5559
5560   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify
5561      entity / representation / variant terminology"
5562
5563   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/139>: "Methods and
5564      Caching"
5565
5566   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/190>: "OPTIONS vs
5567      Max-Forwards"
5568
5569   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/199>: "Status codes
5570      and caching"
5571
5572   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider
5573      removing the 'changes from 2068' sections"
5574
5575F.23.  Since draft-ietf-httpbis-p3-payload-10
5576
5577   Closed issues:
5578
5579   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/69>: "Clarify
5580      'Requested Variant'"
5581
5582   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/80>: "Content-
5583      Location isn't special"
5584
5585   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/90>: "Delimiting
5586      messages with multipart/byteranges"
5587
5588   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/109>: "Clarify
5589      entity / representation / variant terminology"
5590
5591   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/136>: "confusing
5592      req. language for Content-Location"
5593
5594   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/167>: "Content-
5595      Location on 304 responses"
5596
5597
5598
5599Fielding & Reschke        Expires April 7, 2013               [Page 100]
5600
5601Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
5602
5603
5604   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/183>: "'requested
5605      resource' in content-encoding definition"
5606
5607   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/220>: "consider
5608      removing the 'changes from 2068' sections"
5609
5610   Partly resolved issues:
5611
5612   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/178>: "Content-MD5
5613      and partial responses"
5614
5615F.24.  Since draft-ietf-httpbis-p2-semantics-11
5616
5617   Closed issues:
5618
5619   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/229>:
5620      "Considerations for new status codes"
5621
5622   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/230>:
5623      "Considerations for new methods"
5624
5625   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/232>: "User-Agent
5626      guidelines" (relating to the 'User-Agent' header field)
5627
5628F.25.  Since draft-ietf-httpbis-p3-payload-11
5629
5630   Closed issues:
5631
5632   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/123>: "Factor out
5633      Content-Disposition"
5634
5635F.26.  Since draft-ietf-httpbis-p2-semantics-12
5636
5637   Closed issues:
5638
5639   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/43>: "Fragment
5640      combination / precedence during redirects" (added warning about
5641      having a fragid on the redirect might cause inconvenience in some
5642      cases)
5643
5644   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/79>: "Content-* vs.
5645      PUT"
5646
5647   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/88>: "205 Bodies"
5648
5649   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/102>: "Understanding
5650      Content-* on non-PUT requests"
5651
5652
5653
5654
5655Fielding & Reschke        Expires April 7, 2013               [Page 101]
5656
5657Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
5658
5659
5660   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/103>: "Content-*"
5661
5662   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/104>: "Header field
5663      type defaulting"
5664
5665   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/112>: "PUT - 'store
5666      under' vs 'store at'"
5667
5668   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/137>: "duplicate
5669      ABNF for reason-phrase"
5670
5671   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/180>: "Note special
5672      status of Content-* prefix in header field registration
5673      procedures"
5674
5675   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/203>: "Max-Forwards
5676      vs extension methods"
5677
5678   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/213>: "What is the
5679      value space of HTTP status codes?" (actually fixed in
5680      draft-ietf-httpbis-p2-semantics-11)
5681
5682   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header Field
5683      Classification"
5684
5685   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/225>: "PUT side
5686      effect: invalidation or just stale?"
5687
5688   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/226>: "proxies not
5689      supporting certain methods"
5690
5691   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/239>: "Migrate
5692      CONNECT from RFC2817 to p2"
5693
5694   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/240>: "Migrate
5695      Upgrade details from RFC2817"
5696
5697   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/267>: "clarify PUT
5698      semantics'"
5699
5700   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/275>: "duplicate
5701      ABNF for 'Method'"
5702
5703   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
5704      ABNFs for header fields"
5705
5706
5707
5708
5709
5710
5711Fielding & Reschke        Expires April 7, 2013               [Page 102]
5712
5713Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
5714
5715
5716F.27.  Since draft-ietf-httpbis-p3-payload-12
5717
5718   Closed issues:
5719
5720   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/224>: "Header Field
5721      Classification"
5722
5723   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
5724      ABNFs for header fields"
5725
5726   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/277>: "potentially
5727      misleading MAY in media-type def"
5728
5729F.28.  Since draft-ietf-httpbis-p2-semantics-13
5730
5731   Closed issues:
5732
5733   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
5734      ABNFs for header fields"
5735
5736   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/251>: "message body
5737      in CONNECT request"
5738
5739F.29.  Since draft-ietf-httpbis-p3-payload-13
5740
5741   Closed issues:
5742
5743   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/20>: "Default
5744      charsets for text media types"
5745
5746   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/178>: "Content-MD5
5747      and partial responses"
5748
5749   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/276>: "untangle
5750      ABNFs for header fields"
5751
5752   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/281>: "confusing
5753      undefined parameter in media range example"
5754
5755F.30.  Since draft-ietf-httpbis-p2-semantics-14
5756
5757   Closed issues:
5758
5759   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/255>: "Clarify
5760      status code for rate limiting"
5761
5762   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/294>: "clarify 403
5763      forbidden"
5764
5765
5766
5767Fielding & Reschke        Expires April 7, 2013               [Page 103]
5768
5769Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
5770
5771
5772   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/296>: "Clarify 203
5773      Non-Authoritative Information"
5774
5775   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/298>: "update
5776      default reason phrase for 413"
5777
5778F.31.  Since draft-ietf-httpbis-p3-payload-14
5779
5780   None.
5781
5782F.32.  Since draft-ietf-httpbis-p2-semantics-15
5783
5784   Closed issues:
5785
5786   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/285>: "Strength of
5787      requirements on Accept re: 406"
5788
5789   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/303>: "400 response
5790      isn't generic"
5791
5792F.33.  Since draft-ietf-httpbis-p3-payload-15
5793
5794   Closed issues:
5795
5796   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/285>: "Strength of
5797      requirements on Accept re: 406"
5798
5799F.34.  Since draft-ietf-httpbis-p2-semantics-16
5800
5801   Closed issues:
5802
5803   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/160>: "Redirects and
5804      non-GET methods"
5805
5806   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document
5807      HTTP's error-handling philosophy"
5808
5809   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/231>:
5810      "Considerations for new header fields"
5811
5812   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/310>: "clarify 303
5813      redirect on HEAD"
5814
5815F.35.  Since draft-ietf-httpbis-p3-payload-16
5816
5817   Closed issues:
5818
5819
5820
5821
5822
5823Fielding & Reschke        Expires April 7, 2013               [Page 104]
5824
5825Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
5826
5827
5828   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document
5829      HTTP's error-handling philosophy"
5830
5831F.36.  Since draft-ietf-httpbis-p2-semantics-17
5832
5833   Closed issues:
5834
5835   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/185>: "Location
5836      header field payload handling"
5837
5838   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/255>: "Clarify
5839      status code for rate limiting" (change backed out because a new
5840      status code is being defined for this purpose)
5841
5842   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/312>: "should there
5843      be a permanent variant of 307"
5844
5845   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/325>: "When are
5846      Location's semantics triggered?"
5847
5848   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/327>: "'expect'
5849      grammar missing OWS"
5850
5851   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/329>: "header field
5852      considerations: quoted-string vs use of double quotes"
5853
5854F.37.  Since draft-ietf-httpbis-p3-payload-17
5855
5856   Closed issues:
5857
5858   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/323>: "intended
5859      maturity level vs normative references"
5860
5861F.38.  Since draft-ietf-httpbis-p2-semantics-18
5862
5863   Closed issues:
5864
5865   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/227>: "Combining
5866      HEAD responses"
5867
5868   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/238>: "Requirements
5869      for user intervention during redirects"
5870
5871   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/250>: "message-body
5872      in CONNECT response"
5873
5874   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/295>: "Applying
5875      original fragment to 'plain' redirected URI"
5876
5877
5878
5879Fielding & Reschke        Expires April 7, 2013               [Page 105]
5880
5881Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
5882
5883
5884   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/302>: "Misplaced
5885      text on connection handling in p2"
5886
5887   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/331>: "clarify that
5888      201 doesn't require Location header fields"
5889
5890   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/332>: "relax
5891      requirements on hypertext in 3/4/5xx error responses"
5892
5893   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/333>: "example for
5894      426 response should have a payload"
5895
5896   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/336>: "drop
5897      indirection entries for status codes"
5898
5899F.39.  Since draft-ietf-httpbis-p3-payload-18
5900
5901   Closed issues:
5902
5903   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/330>: "is ETag a
5904      representation header field?"
5905
5906   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/338>: "Content-
5907      Location doesn't constrain the cardinality of representations"
5908
5909   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/346>: "make IANA
5910      policy definitions consistent"
5911
5912F.40.  Since draft-ietf-httpbis-p2-semantics-19 and
5913       draft-ietf-httpbis-p3-payload-19
5914
5915   Closed issues:
5916
5917   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/312>: "should there
5918      be a permanent variant of 307"
5919
5920   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/347>: "clarify that
5921      201 can imply *multiple* resources were created"
5922
5923   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/351>: "merge P2 and
5924      P3"
5925
5926   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/361>: "ABNF
5927      requirements for recipients"
5928
5929   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/364>: "Capturing
5930      more information in the method registry"
5931
5932
5933
5934
5935Fielding & Reschke        Expires April 7, 2013               [Page 106]
5936
5937Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
5938
5939
5940   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/368>: "note
5941      introduction of new IANA registries as normative changes"
5942
5943F.41.  Since draft-ietf-httpbis-p2-semantics-20
5944
5945   Closed issues:
5946
5947   o  <http://tools.ietf.org/wg/httpbis/trac/ticket/378>: "is 'q=' case-
5948      sensitive?"
5949
5950   Other changes:
5951
5952   o  Conformance criteria and considerations regarding error handling
5953      are now defined in Part 1.
5954
5955   o  Properly explain what HTTP semantics are and why.  Rewrite
5956      introductory description of methods.  Rewrite definition of "safe"
5957      to be more operable and weaken the original same-origin
5958      restrictions to be more consistent with modern UAs.  Rewrite
5959      definition of "idempotent", add definition of "cacheable".
5960
5961   o  Conneg terminology change: "server-driven" => "proactive" (UA
5962      sends Accept* fields), "agent-driven" => "reactive" (UA waits for
5963      300/Alternatives)
5964
5965   o  Move description of "100-continue" from Part 1 over here.
5966
5967   o  Move definition of "Vary" header field from Part 6 over here.
5968
5969   o  Rewrite definition of "representation".
5970
5971Index
5972
5973   1
5974      1xx Informational (status code class)  49
5975
5976   2
5977      2xx Successful (status code class)  50
5978
5979   3
5980      3xx Redirection (status code class)  52
5981
5982   4
5983      4xx Client Error (status code class)  56
5984
5985   5
5986      5xx Server Error (status code class)  60
5987
5988
5989
5990
5991Fielding & Reschke        Expires April 7, 2013               [Page 107]
5992
5993Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
5994
5995
5996   1
5997      100 Continue (status code)  49
5998      100-continue (expect value)  35
5999      101 Switching Protocols (status code)  49
6000
6001   2
6002      200 OK (status code)  50
6003      201 Created (status code)  50
6004      202 Accepted (status code)  51
6005      203 Non-Authoritative Information (status code)  51
6006      204 No Content (status code)  51
6007      205 Reset Content (status code)  52
6008
6009   3
6010      300 Multiple Choices (status code)  54
6011      301 Moved Permanently (status code)  54
6012      302 Found (status code)  55
6013      303 See Other (status code)  55
6014      305 Use Proxy (status code)  56
6015      306 (Unused) (status code)  56
6016      307 Temporary Redirect (status code)  56
6017
6018   4
6019      400 Bad Request (status code)  56
6020      402 Payment Required (status code)  56
6021      403 Forbidden (status code)  57
6022      404 Not Found (status code)  57
6023      405 Method Not Allowed (status code)  57
6024      406 Not Acceptable (status code)  57
6025      408 Request Timeout (status code)  58
6026      409 Conflict (status code)  58
6027      410 Gone (status code)  58
6028      411 Length Required (status code)  59
6029      413 Request Representation Too Large (status code)  59
6030      414 URI Too Long (status code)  59
6031      415 Unsupported Media Type (status code)  59
6032      417 Expectation Failed (status code)  60
6033      426 Upgrade Required (status code)  60
6034
6035   5
6036      500 Internal Server Error (status code)  60
6037      501 Not Implemented (status code)  60
6038      502 Bad Gateway (status code)  61
6039      503 Service Unavailable (status code)  61
6040      504 Gateway Timeout (status code)  61
6041      505 HTTP Version Not Supported (status code)  61
6042
6043   A
6044
6045
6046
6047Fielding & Reschke        Expires April 7, 2013               [Page 108]
6048
6049Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
6050
6051
6052      Accept header field  38
6053      Accept-Charset header field  41
6054      Accept-Encoding header field  41
6055      Accept-Language header field  42
6056      Allow header field  69
6057
6058   C
6059      cacheable  25
6060      compress (content coding)  12
6061      CONNECT method  30
6062      content coding  12
6063      content negotiation  7
6064      Content-Encoding header field  12
6065      Content-Language header field  14
6066      Content-Location header field  16
6067      Content-Transfer-Encoding header field  85
6068      Content-Type header field  11
6069
6070   D
6071      Date header field  64
6072      deflate (content coding)  12
6073      DELETE method  30
6074
6075   E
6076      Expect header field  34
6077      Expect Values
6078         100-continue  35
6079
6080   F
6081      From header field  44
6082
6083   G
6084      GET method  25
6085      Grammar
6086         Accept  39
6087         Accept-Charset  41
6088         Accept-Encoding  41
6089         accept-ext  39
6090         Accept-Language  43
6091         accept-params  39
6092         Allow  69
6093         asctime-date  64
6094         attribute  9
6095         charset  10
6096         codings  41
6097         content-coding  12
6098         Content-Encoding  13
6099         Content-Language  14
6100
6101
6102
6103Fielding & Reschke        Expires April 7, 2013               [Page 109]
6104
6105Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
6106
6107
6108         Content-Location  16
6109         Content-Type  11
6110         Date  64
6111         date1  63
6112         day  63
6113         day-name  63
6114         day-name-l  63
6115         delta-seconds  66
6116         Expect  34
6117         expect-name  34
6118         expect-param  34
6119         expect-value  34
6120         expectation  34
6121         From  44
6122         GMT  63
6123         hour  63
6124         HTTP-date  62
6125         language-range  43
6126         language-tag  14
6127         Location  65
6128         Max-Forwards  34
6129         media-range  39
6130         media-type  9
6131         method  22
6132         MIME-Version  84
6133         minute  63
6134         month  63
6135         obs-date  63
6136         parameter  9
6137         product  22
6138         product-version  22
6139         qvalue  38
6140         Referer  45
6141         Retry-After  66
6142         rfc850-date  64
6143         rfc1123-date  63
6144         second  63
6145         Server  69
6146         subtype  9
6147         time-of-day  63
6148         type  9
6149         User-Agent  46
6150         value  9
6151         Vary  67
6152         weight  38
6153         year  63
6154      gzip (content coding)  12
6155
6156
6157
6158
6159Fielding & Reschke        Expires April 7, 2013               [Page 110]
6160
6161Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
6162
6163
6164   H
6165      HEAD method  26
6166
6167   I
6168      idempotent  25
6169
6170   L
6171      Location header field  65
6172
6173   M
6174      Max-Forwards header field  34
6175      MIME-Version header field  84
6176
6177   O
6178      OPTIONS method  32
6179
6180   P
6181      payload  18
6182      POST method  27
6183      PUT method  28
6184
6185   R
6186      Referer header field  45
6187      representation  8
6188      Retry-After header field  66
6189
6190   S
6191      safe  24
6192      selected representation  67
6193      Server header field  69
6194      Status Codes Classes
6195         1xx Informational  49
6196         2xx Successful  50
6197         3xx Redirection  52
6198         4xx Client Error  56
6199         5xx Server Error  60
6200
6201   T
6202      TRACE method  33
6203
6204   U
6205      User-Agent header field  45
6206
6207   V
6208      Vary header field  67
6209
6210   X
6211      x-compress (content coding)  12
6212
6213
6214
6215Fielding & Reschke        Expires April 7, 2013               [Page 111]
6216
6217Internet-Draft       HTTP/1.1 Semantics and Content         October 2012
6218
6219
6220      x-gzip (content coding)  12
6221
6222Authors' Addresses
6223
6224   Roy T. Fielding (editor)
6225   Adobe Systems Incorporated
6226   345 Park Ave
6227   San Jose, CA  95110
6228   USA
6229
6230   EMail: fielding@gbiv.com
6231   URI:   http://roy.gbiv.com/
6232
6233
6234   Julian F. Reschke (editor)
6235   greenbytes GmbH
6236   Hafenweg 16
6237   Muenster, NW  48155
6238   Germany
6239
6240   EMail: julian.reschke@greenbytes.de
6241   URI:   http://greenbytes.de/tech/webdav/
6242
6243
6244
6245
6246
6247
6248
6249
6250
6251
6252
6253
6254
6255
6256
6257
6258
6259
6260
6261
6262
6263
6264
6265
6266
6267
6268
6269
6270
6271Fielding & Reschke        Expires April 7, 2013               [Page 112]
6272
Note: See TracBrowser for help on using the repository browser.