source: draft-ietf-httpbis/20/draft-ietf-httpbis-p2-semantics-20.txt

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

Prepare release of -20 drafts

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