source: draft-ietf-httpbis/16/draft-ietf-httpbis-p2-semantics-16.xml @ 1500

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

fix mime types

  • Property svn:eol-style set to native
  • Property svn:mime-type set to text/xml
File size: 156.0 KB
Line 
1<?xml version="1.0" encoding="UTF-8"?>
2<!--
3    This XML document is the output of clean-for-DTD.xslt; a tool that strips
4    extensions to RFC2629(bis) from documents for processing with xml2rfc.
5-->
6<?xml-stylesheet type='text/xsl' href='../myxml2rfc.xslt'?>
7<?rfc toc="yes" ?>
8<?rfc symrefs="yes" ?>
9<?rfc sortrefs="yes" ?>
10<?rfc compact="yes"?>
11<?rfc subcompact="no" ?>
12<?rfc linkmailto="no" ?>
13<?rfc editing="no" ?>
14<?rfc comments="yes"?>
15<?rfc inline="yes"?>
16<?rfc rfcedstyle="yes"?>
17<!DOCTYPE rfc
18  PUBLIC "" "rfc2629.dtd">
19<rfc obsoletes="2616" updates="2817" category="std" ipr="pre5378Trust200902" docName="draft-ietf-httpbis-p2-semantics-16">
20<front>
21
22  <title abbrev="HTTP/1.1, Part 2">HTTP/1.1, part 2: Message Semantics</title>
23
24  <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
25    <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
26    <address>
27      <postal>
28        <street>345 Park Ave</street>
29        <city>San Jose</city>
30        <region>CA</region>
31        <code>95110</code>
32        <country>USA</country>
33      </postal>
34      <email>fielding@gbiv.com</email>
35      <uri>http://roy.gbiv.com/</uri>
36    </address>
37  </author>
38
39  <author initials="J." surname="Gettys" fullname="Jim Gettys">
40    <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization>
41    <address>
42      <postal>
43        <street>21 Oak Knoll Road</street>
44        <city>Carlisle</city>
45        <region>MA</region>
46        <code>01741</code>
47        <country>USA</country>
48      </postal>
49      <email>jg@freedesktop.org</email>
50      <uri>http://gettys.wordpress.com/</uri>
51    </address>
52  </author>
53 
54  <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
55    <organization abbrev="HP">Hewlett-Packard Company</organization>
56    <address>
57      <postal>
58        <street>HP Labs, Large Scale Systems Group</street>
59        <street>1501 Page Mill Road, MS 1177</street>
60        <city>Palo Alto</city>
61        <region>CA</region>
62        <code>94304</code>
63        <country>USA</country>
64      </postal>
65      <email>JeffMogul@acm.org</email>
66    </address>
67  </author>
68
69  <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
70    <organization abbrev="Microsoft">Microsoft Corporation</organization>
71    <address>
72      <postal>
73        <street>1 Microsoft Way</street>
74        <city>Redmond</city>
75        <region>WA</region>
76        <code>98052</code>
77        <country>USA</country>
78      </postal>
79      <email>henrikn@microsoft.com</email>
80    </address>
81  </author>
82
83  <author initials="L." surname="Masinter" fullname="Larry Masinter">
84    <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
85    <address>
86      <postal>
87        <street>345 Park Ave</street>
88        <city>San Jose</city>
89        <region>CA</region>
90        <code>95110</code>
91        <country>USA</country>
92      </postal>
93      <email>LMM@acm.org</email>
94      <uri>http://larry.masinter.net/</uri>
95    </address>
96  </author>
97 
98  <author initials="P." surname="Leach" fullname="Paul J. Leach">
99    <organization abbrev="Microsoft">Microsoft Corporation</organization>
100    <address>
101      <postal>
102        <street>1 Microsoft Way</street>
103        <city>Redmond</city>
104        <region>WA</region>
105        <code>98052</code>
106      </postal>
107      <email>paulle@microsoft.com</email>
108    </address>
109  </author>
110   
111  <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
112    <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
113    <address>
114      <postal>
115        <street>MIT Computer Science and Artificial Intelligence Laboratory</street>
116        <street>The Stata Center, Building 32</street>
117        <street>32 Vassar Street</street>
118        <city>Cambridge</city>
119        <region>MA</region>
120        <code>02139</code>
121        <country>USA</country>
122      </postal>
123      <email>timbl@w3.org</email>
124      <uri>http://www.w3.org/People/Berners-Lee/</uri>
125    </address>
126  </author>
127
128  <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
129    <organization abbrev="W3C">World Wide Web Consortium</organization>
130    <address>
131      <postal>
132        <street>W3C / ERCIM</street>
133        <street>2004, rte des Lucioles</street>
134        <city>Sophia-Antipolis</city>
135        <region>AM</region>
136        <code>06902</code>
137        <country>France</country>
138      </postal>
139      <email>ylafon@w3.org</email>
140      <uri>http://www.raubacapeu.net/people/yves/</uri>
141    </address>
142  </author>
143
144  <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
145    <organization abbrev="greenbytes">greenbytes GmbH</organization>
146    <address>
147      <postal>
148        <street>Hafenweg 16</street>
149        <city>Muenster</city><region>NW</region><code>48155</code>
150        <country>Germany</country>
151      </postal>
152      <phone>+49 251 2807760</phone>
153      <facsimile>+49 251 2807761</facsimile>
154      <email>julian.reschke@greenbytes.de</email>
155      <uri>http://greenbytes.de/tech/webdav/</uri>
156    </address>
157  </author>
158
159  <date month="August" year="2011" day="24"/>
160  <workgroup>HTTPbis Working Group</workgroup>
161
162<abstract>
163<t>
164   The Hypertext Transfer Protocol (HTTP) is an application-level protocol for
165   distributed, collaborative, hypertext information systems. HTTP has been in
166   use by the World Wide Web global information initiative since 1990. This
167   document is Part 2 of the seven-part specification that defines the protocol
168   referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616.
169</t>
170<t>
171   Part 2 defines the semantics of HTTP messages as expressed by request
172   methods, request header fields, response status codes, and response header
173   fields.
174</t>
175</abstract>
176
177<note title="Editorial Note (To be removed by RFC Editor)">
178  <t>
179    Discussion of this draft should take place on the HTTPBIS working group
180    mailing list (ietf-http-wg@w3.org), which is archived at
181    <eref target="http://lists.w3.org/Archives/Public/ietf-http-wg/"/>.
182  </t>
183  <t>
184    The current issues list is at
185    <eref target="http://tools.ietf.org/wg/httpbis/trac/report/3"/> and related
186    documents (including fancy diffs) can be found at
187    <eref target="http://tools.ietf.org/wg/httpbis/"/>.
188  </t>
189  <t>
190    The changes in this draft are summarized in <xref target="changes.since.15"/>.
191  </t>
192</note>
193</front>
194<middle>
195<section title="Introduction" anchor="introduction">
196<t>
197   This document defines HTTP/1.1 request and response semantics.  Each HTTP
198   message, as defined in <xref target="Part1"/>, is in the form of either a request or
199   a response.  An HTTP server listens on a connection for HTTP requests and
200   responds to each request, in the order received on that connection, with
201   one or more HTTP response messages.  This document defines the commonly
202   agreed upon semantics of the HTTP uniform interface, the intentions defined
203   by each request method, and the various response messages that might be
204   expected as a result of applying that method to the target resource.
205</t>
206<t>
207   This document is currently disorganized in order to minimize the changes
208   between drafts and enable reviewers to see the smaller errata changes.
209   A future draft will reorganize the sections to better reflect the content.
210   In particular, the sections will be ordered according to the typical
211   processing of an HTTP request message (after message parsing): resource
212   mapping, methods, request modifying header fields, response status,
213   status modifying header fields, and resource metadata.  The current mess
214   reflects how widely dispersed these topics and associated requirements
215   had become in <xref target="RFC2616"/>.
216</t>
217
218<section title="Requirements" anchor="intro.requirements">
219<t>
220   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
221   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
222   document are to be interpreted as described in <xref target="RFC2119"/>.
223</t>
224<t>
225   An implementation is not compliant if it fails to satisfy one or more
226   of the "MUST" or "REQUIRED" level requirements for the protocols it
227   implements. An implementation that satisfies all the "MUST" or "REQUIRED"
228   level and all the "SHOULD" level requirements for its protocols is said
229   to be "unconditionally compliant"; one that satisfies all the "MUST"
230   level requirements but not all the "SHOULD" level requirements for its
231   protocols is said to be "conditionally compliant".
232</t>
233</section>
234
235<section title="Syntax Notation" anchor="notation">
236 
237 
238 
239 
240 
241<t>
242  This specification uses the ABNF syntax defined in Section 1.2 of <xref target="Part1"/> (which
243  extends the syntax defined in <xref target="RFC5234"/> with a list rule).
244  <xref target="collected.abnf"/> shows the collected ABNF, with the list
245  rule expanded.
246</t>
247<t>
248  The following core rules are included by
249  reference, as defined in <xref target="RFC5234"/>, Appendix B.1:
250  ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls),
251  DIGIT (decimal 0-9), DQUOTE (double quote),
252  HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed),
253  OCTET (any 8-bit sequence of data), SP (space),
254  VCHAR (any visible USASCII character),
255  and WSP (whitespace).
256</t>
257
258<section title="Core Rules" anchor="core.rules">
259 
260 
261 
262 
263 
264<t>
265  The core rules below are defined in <xref target="Part1"/>:
266</t>
267<figure><artwork type="abnf2616"><![CDATA[
268  OWS           = <OWS, defined in [Part1], Section 1.2.2>
269  RWS           = <RWS, defined in [Part1], Section 1.2.2>
270  obs-text      = <obs-text, defined in [Part1], Section 1.2.2>
271  quoted-string = <quoted-string, defined in [Part1], Section 3.2.3>
272  token         = <token, defined in [Part1], Section 3.2.3>
273]]></artwork></figure>
274</section>
275
276<section title="ABNF Rules defined in other Parts of the Specification" anchor="abnf.dependencies">
277 
278 
279 
280 
281 
282 
283<t>
284  The ABNF rules below are defined in other parts:
285</t>
286<figure><artwork type="abnf2616"><![CDATA[
287  absolute-URI  = <absolute-URI, defined in [Part1], Section 2.7>
288  comment       = <comment, defined in [Part1], Section 3.2>
289  HTTP-date     = <HTTP-date, defined in [Part1], Section 6.1>
290  partial-URI   = <partial-URI, defined in [Part1], Section 2.7>
291  product       = <product, defined in [Part1], Section 6.3>
292  URI-reference = <URI-reference, defined in [Part1], Section 2.7>
293]]></artwork></figure>
294</section>
295</section>
296</section>
297
298<section title="Method" anchor="method">
299 
300 
301<t>
302   The Method token indicates the request method to be performed on the target
303   resource (Section 4.3 of <xref target="Part1"/>). The method is case-sensitive.
304</t>
305<figure><iref primary="true" item="Grammar" subitem="Method"/><artwork type="abnf2616"><![CDATA[
306  Method         = token
307]]></artwork></figure>
308<t>
309   The list of methods allowed by a resource can be specified in an
310   Allow header field (<xref target="header.allow"/>). The status code of the response
311   always notifies the client whether a method is currently allowed on a
312   resource, since the set of allowed methods can change dynamically. An
313   origin server SHOULD respond with the status code 405 (Method Not Allowed)
314   if the method is known by the origin server but not allowed for the
315   resource, and 501 (Not Implemented) if the method is
316   unrecognized or not implemented by the origin server. The methods GET
317   and HEAD MUST be supported by all general-purpose servers. All other
318   methods are OPTIONAL; however, if the above methods are implemented,
319   they MUST be implemented with the same semantics as those specified
320   in <xref target="method.definitions"/>.
321</t>
322
323<section title="Overview of Methods" anchor="overview.of.methods">
324<t>
325  The methods listed below are defined in <xref target="method.definitions"/>.
326</t>
327<texttable align="left">
328  <ttcol>Method Name</ttcol><ttcol>Defined in...</ttcol>
329 
330  <c>OPTIONS</c> <c><xref target="OPTIONS"/></c>
331  <c>GET</c> <c><xref target="GET"/></c>
332  <c>HEAD</c> <c><xref target="HEAD"/></c>
333  <c>POST</c> <c><xref target="POST"/></c>
334  <c>PUT</c> <c><xref target="PUT"/></c>
335  <c>DELETE</c> <c><xref target="DELETE"/></c>
336  <c>TRACE</c> <c><xref target="TRACE"/></c>
337  <c>CONNECT</c> <c><xref target="CONNECT"/></c>
338</texttable>
339<t>
340  Note that this list is not exhaustive — it does not include request methods defined
341  in other specifications.
342</t>
343</section>
344
345<section title="Method Registry" anchor="method.registry">
346<t>
347  The HTTP Method Registry defines the name space for the Method token in the
348  Request line of an HTTP request.
349</t>
350<t>
351  Registrations MUST include the following fields:
352  <list style="symbols">
353    <t>Method Name (see <xref target="method"/>)</t>
354    <t>Safe ("yes" or "no", see <xref target="safe.methods"/>)</t>
355    <t>Pointer to specification text</t>
356  </list>
357</t>
358<t>
359  Values to be added to this name space are subject to IETF review
360  (<xref target="RFC5226"/>, Section 4.1).
361</t>
362<t>
363  The registry itself is maintained at <eref target="http://www.iana.org/assignments/http-methods"/>.
364</t>
365
366<section title="Considerations for New Methods" anchor="considerations.for.new.methods">
367<t>
368   When it is necessary to express new semantics for a HTTP request that
369   aren't specific to a single application or media type, and currently defined
370   methods are inadequate, it may be appropriate to register a new method.
371</t>
372<t>
373   HTTP methods are generic; that is, they are potentially applicable to any
374   resource, not just one particular media type, "type" of resource, or
375   application. As such, it is preferred that new HTTP methods be registered
376   in a document that isn't specific to a single application, so that this is
377   clear.
378</t>
379<t>
380   Due to the parsing rules defined in Section 3.3 of <xref target="Part1"/>, definitions of HTTP
381   methods cannot prohibit the presence of a message-body on either the request
382   or the response message (with responses to HEAD requests being the single
383   exception). Definitions of new methods cannot change this rule, but they can
384   specify that only zero-length bodies (as opposed to absent bodies) are allowed.
385</t>
386<t>
387   New method definitions need to indicate whether they are safe (<xref target="safe.methods"/>), what semantics (if any) the request body has,
388   and whether they are idempotent (<xref target="idempotent.methods"/>).
389   They also need to state whether they can be cached (<xref target="Part6"/>); in
390   particular what conditions a cache may store the response, and under what
391   conditions such a stored response may be used to satisfy a subsequent
392   request.
393</t>
394</section>
395
396</section>
397</section>
398
399<section title="Request Header Fields" anchor="request.header.fields">
400 
401<t>
402   The request header fields allow the client to pass additional
403   information about the request, and about the client itself, to the
404   server. These fields act as request modifiers, with semantics
405   equivalent to the parameters on a programming language method
406   invocation.
407</t>
408<texttable align="left">
409  <ttcol>Header Field Name</ttcol>
410  <ttcol>Defined in...</ttcol>
411
412  <c>Accept</c> <c>Section 6.1 of <xref target="Part3"/></c>
413  <c>Accept-Charset</c> <c>Section 6.2 of <xref target="Part3"/></c>
414  <c>Accept-Encoding</c> <c>Section 6.3 of <xref target="Part3"/></c>
415  <c>Accept-Language</c> <c>Section 6.4 of <xref target="Part3"/></c>
416  <c>Authorization</c> <c>Section 4.1 of <xref target="Part7"/></c>
417  <c>Expect</c> <c><xref target="header.expect"/></c>
418  <c>From</c> <c><xref target="header.from"/></c>
419  <c>Host</c> <c>Section 9.4 of <xref target="Part1"/></c>
420  <c>If-Match</c> <c>Section 3.1 of <xref target="Part4"/></c>
421  <c>If-Modified-Since</c> <c>Section 3.3 of <xref target="Part4"/></c>
422  <c>If-None-Match</c> <c>Section 3.2 of <xref target="Part4"/></c>
423  <c>If-Range</c> <c>Section 5.3 of <xref target="Part5"/></c>
424  <c>If-Unmodified-Since</c> <c>Section 3.4 of <xref target="Part4"/></c>
425  <c>Max-Forwards</c> <c><xref target="header.max-forwards"/></c>
426  <c>Proxy-Authorization</c> <c>Section 4.3 of <xref target="Part7"/></c>
427  <c>Range</c> <c>Section 5.4 of <xref target="Part5"/></c>
428  <c>Referer</c> <c><xref target="header.referer"/></c>
429  <c>TE</c> <c>Section 9.5 of <xref target="Part1"/></c>
430  <c>User-Agent</c> <c><xref target="header.user-agent"/></c>
431</texttable>
432</section>
433
434<section title="Status Code and Reason Phrase" anchor="status.code.and.reason.phrase">
435 
436 
437 
438<t>
439   The Status-Code element is a 3-digit integer result code of the attempt to
440   understand and satisfy the request.
441</t>
442<t>
443   The Reason-Phrase is intended to give a short textual description of the
444   Status-Code and is intended for a human user. The client does not need
445   to examine or display the Reason-Phrase.
446</t>
447<figure><iref primary="true" item="Grammar" subitem="Status-Code"/><iref primary="true" item="Grammar" subitem="extension-code"/><iref primary="true" item="Grammar" subitem="Reason-Phrase"/><artwork type="abnf2616"><![CDATA[
448  Status-Code    = 3DIGIT
449  Reason-Phrase  = *( WSP / VCHAR / obs-text )
450]]></artwork></figure>
451<t>
452   HTTP status codes are extensible. HTTP applications are not required
453   to understand the meaning of all registered status codes, though such
454   understanding is obviously desirable. However, applications MUST
455   understand the class of any status code, as indicated by the first
456   digit, and treat any unrecognized response as being equivalent to the
457   x00 status code of that class, with the exception that an
458   unrecognized response MUST NOT be cached. For example, if an
459   unrecognized status code of 431 is received by the client, it can
460   safely assume that there was something wrong with its request and
461   treat the response as if it had received a 400 status code. In such
462   cases, user agents SHOULD present to the user the representation enclosed
463   with the response, since that representation is likely to include human-readable
464   information which will explain the unusual status.
465</t>
466
467<section title="Overview of Status Codes" anchor="overview.of.status.codes">
468<t> 
469   The status codes listed below are defined in <xref target="status.codes"/>
470   of this specification, Section 4 of <xref target="Part4"/>, Section 3 of <xref target="Part5"/>, and Section 3 of <xref target="Part7"/>.
471   The reason phrases listed here are only recommendations — they can be
472   replaced by local equivalents without affecting the protocol.
473</t>
474<texttable align="left">
475  <ttcol>Status-Code</ttcol>
476  <ttcol>Reason-Phrase</ttcol>
477  <ttcol>Defined in...</ttcol>
478 
479  <c>100</c> <c>Continue</c> <c><xref target="status.100"/></c>
480  <c>101</c> <c>Switching Protocols</c> <c><xref target="status.101"/></c>
481
482  <c>200</c> <c>OK</c> <c><xref target="status.200"/></c>
483  <c>201</c> <c>Created</c> <c><xref target="status.201"/></c>
484  <c>202</c> <c>Accepted</c> <c><xref target="status.202"/></c>
485  <c>203</c> <c>Non-Authoritative Information</c> <c><xref target="status.203"/></c>
486  <c>204</c> <c>No Content</c> <c><xref target="status.204"/></c>
487  <c>205</c> <c>Reset Content</c> <c><xref target="status.205"/></c>
488  <c>206</c> <c>Partial Content</c> <c>Section 3.1 of <xref target="Part5"/></c>
489
490  <c>300</c> <c>Multiple Choices</c> <c><xref target="status.300"/></c>
491  <c>301</c> <c>Moved Permanently</c> <c><xref target="status.301"/></c>
492  <c>302</c> <c>Found</c> <c><xref target="status.302"/></c>
493  <c>303</c> <c>See Other</c> <c><xref target="status.303"/></c>
494  <c>304</c> <c>Not Modified</c> <c>Section 4.1 of <xref target="Part4"/></c>
495  <c>305</c> <c>Use Proxy</c> <c><xref target="status.305"/></c>
496  <c>307</c> <c>Temporary Redirect</c> <c><xref target="status.307"/></c>
497
498  <c>400</c> <c>Bad Request</c> <c><xref target="status.400"/></c>
499  <c>401</c> <c>Unauthorized</c> <c>Section 3.1 of <xref target="Part7"/></c>
500  <c>402</c> <c>Payment Required</c> <c><xref target="status.402"/></c>
501  <c>403</c> <c>Forbidden</c> <c><xref target="status.403"/></c>
502  <c>404</c> <c>Not Found</c> <c><xref target="status.404"/></c>
503  <c>405</c> <c>Method Not Allowed</c> <c><xref target="status.405"/></c>
504  <c>406</c> <c>Not Acceptable</c> <c><xref target="status.406"/></c>
505  <c>407</c> <c>Proxy Authentication Required</c> <c>Section 3.2 of <xref target="Part7"/></c>
506  <c>408</c> <c>Request Time-out</c> <c><xref target="status.408"/></c>
507  <c>409</c> <c>Conflict</c> <c><xref target="status.409"/></c>
508  <c>410</c> <c>Gone</c> <c><xref target="status.410"/></c>
509  <c>411</c> <c>Length Required</c> <c><xref target="status.411"/></c>
510  <c>412</c> <c>Precondition Failed</c> <c>Section 4.2 of <xref target="Part4"/></c>
511  <c>413</c> <c>Request Representation Too Large</c> <c><xref target="status.413"/></c>
512  <c>414</c> <c>URI Too Long</c> <c><xref target="status.414"/></c>
513  <c>415</c> <c>Unsupported Media Type</c> <c><xref target="status.415"/></c>
514  <c>416</c> <c>Requested range not satisfiable</c> <c>Section 3.2 of <xref target="Part5"/></c>
515  <c>417</c> <c>Expectation Failed</c> <c><xref target="status.417"/></c>
516  <c>426</c> <c>Upgrade Required</c> <c><xref target="status.426"/></c>
517
518  <c>500</c> <c>Internal Server Error</c> <c><xref target="status.500"/></c>
519  <c>501</c> <c>Not Implemented</c> <c><xref target="status.501"/></c>
520  <c>502</c> <c>Bad Gateway</c> <c><xref target="status.502"/></c>
521  <c>503</c> <c>Service Unavailable</c> <c><xref target="status.503"/></c>
522  <c>504</c> <c>Gateway Time-out</c> <c><xref target="status.504"/></c>
523  <c>505</c> <c>HTTP Version not supported</c> <c><xref target="status.505"/></c>
524</texttable>
525<t>
526   Note that this list is not exhaustive — it does not include
527   extension status codes defined in other specifications.
528</t>
529</section>
530
531<section title="Status Code Registry" anchor="status.code.registry">
532<t>
533  The HTTP Status Code Registry defines the name space for the Status-Code
534  token in the Status-Line of an HTTP response.
535</t>
536<t>
537  Values to be added to this name space are subject to IETF review
538  (<xref target="RFC5226"/>, Section 4.1).
539</t>
540<t>
541  The registry itself is maintained at <eref target="http://www.iana.org/assignments/http-status-codes"/>.
542</t>
543
544<section title="Considerations for New Status Codes" anchor="considerations.for.new.status.codes">
545<t>
546   When it is necessary to express new semantics for a HTTP response that
547   aren't specific to a single application or media type, and currently defined
548   status codes are inadequate, a new status code can be registered.
549</t>
550<t>
551   HTTP status codes are generic; that is, they are potentially applicable to
552   any resource, not just one particular media type, "type" of resource, or
553   application. As such, it is preferred that new HTTP status codes be
554   registered in a document that isn't specific to a single application, so
555   that this is clear.
556</t>
557<t>
558   Definitions of new HTTP status codes typically explain the request
559   conditions that produce a response containing the status code (e.g.,
560   combinations of request headers and/or method(s)), along with any
561   interactions with response headers (e.g., those that are required, those
562   that modify the semantics of the response).
563</t>
564<t>
565   New HTTP status codes are required to fall under one of the categories
566   defined in <xref target="status.codes"/>. To allow existing parsers to
567   properly handle them, new status codes cannot disallow a response body,
568   although they can mandate a zero-length response body. They can require the
569   presence of one or more particular HTTP response header(s).
570</t>
571<t>
572   Likewise, their definitions can specify that caches are allowed to use
573   heuristics to determine their freshness (see <xref target="Part6"/>; by default, it is
574   not allowed), and can define how to determine the resource which they
575   carry a representation for (see <xref target="identifying.response.associated.with.representation"/>; by default,
576   it is anonymous).
577</t>
578</section>
579
580</section>
581
582</section>
583
584<section title="Response Header Fields" anchor="response.header.fields">
585 
586<t>
587   The response header fields allow the server to pass additional
588   information about the response which cannot be placed in the Status-Line.
589   These header fields give information about the server and about
590   further access to the target resource (Section 4.3 of <xref target="Part1"/>).
591</t>
592<texttable align="left">
593  <ttcol>Header Field Name</ttcol><ttcol>Defined in...</ttcol>
594
595  <c>Accept-Ranges</c> <c>Section 5.1 of <xref target="Part5"/></c>
596  <c>Age</c> <c>Section 3.1 of <xref target="Part6"/></c>
597  <c>Allow</c> <c><xref target="header.allow"/></c>
598  <c>ETag</c> <c>Section 2.3 of <xref target="Part4"/></c>
599  <c>Location</c> <c><xref target="header.location"/></c>
600  <c>Proxy-Authenticate</c> <c>Section 4.2 of <xref target="Part7"/></c>
601  <c>Retry-After</c> <c><xref target="header.retry-after"/></c>
602  <c>Server</c> <c><xref target="header.server"/></c>
603  <c>Vary</c> <c>Section 3.5 of <xref target="Part6"/></c>
604  <c>WWW-Authenticate</c> <c>Section 4.4 of <xref target="Part7"/></c>
605</texttable>
606</section>
607
608<section title="Representation" anchor="representation">
609<t>
610   Request and Response messages MAY transfer a representation if not otherwise
611   restricted by the request method or response status code. A representation
612   consists of metadata (representation header fields) and data (representation
613   body).  When a complete or partial representation is enclosed in an HTTP message,
614   it is referred to as the payload of the message. HTTP representations
615   are defined in <xref target="Part3"/>.
616</t>
617<t>
618   A representation body is only present in a message when a message-body is
619   present, as described in Section 3.3 of <xref target="Part1"/>. The representation body is obtained
620   from the message-body by decoding any Transfer-Encoding that might
621   have been applied to ensure safe and proper transfer of the message.
622</t>
623
624<section title="Identifying the Resource Associated with a Representation" anchor="identifying.response.associated.with.representation">
625<t>
626   It is sometimes necessary to determine an identifier for the resource
627   associated with a representation.
628</t>
629<t>
630   An HTTP request representation, when present, is always associated with an
631   anonymous (i.e., unidentified) resource.
632</t>
633<t>
634   In the common case, an HTTP response is a representation of the target
635   resource (see Section 4.3 of <xref target="Part1"/>). However, this is not always the
636   case. To determine the URI of the resource a response is associated with,
637   the following rules are used (with the first applicable one being selected):
638</t>
639<t><list style="numbers">
640   <t>If the response status code is 200 or 203 and the request method was GET,
641   the response payload is a representation of the target resource.</t>
642   <t>If the response status code is 204, 206, or 304 and the request method was GET
643   or HEAD, the response payload is a partial representation of the target
644   resource.</t>
645   <t>If the response has a Content-Location header field, and that URI is the same
646   as the effective request URI, the response payload is a representation of the
647   target resource.</t>
648   <t>If the response has a Content-Location header field, and that URI is not the
649   same as the effective request URI, then the response asserts that its
650   payload is a representation of the resource identified by the
651   Content-Location URI. However, such an assertion cannot be trusted unless
652   it can be verified by other means (not defined by HTTP).</t>
653   <t>Otherwise, the response is a representation of an anonymous (i.e.,
654   unidentified) resource.</t>
655</list></t>
656<t>
657  <cref anchor="TODO-req-uri">
658   The comparison function is going to have to be defined somewhere,
659   because we already need to compare URIs for things like cache invalidation.</cref>
660</t>
661</section>
662
663</section>
664
665
666<section title="Method Definitions" anchor="method.definitions">
667<t>
668   The set of common request methods for HTTP/1.1 is defined below. Although
669   this set can be expanded, additional methods cannot be assumed to
670   share the same semantics for separately extended clients and servers.
671</t>
672
673<section title="Safe and Idempotent Methods" anchor="safe.and.idempotent">
674
675<section title="Safe Methods" anchor="safe.methods">
676<iref item="Safe Methods" primary="true"/>
677<t>
678   Implementors need to be aware that the software represents the user in
679   their interactions over the Internet, and need to allow
680   the user to be aware of any actions they take which might have an
681   unexpected significance to themselves or others.
682</t>
683<t>
684   In particular, the convention has been established that the GET, HEAD,
685   OPTIONS, and TRACE request methods SHOULD NOT have the significance
686   of taking an action other than retrieval. These request methods ought
687   to be considered "safe".
688   This allows user agents to represent other methods, such as POST, PUT
689   and DELETE, in a special way, so that the user is made aware of the
690   fact that a possibly unsafe action is being requested.
691</t>
692<t>
693   Naturally, it is not possible to ensure that the server does not
694   generate side-effects as a result of performing a GET request; in
695   fact, some dynamic resources consider that a feature. The important
696   distinction here is that the user did not request the side-effects,
697   so therefore cannot be held accountable for them.
698</t>
699</section>
700
701<section title="Idempotent Methods" anchor="idempotent.methods">
702<iref item="Idempotent Methods" primary="true"/>
703<t>
704   Request methods can also have the property of "idempotence" in that,
705   aside from error or expiration issues, the intended effect of multiple
706   identical requests is the same as for a single request.
707   PUT, DELETE, and all safe request methods are idempotent.
708   It is important to note that idempotence refers only to changes
709   requested by the client: a server is free to change its state due
710   to multiple requests for the purpose of tracking those requests,
711   versioning of results, etc.
712</t>
713</section>
714</section>
715
716<section title="OPTIONS" anchor="OPTIONS">
717 
718  <iref primary="true" item="OPTIONS method"/>
719  <iref primary="true" item="Methods" subitem="OPTIONS"/>
720<t>
721   The OPTIONS method requests information about the
722   communication options available on the request/response chain
723   identified by the effective request URI. This method allows a client to
724   determine the options and/or requirements associated with a resource,
725   or the capabilities of a server, without implying a resource action
726   or initiating a resource retrieval.
727</t>
728<t>
729   Responses to the OPTIONS method are not cacheable.
730</t>
731<t>
732   If the OPTIONS request includes a message-body (as indicated by the
733   presence of Content-Length or Transfer-Encoding), then the media type
734   MUST be indicated by a Content-Type field. Although this
735   specification does not define any use for such a body, future
736   extensions to HTTP might use the OPTIONS body to make more detailed
737   queries on the server.
738</t>
739<t>
740   If the request-target is an asterisk ("*"), the OPTIONS request is
741   intended to apply to the server in general rather than to a specific
742   resource. Since a server's communication options typically depend on
743   the resource, the "*" request is only useful as a "ping" or "no-op"
744   type of method; it does nothing beyond allowing the client to test
745   the capabilities of the server. For example, this can be used to test
746   a proxy for HTTP/1.1 compliance (or lack thereof).
747</t>
748<t>
749   If the request-target is not an asterisk, the OPTIONS request applies
750   only to the options that are available when communicating with that
751   resource.
752</t>
753<t>
754   A 200 response SHOULD include any header fields that indicate
755   optional features implemented by the server and applicable to that
756   resource (e.g., Allow), possibly including extensions not defined by
757   this specification. The response body, if any, SHOULD also include
758   information about the communication options. The format for such a
759   body is not defined by this specification, but might be defined by
760   future extensions to HTTP. Content negotiation MAY be used to select
761   the appropriate response format. If no response body is included, the
762   response MUST include a Content-Length field with a field-value of
763   "0".
764</t>
765<t>
766   The Max-Forwards header field MAY be used to target a
767   specific proxy in the request chain (see <xref target="header.max-forwards"/>).
768   If no Max-Forwards field is present in the request, then the forwarded
769   request MUST NOT include a Max-Forwards field.
770</t>
771</section>
772
773<section title="GET" anchor="GET">
774 
775  <iref primary="true" item="GET method"/>
776  <iref primary="true" item="Methods" subitem="GET"/>
777<t>
778   The GET method requests transfer of a current representation of
779   the target resource.
780</t>
781<t>   
782   If the target resource is a data-producing process, it is the
783   produced data which shall be returned as the representation in the response and not
784   the source text of the process, unless that text happens to be the output of
785   the process.
786</t>
787<t>
788   The semantics of the GET method change to a "conditional GET" if the
789   request message includes an If-Modified-Since, If-Unmodified-Since,
790   If-Match, If-None-Match, or If-Range header field. A conditional GET
791   requests that the representation be transferred only under the
792   circumstances described by the conditional header field(s). The
793   conditional GET request is intended to reduce unnecessary network
794   usage by allowing cached representations to be refreshed without requiring
795   multiple requests or transferring data already held by the client.
796</t>
797<t>
798   The semantics of the GET method change to a "partial GET" if the
799   request message includes a Range header field. A partial GET requests
800   that only part of the representation be transferred, as described in Section 5.4 of <xref target="Part5"/>.
801   The partial GET request is intended to reduce unnecessary
802   network usage by allowing partially-retrieved representations to be
803   completed without transferring data already held by the client.
804</t>
805<t>
806   Bodies on GET requests have no defined semantics. Note that sending a body
807   on a GET request might cause some existing implementations to reject the
808   request.
809</t>
810<t>
811   The response to a GET request is cacheable and MAY be used to satisfy
812   subsequent GET and HEAD requests (see <xref target="Part6"/>).
813</t>
814<t>
815   See <xref target="encoding.sensitive.information.in.uris"/> for security considerations when used for forms.
816</t>
817</section>
818
819<section title="HEAD" anchor="HEAD">
820 
821  <iref primary="true" item="HEAD method"/>
822  <iref primary="true" item="Methods" subitem="HEAD"/>
823<t>
824   The HEAD method is identical to GET except that the server MUST NOT
825   return a message-body in the response. The metadata contained
826   in the HTTP header fields in response to a HEAD request SHOULD be identical
827   to the information sent in response to a GET request. This method can
828   be used for obtaining metadata about the representation implied by the
829   request without transferring the representation body. This method is
830   often used for testing hypertext links for validity, accessibility,
831   and recent modification.
832</t>
833<t>
834   The response to a HEAD request is cacheable and MAY be used to satisfy
835   a subsequent HEAD request; see <xref target="Part6"/>. It also MAY be used to update a previously cached
836   representation from that resource; if the new field values
837   indicate that the cached representation differs from the current representation (as
838   would be indicated by a change in Content-Length, ETag
839   or Last-Modified), then the cache MUST treat the cache entry as
840   stale.
841</t>
842<t>
843   Bodies on HEAD requests have no defined semantics. Note that sending a body
844   on a HEAD request might cause some existing implementations to reject the
845   request.
846</t>
847</section>
848
849<section title="POST" anchor="POST">
850  <iref primary="true" item="POST method"/>
851  <iref primary="true" item="Methods" subitem="POST"/>
852<t>
853   The POST method requests that the origin server accept the
854   representation enclosed in the request as data to be processed by the
855   target resource. POST is designed to allow a uniform method to cover the
856   following functions:
857  <list style="symbols">
858    <t>
859      Annotation of existing resources;
860    </t>
861    <t>
862        Posting a message to a bulletin board, newsgroup, mailing list,
863        or similar group of articles;
864    </t>
865    <t>
866        Providing a block of data, such as the result of submitting a
867        form, to a data-handling process;
868    </t>
869    <t>
870        Extending a database through an append operation.
871    </t>
872  </list>
873</t>
874<t>
875   The actual function performed by the POST method is determined by the
876   server and is usually dependent on the effective request URI.
877</t>
878<t>
879   The action performed by the POST method might not result in a
880   resource that can be identified by a URI. In this case, either 200
881   (OK) or 204 (No Content) is the appropriate response status code,
882   depending on whether or not the response includes a representation that
883   describes the result.
884</t>
885<t>
886   If a resource has been created on the origin server, the response
887   SHOULD be 201 (Created) and contain a representation which describes the
888   status of the request and refers to the new resource, and a Location
889   header field (see <xref target="header.location"/>).
890</t>
891<t>
892   Responses to POST requests are only cacheable when they
893   include explicit freshness information (see Section 2.3.1 of <xref target="Part6"/>). A
894   cached POST response with a Content-Location header field
895   (see Section 6.7 of <xref target="Part3"/>) whose value is the effective
896   Request URI MAY be used to satisfy subsequent GET and HEAD requests.
897</t>
898<t>
899   Note that POST caching is not widely implemented.
900   However, the 303 (See Other) response can be used to direct the
901   user agent to retrieve a cacheable resource.
902</t>
903</section>
904
905<section title="PUT" anchor="PUT">
906  <iref primary="true" item="PUT method"/>
907  <iref primary="true" item="Methods" subitem="PUT"/>
908<t>
909   The PUT method requests that the state of the target resource
910   be created or replaced with the state defined by the representation
911   enclosed in the request message payload.  A successful PUT of a given
912   representation would suggest that a subsequent GET on that same target
913   resource will result in an equivalent representation being returned in
914   a 200 (OK) response.  However, there is no guarantee that such a state
915   change will be observable, since the target resource might be acted
916   upon by other user agents in parallel, or might be subject to dynamic
917   processing by the origin server, before any subsequent GET is received.
918   A successful response only implies that the user agent's intent was
919   achieved at the time of its processing by the origin server.
920</t>
921<t>   
922   If the target resource does not have a current representation and
923   the PUT successfully creates one, then the origin server MUST inform
924   the user agent by sending a 201 (Created) response.  If the target
925   resource does have a current representation and that representation is
926   successfully modified in accordance with the state of the enclosed
927   representation, then either a 200 (OK) or 204 (No Content) response
928   SHOULD be sent to indicate successful completion of the request.
929</t>
930<t>
931   Unrecognized header fields SHOULD be ignored (i.e., not saved
932   as part of the resource state).
933</t>
934<t>
935   An origin server SHOULD verify that the PUT representation is
936   consistent with any constraints which the server has for the target
937   resource that cannot or will not be changed by the PUT.  This is
938   particularly important when the origin server uses internal
939   configuration information related to the URI in order to set the
940   values for representation metadata on GET responses.  When a PUT
941   representation is inconsistent with the target resource, the origin
942   server SHOULD either make them consistent, by transforming the
943   representation or changing the resource configuration, or respond
944   with an appropriate error message containing sufficient information
945   to explain why the representation is unsuitable.  The 409 (Conflict)
946   or 415 (Unsupported Media Type) status codes are suggested, with the
947   latter being specific to constraints on Content-Type values.
948</t>
949<t>
950   For example, if the target resource is configured to always have a
951   Content-Type of "text/html" and the representation being PUT has a
952   Content-Type of "image/jpeg", then the origin server SHOULD do one of:
953   (a) reconfigure the target resource to reflect the new media type;
954   (b) transform the PUT representation to a format consistent with that
955   of the resource before saving it as the new resource state; or,
956   (c) reject the request with a 415 response indicating that the target
957   resource is limited to "text/html", perhaps including a link to a
958   different resource that would be a suitable target for the new
959   representation.
960</t>
961<t>
962   HTTP does not define exactly how a PUT method affects the state
963   of an origin server beyond what can be expressed by the intent of
964   the user agent request and the semantics of the origin server response.
965   It does not define what a resource might be, in any sense of that
966   word, beyond the interface provided via HTTP.  It does not define
967   how resource state is "stored", nor how such storage might change
968   as a result of a change in resource state, nor how the origin server
969   translates resource state into representations.  Generally speaking,
970   all implementation details behind the resource interface are
971   intentionally hidden by the server.
972</t>
973<t>
974   The fundamental difference between the POST and PUT methods is
975   highlighted by the different intent for the target resource.
976   The target resource in a POST request is intended to handle the
977   enclosed representation as a data-accepting process, such as for
978   a gateway to some other protocol or a document that accepts annotations.
979   In contrast, the target resource in a PUT request is intended to
980   take the enclosed representation as a new or replacement value.
981   Hence, the intent of PUT is idempotent and visible to intermediaries,
982   even though the exact effect is only known by the origin server.
983</t>
984<t>
985   Proper interpretation of a PUT request presumes that the user agent
986   knows what target resource is desired.  A service that is intended
987   to select a proper URI on behalf of the client, after receiving
988   a state-changing request, SHOULD be implemented using the POST
989   method rather than PUT.  If the origin server will not make the
990   requested PUT state change to the target resource and instead
991   wishes to have it applied to a different resource, such as when the
992   resource has been moved to a different URI, then the origin server
993   MUST send a 301 (Moved Permanently) response; the user agent MAY
994   then make its own decision regarding whether or not to redirect the
995   request.
996</t>
997<t>
998   A PUT request applied to the target resource MAY have side-effects
999   on other resources.  For example, an article might have a URI for
1000   identifying "the current version" (a resource) which is separate
1001   from the URIs identifying each particular version (different
1002   resources that at one point shared the same state as the current version
1003   resource).  A successful PUT request on "the current version" URI might
1004   therefore create a new version resource in addition to changing the
1005   state of the target resource, and might also cause links to be added
1006   between the related resources.
1007</t>
1008<t>
1009   An origin server SHOULD reject any PUT request that contains a
1010   Content-Range header field, since it might be misinterpreted as
1011   partial content (or might be partial content that is being mistakenly
1012   PUT as a full representation).  Partial content updates are
1013   possible by targeting a separately identified resource with state
1014   that overlaps a portion of the larger resource, or by using a
1015   different method that has been specifically defined for partial
1016   updates (for example, the PATCH method defined in
1017   <xref target="RFC5789"/>).
1018</t>
1019<t>
1020   Responses to the PUT method are not cacheable. If a PUT request passes
1021   through a cache that has one or more stored responses for the effective
1022   request URI, those stored responses will be invalidated (see
1023   Section 2.5 of <xref target="Part6"/>).
1024</t>
1025</section>
1026
1027<section title="DELETE" anchor="DELETE">
1028  <iref primary="true" item="DELETE method"/>
1029  <iref primary="true" item="Methods" subitem="DELETE"/>
1030<t>
1031   The DELETE method requests that the origin server delete the target
1032   resource. This method MAY be overridden by
1033   human intervention (or other means) on the origin server. The client cannot
1034   be guaranteed that the operation has been carried out, even if the
1035   status code returned from the origin server indicates that the action
1036   has been completed successfully. However, the server SHOULD NOT
1037   indicate success unless, at the time the response is given, it
1038   intends to delete the resource or move it to an inaccessible
1039   location.
1040</t>
1041<t>
1042   A successful response SHOULD be 200 (OK) if the response includes an
1043   representation describing the status, 202 (Accepted) if the action has not
1044   yet been enacted, or 204 (No Content) if the action has been enacted
1045   but the response does not include a representation.
1046</t>
1047<t>
1048   Bodies on DELETE requests have no defined semantics. Note that sending a body
1049   on a DELETE request might cause some existing implementations to reject the
1050   request.
1051</t>
1052<t>
1053   Responses to the DELETE method are not cacheable. If a DELETE request
1054   passes through a cache that has one or more stored responses for the
1055   effective request URI, those stored responses will be invalidated (see
1056   Section 2.5 of <xref target="Part6"/>).
1057</t>
1058</section>
1059
1060<section title="TRACE" anchor="TRACE">
1061 
1062  <iref primary="true" item="TRACE method"/>
1063  <iref primary="true" item="Methods" subitem="TRACE"/>
1064<t>
1065   The TRACE method requests a remote, application-layer loop-back
1066   of the request message. The final recipient of the request
1067   SHOULD reflect the message received back to the client as the
1068   message-body of a 200 (OK) response. The final recipient is either the
1069   origin server or the first proxy to receive a Max-Forwards
1070   value of zero (0) in the request (see <xref target="header.max-forwards"/>).
1071   A TRACE request MUST NOT include a message-body.
1072</t>
1073<t>
1074   TRACE allows the client to see what is being received at the other
1075   end of the request chain and use that data for testing or diagnostic
1076   information. The value of the Via header field (Section 9.9 of <xref target="Part1"/>) is of
1077   particular interest, since it acts as a trace of the request chain.
1078   Use of the Max-Forwards header field allows the client to limit the
1079   length of the request chain, which is useful for testing a chain of
1080   proxies forwarding messages in an infinite loop.
1081</t>
1082<t>
1083   If the request is valid, the response SHOULD have a Content-Type of
1084   "message/http" (see Section 10.3.1 of <xref target="Part1"/>) and contain a message-body
1085   that encloses a copy of the entire request message.
1086   Responses to the TRACE method are not cacheable.
1087</t>
1088</section>
1089
1090<section title="CONNECT" anchor="CONNECT">
1091  <iref primary="true" item="CONNECT method"/>
1092  <iref primary="true" item="Methods" subitem="CONNECT"/>
1093<t>
1094   The CONNECT method requests that the proxy establish a tunnel
1095   to the request-target and then restrict its behavior to blind
1096   forwarding of packets until the connection is closed.
1097</t>
1098<t>
1099   When using CONNECT, the request-target MUST use the authority form
1100   (Section 4.1.2 of <xref target="Part1"/>); i.e., the request-target consists of only the
1101   host name and port number of the tunnel destination, separated by a colon.
1102   For example,
1103</t>
1104<figure><artwork type="message/http; msgtype=&#34;request&#34;"><![CDATA[
1105  CONNECT server.example.com:80 HTTP/1.1
1106  Host: server.example.com:80
1107 
1108  ]]></artwork></figure>
1109<t>
1110   Other HTTP mechanisms can be used normally with the CONNECT method —
1111   except end-to-end protocol Upgrade requests, since the
1112   tunnel must be established first.
1113</t>
1114<t>
1115   For example, proxy authentication might be used to establish the
1116   authority to create a tunnel:
1117</t>
1118<figure><artwork type="message/http; msgtype=&#34;request&#34;"><![CDATA[
1119  CONNECT server.example.com:80 HTTP/1.1
1120  Host: server.example.com:80
1121  Proxy-Authorization: basic aGVsbG86d29ybGQ=
1122 
1123  ]]></artwork></figure>
1124<t>
1125   Bodies on CONNECT requests have no defined semantics. Note that sending a body
1126   on a CONNECT request might cause some existing implementations to reject the
1127   request.
1128</t>
1129<t>
1130   Like any other pipelined HTTP/1.1 request, data to be tunnel may be
1131   sent immediately after the blank line. The usual caveats also apply:
1132   data may be discarded if the eventual response is negative, and the
1133   connection may be reset with no response if more than one TCP segment
1134   is outstanding.
1135</t>
1136
1137<section title="Establishing a Tunnel with CONNECT">
1138<t>
1139   Any successful (2xx) response to a CONNECT request indicates that the
1140   proxy has established a connection to the requested host and port,
1141   and has switched to tunneling the current connection to that server
1142   connection.
1143</t>
1144<t>
1145   It may be the case that the proxy itself can only reach the requested
1146   origin server through another proxy.  In this case, the first proxy
1147   SHOULD make a CONNECT request of that next proxy, requesting a tunnel
1148   to the authority.  A proxy MUST NOT respond with any 2xx status code
1149   unless it has either a direct or tunnel connection established to the
1150   authority.
1151</t>
1152<t>
1153   An origin server which receives a CONNECT request for itself MAY
1154   respond with a 2xx status code to indicate that a connection is
1155   established.
1156</t>
1157<t>
1158   If at any point either one of the peers gets disconnected, any
1159   outstanding data that came from that peer will be passed to the other
1160   one, and after that also the other connection will be terminated by
1161   the proxy. If there is outstanding data to that peer undelivered,
1162   that data will be discarded.
1163</t>
1164
1165</section>
1166</section>
1167</section>
1168
1169
1170<section title="Status Code Definitions" anchor="status.codes">
1171<t>
1172   Each Status-Code is described below, including any metadata required
1173   in the response.
1174</t>
1175
1176<section title="Informational 1xx" anchor="status.1xx">
1177<t>
1178   This class of status code indicates a provisional response,
1179   consisting only of the Status-Line and optional header fields, and is
1180   terminated by an empty line. There are no required header fields for this
1181   class of status code. Since HTTP/1.0 did not define any 1xx status
1182   codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client
1183   except under experimental conditions.
1184</t>
1185<t>
1186   A client MUST be prepared to accept one or more 1xx status responses
1187   prior to a regular response, even if the client does not expect a 100
1188   (Continue) status message. Unexpected 1xx status responses MAY be
1189   ignored by a user agent.
1190</t>
1191<t>
1192   Proxies MUST forward 1xx responses, unless the connection between the
1193   proxy and its client has been closed, or unless the proxy itself
1194   requested the generation of the 1xx response. (For example, if a
1195   proxy adds a "Expect: 100-continue" field when it forwards a request,
1196   then it need not forward the corresponding 100 (Continue)
1197   response(s).)
1198</t>
1199
1200<section title="100 Continue" anchor="status.100">
1201  <iref primary="true" item="100 Continue (status code)"/>
1202  <iref primary="true" item="Status Codes" subitem="100 Continue"/>
1203<t>
1204   The client SHOULD continue with its request. This interim response is
1205   used to inform the client that the initial part of the request has
1206   been received and has not yet been rejected by the server. The client
1207   SHOULD continue by sending the remainder of the request or, if the
1208   request has already been completed, ignore this response. The server
1209   MUST send a final response after the request has been completed. See
1210   Section 7.2.3 of <xref target="Part1"/> for detailed discussion of the use and handling of this
1211   status code.
1212</t>
1213</section>
1214
1215<section title="101 Switching Protocols" anchor="status.101">
1216  <iref primary="true" item="101 Switching Protocols (status code)"/>
1217  <iref primary="true" item="Status Codes" subitem="101 Switching Protocols"/>
1218<t>
1219   The server understands and is willing to comply with the client's
1220   request, via the Upgrade message header field (Section 9.8 of <xref target="Part1"/>), for a
1221   change in the application protocol being used on this connection. The
1222   server will switch protocols to those defined by the response's
1223   Upgrade header field immediately after the empty line which
1224   terminates the 101 response.
1225</t>
1226<t>
1227   The protocol SHOULD be switched only when it is advantageous to do
1228   so. For example, switching to a newer version of HTTP is advantageous
1229   over older versions, and switching to a real-time, synchronous
1230   protocol might be advantageous when delivering resources that use
1231   such features.
1232</t>
1233</section>
1234</section>
1235
1236<section title="Successful 2xx" anchor="status.2xx">
1237<t>
1238   This class of status code indicates that the client's request was
1239   successfully received, understood, and accepted.
1240</t>
1241
1242<section title="200 OK" anchor="status.200">
1243  <iref primary="true" item="200 OK (status code)"/>
1244  <iref primary="true" item="Status Codes" subitem="200 OK"/>
1245<t>
1246   The request has succeeded. The payload returned with the response
1247   is dependent on the method used in the request, for example:
1248  <list style="hanging">
1249    <t hangText="GET">
1250      a representation of the target resource is sent in the response;
1251    </t>
1252    <t hangText="HEAD">
1253      the same representation as GET, except without the message-body;
1254    </t>
1255    <t hangText="POST">
1256      a representation describing or containing the result of the action;
1257    </t>
1258    <t hangText="TRACE">
1259      a representation containing the request message as received by the
1260      end server.
1261    </t>
1262  </list>
1263</t>
1264<t>
1265   Caches MAY use a heuristic (see Section 2.3.1.1 of <xref target="Part6"/>) to determine
1266   freshness for 200 responses.
1267</t>
1268</section>
1269
1270<section title="201 Created" anchor="status.201">
1271  <iref primary="true" item="201 Created (status code)"/>
1272  <iref primary="true" item="Status Codes" subitem="201 Created"/>
1273<t>
1274   The request has been fulfilled and has resulted in a new resource being
1275   created. The newly created resource can be referenced by the URI(s)
1276   returned in the payload of the response, with the most specific URI
1277   for the resource given by a Location header field. The response
1278   SHOULD include a payload containing a list of resource
1279   characteristics and location(s) from which the user or user agent can
1280   choose the one most appropriate. The payload format is specified by
1281   the media type given in the Content-Type header field. The origin
1282   server MUST create the resource before returning the 201 status code.
1283   If the action cannot be carried out immediately, the server SHOULD
1284   respond with 202 (Accepted) response instead.
1285</t>
1286<t>
1287   A 201 response MAY contain an ETag response header field indicating
1288   the current value of the entity-tag for the representation of the resource
1289   just created (see Section 2.3 of <xref target="Part4"/>).
1290</t>
1291</section>
1292
1293<section title="202 Accepted" anchor="status.202">
1294  <iref primary="true" item="202 Accepted (status code)"/>
1295  <iref primary="true" item="Status Codes" subitem="202 Accepted"/>
1296<t>
1297   The request has been accepted for processing, but the processing has
1298   not been completed.  The request might or might not eventually be
1299   acted upon, as it might be disallowed when processing actually takes
1300   place. There is no facility for re-sending a status code from an
1301   asynchronous operation such as this.
1302</t>
1303<t>
1304   The 202 response is intentionally non-committal. Its purpose is to
1305   allow a server to accept a request for some other process (perhaps a
1306   batch-oriented process that is only run once per day) without
1307   requiring that the user agent's connection to the server persist
1308   until the process is completed. The representation returned with this
1309   response SHOULD include an indication of the request's current status
1310   and either a pointer to a status monitor or some estimate of when the
1311   user can expect the request to be fulfilled.
1312</t>
1313</section>
1314
1315<section title="203 Non-Authoritative Information" anchor="status.203">
1316  <iref primary="true" item="203 Non-Authoritative Information (status code)"/>
1317  <iref primary="true" item="Status Codes" subitem="203 Non-Authoritative Information"/>
1318<t>
1319   The representation in the response has been transformed or otherwise
1320   modified by a transforming proxy (Section 2.4 of <xref target="Part1"/>).  Note that the
1321   behaviour of transforming intermediaries is controlled by the no-transform
1322   Cache-Control directive (Section 3.2 of <xref target="Part6"/>).
1323</t>
1324<t>
1325   This status code is only appropriate when the response status code would
1326   have been 200 (OK) otherwise. When the status code before transformation
1327   would have been different, the 214 Transformation Applied warn-code
1328   (Section 3.6 of <xref target="Part6"/>) is appropriate.
1329</t>
1330<t>
1331   Caches MAY use a heuristic (see Section 2.3.1.1 of <xref target="Part6"/>) to determine
1332   freshness for 203 responses.
1333</t>
1334</section>
1335
1336<section title="204 No Content" anchor="status.204">
1337  <iref primary="true" item="204 No Content (status code)"/>
1338  <iref primary="true" item="Status Codes" subitem="204 No Content"/>
1339<t>
1340   The 204 (No Content) status code indicates that the server has
1341   successfully fulfilled the request and that there is no additional
1342   content to return in the response payload body.  Metadata in the
1343   response header fields refer to the target resource and its current
1344   representation after the requested action.
1345</t>
1346<t>
1347   For example, if a 204 status code is received in response to a PUT
1348   request and the response contains an ETag header field, then the PUT
1349   was successful and the ETag field-value contains the entity-tag for
1350   the new representation of that target resource.
1351</t>
1352<t>
1353   The 204 response allows a server to indicate that the action has been
1354   successfully applied to the target resource while implying that the
1355   user agent SHOULD NOT traverse away from its current "document view"
1356   (if any).  The server assumes that the user agent will provide some
1357   indication of the success to its user, in accord with its own interface,
1358   and apply any new or updated metadata in the response to the active
1359   representation.
1360</t>
1361<t>
1362   For example, a 204 status code is commonly used with document editing
1363   interfaces corresponding to a "save" action, such that the document
1364   being saved remains available to the user for editing. It is also
1365   frequently used with interfaces that expect automated data transfers
1366   to be prevalent, such as within distributed version control systems.
1367</t>
1368<t>
1369   The 204 response MUST NOT include a message-body, and thus is always
1370   terminated by the first empty line after the header fields.
1371</t>
1372</section>
1373
1374<section title="205 Reset Content" anchor="status.205">
1375  <iref primary="true" item="205 Reset Content (status code)"/>
1376  <iref primary="true" item="Status Codes" subitem="205 Reset Content"/>
1377<t>
1378   The server has fulfilled the request and the user agent SHOULD reset
1379   the document view which caused the request to be sent. This response
1380   is primarily intended to allow input for actions to take place via
1381   user input, followed by a clearing of the form in which the input is
1382   given so that the user can easily initiate another input action.
1383</t>
1384<t>   
1385   The message-body included with the response MUST be empty. Note that
1386   receivers still need to parse the response according to the algorithm defined
1387   in Section 3.3 of <xref target="Part1"/>.
1388</t>
1389</section>
1390
1391<section title="206 Partial Content" anchor="status.206">
1392  <iref primary="true" item="206 Partial Content (status code)"/>
1393  <iref primary="true" item="Status Codes" subitem="206 Partial Content"/>
1394 
1395<t>
1396   The server has fulfilled the partial GET request for the resource
1397   and the enclosed payload is a partial representation as defined in Section 3.1 of <xref target="Part5"/>.
1398</t>
1399<t>
1400   Caches MAY use a heuristic (see Section 2.3.1.1 of <xref target="Part6"/>) to determine
1401   freshness for 206 responses.
1402</t>
1403</section>
1404</section>
1405
1406<section title="Redirection 3xx" anchor="status.3xx">
1407<t>
1408   This class of status code indicates that further action needs to be
1409   taken by the user agent in order to fulfill the request.  The action
1410   required MAY be carried out by the user agent without interaction
1411   with the user if and only if the method used in the second request is
1412   known to be "safe", as defined in <xref target="safe.methods"/>.
1413   A client SHOULD detect infinite redirection loops, since such loops
1414   generate network traffic for each redirection.
1415</t>
1416<t><list>
1417  <t>
1418    Note: An earlier version of this specification recommended a
1419    maximum of five redirections (<xref target="RFC2068"/>, Section 10.3).
1420    Content developers need to be aware that some clients might
1421    implement such a fixed limitation.
1422  </t>
1423</list></t>
1424
1425<section title="300 Multiple Choices" anchor="status.300">
1426  <iref primary="true" item="300 Multiple Choices (status code)"/>
1427  <iref primary="true" item="Status Codes" subitem="300 Multiple Choices"/>
1428<t>
1429   The target resource has more than one
1430   representation, each with its own specific location, and agent-driven
1431   negotiation information (Section 5 of <xref target="Part3"/>) is being provided so that
1432   the user (or user agent) can select a preferred representation by
1433   redirecting its request to that location.
1434</t>
1435<t>
1436   Unless it was a HEAD request, the response SHOULD include a representation
1437   containing a list of representation metadata and location(s) from
1438   which the user or user agent can choose the one most appropriate. The
1439   data format is specified by the media type given in the Content-Type
1440   header field. Depending upon the format and the capabilities of
1441   the user agent, selection of the most appropriate choice MAY be
1442   performed automatically. However, this specification does not define
1443   any standard for such automatic selection.
1444</t>
1445<t>
1446   If the server has a preferred choice of representation, it SHOULD
1447   include the specific URI for that representation in the Location
1448   field; user agents MAY use the Location field value for automatic
1449   redirection.
1450</t>
1451<t>
1452   Caches MAY use a heuristic (see Section 2.3.1.1 of <xref target="Part6"/>) to determine
1453   freshness for 300 responses.
1454</t>
1455
1456</section>
1457
1458<section title="301 Moved Permanently" anchor="status.301">
1459  <iref primary="true" item="301 Moved Permanently (status code)"/>
1460  <iref primary="true" item="Status Codes" subitem="301 Moved Permanently"/>
1461<t>
1462   The target resource has been assigned a new permanent URI and any
1463   future references to this resource SHOULD use one of the returned
1464   URIs.  Clients with link editing capabilities ought to automatically
1465   re-link references to the effective request URI to one or more of the new
1466   references returned by the server, where possible.
1467</t>
1468<t>
1469   Caches MAY use a heuristic (see Section 2.3.1.1 of <xref target="Part6"/>) to determine
1470   freshness for 301 responses.
1471</t>
1472<t>
1473   The new permanent URI SHOULD be given by the Location field in the
1474   response. Unless the request method was HEAD, the representation of the
1475   response SHOULD contain a short hypertext note with a hyperlink to
1476   the new URI(s).
1477</t>
1478<t>
1479   If the 301 status code is received in response to a request method
1480   that is known to be "safe", as defined in <xref target="safe.methods"/>,
1481   then the request MAY be automatically redirected by the user agent without
1482   confirmation.  Otherwise, the user agent MUST NOT automatically redirect the
1483   request unless it can be confirmed by the user, since this might
1484   change the conditions under which the request was issued.
1485</t>
1486<t><list>
1487  <t>
1488    Note: When automatically redirecting a POST request after
1489    receiving a 301 status code, some existing HTTP/1.0 user agents
1490    will erroneously change it into a GET request.
1491  </t>
1492</list></t>
1493</section>
1494
1495<section title="302 Found" anchor="status.302">
1496  <iref primary="true" item="302 Found (status code)"/>
1497  <iref primary="true" item="Status Codes" subitem="302 Found"/>
1498<t>
1499   The target resource resides temporarily under a different URI.
1500   Since the redirection might be altered on occasion, the client SHOULD
1501   continue to use the effective request URI for future requests.
1502</t>
1503<t>
1504   The temporary URI SHOULD be given by the Location field in the
1505   response. Unless the request method was HEAD, the representation of the
1506   response SHOULD contain a short hypertext note with a hyperlink to
1507   the new URI(s).
1508</t>
1509<t>
1510   If the 302 status code is received in response to a request method
1511   that is known to be "safe", as defined in <xref target="safe.methods"/>,
1512   then the request MAY be automatically redirected by the user agent without
1513   confirmation.  Otherwise, the user agent MUST NOT automatically redirect the
1514   request unless it can be confirmed by the user, since this might
1515   change the conditions under which the request was issued.
1516</t>
1517<t><list>
1518  <t>
1519    Note: HTTP/1.0 (<xref target="RFC1945"/>, Section 9.3)
1520    and the first version of HTTP/1.1 (<xref target="RFC2068"/>, Section 10.3.3)
1521    specify that the client is not allowed to change the method on the
1522    redirected request.  However, most existing user agent implementations
1523    treat 302 as if it were a 303 response, performing a GET on the Location
1524    field-value regardless of the original request method. Therefore, a
1525    previous version of this specification
1526    (<xref target="RFC2616"/>, Section 10.3.3) has added the
1527    status codes
1528    <xref target="status.303" format="none">303</xref> and
1529    <xref target="status.307" format="none">307</xref> for servers that wish
1530    to make unambiguously clear which kind of reaction is expected of the
1531    client.
1532  </t>
1533</list></t>
1534</section>
1535
1536<section title="303 See Other" anchor="status.303">
1537  <iref primary="true" item="303 See Other (status code)"/>
1538  <iref primary="true" item="Status Codes" subitem="303 See Other"/>
1539<t>
1540   The server directs the user agent to a different resource, indicated
1541   by a URI in the Location header field, that provides an indirect
1542   response to the original request.  The user agent MAY perform a GET
1543   request on the URI in the Location field in order to obtain a
1544   representation corresponding to the response, be redirected again,
1545   or end with an error status.  The Location URI is not a substitute
1546   reference for the effective request URI.
1547</t>
1548<t>
1549   The 303 status code is generally applicable to any HTTP method.  It is
1550   primarily used to allow the output of a POST action to redirect
1551   the user agent to a selected resource, since doing so provides the
1552   information corresponding to the POST response in a form that
1553   can be separately identified, bookmarked, and cached independent
1554   of the original request.
1555</t>
1556<t>
1557   A 303 response to a GET request indicates that the requested
1558   resource does not have a representation of its own that can be
1559   transferred by the server over HTTP.  The Location URI indicates a
1560   resource that is descriptive of the target resource, such that the
1561   follow-on representation might be useful to recipients without
1562   implying that it adequately represents the target resource.
1563   Note that answers to the questions of what can be represented, what
1564   representations are adequate, and what might be a useful description
1565   are outside the scope of HTTP and thus entirely determined by the
1566   URI owner(s).
1567</t>
1568<t>
1569   Except for responses to a HEAD request, the representation of a 303
1570   response SHOULD contain a short hypertext note with a hyperlink
1571   to the Location URI.
1572</t>
1573</section>
1574
1575<section title="304 Not Modified" anchor="status.304">
1576  <iref primary="true" item="304 Not Modified (status code)"/>
1577  <iref primary="true" item="Status Codes" subitem="304 Not Modified"/>
1578 
1579<t>
1580   The response to the request has not been modified since the conditions
1581   indicated by the client's conditional GET request, as defined in Section 4.1 of <xref target="Part4"/>.
1582</t>
1583</section>
1584
1585<section title="305 Use Proxy" anchor="status.305">
1586  <iref primary="true" item="305 Use Proxy (status code)"/>
1587  <iref primary="true" item="Status Codes" subitem="305 Use Proxy"/>
1588<t>
1589   The 305 status code was defined in a previous version of this specification
1590   (see <xref target="changes.from.rfc.2616"/>), and is now deprecated.
1591</t>
1592</section>
1593
1594<section title="306 (Unused)" anchor="status.306">
1595  <iref primary="true" item="306 (Unused) (status code)"/>
1596  <iref primary="true" item="Status Codes" subitem="306 (Unused)"/>
1597<t>
1598   The 306 status code was used in a previous version of the
1599   specification, is no longer used, and the code is reserved.
1600</t>
1601</section>
1602
1603<section title="307 Temporary Redirect" anchor="status.307">
1604  <iref primary="true" item="307 Temporary Redirect (status code)"/>
1605  <iref primary="true" item="Status Codes" subitem="307 Temporary Redirect"/>
1606<t>
1607   The target resource resides temporarily under a different URI.
1608   Since the redirection can change over time, the client SHOULD
1609   continue to use the effective request URI for future requests.
1610</t>
1611<t>
1612   The temporary URI SHOULD be given by the Location field in the
1613   response. Unless the request method was HEAD, the representation of the
1614   response SHOULD contain a short hypertext note with a hyperlink to
1615   the new URI(s), since many pre-HTTP/1.1 user agents do not
1616   understand the 307 status code. Therefore, the note SHOULD contain the
1617   information necessary for a user to repeat the original request on
1618   the new URI.
1619</t>
1620<t>
1621   If the 307 status code is received in response to a request method
1622   that is known to be "safe", as defined in <xref target="safe.methods"/>,
1623   then the request MAY be automatically redirected by the user agent without
1624   confirmation.  Otherwise, the user agent MUST NOT automatically redirect the
1625   request unless it can be confirmed by the user, since this might
1626   change the conditions under which the request was issued.
1627</t>
1628</section>
1629</section>
1630
1631<section title="Client Error 4xx" anchor="status.4xx">
1632<t>
1633   The 4xx class of status code is intended for cases in which the
1634   client seems to have erred. Except when responding to a HEAD request,
1635   the server SHOULD include a representation containing an explanation of the
1636   error situation, and whether it is a temporary or permanent
1637   condition. These status codes are applicable to any request method.
1638   User agents SHOULD display any included representation to the user.
1639</t>
1640<t>
1641   If the client is sending data, a server implementation using TCP
1642   SHOULD be careful to ensure that the client acknowledges receipt of
1643   the packet(s) containing the response, before the server closes the
1644   input connection. If the client continues sending data to the server
1645   after the close, the server's TCP stack will send a reset packet to
1646   the client, which might erase the client's unacknowledged input buffers
1647   before they can be read and interpreted by the HTTP application.
1648</t>
1649
1650<section title="400 Bad Request" anchor="status.400">
1651  <iref primary="true" item="400 Bad Request (status code)"/>
1652  <iref primary="true" item="Status Codes" subitem="400 Bad Request"/>
1653<t>
1654   The server cannot or will not process the request, due to a client error (e.g.,
1655   malformed syntax).</t>
1656</section>
1657
1658<section title="401 Unauthorized" anchor="status.401">
1659  <iref primary="true" item="401 Unauthorized (status code)"/>
1660  <iref primary="true" item="Status Codes" subitem="401 Unauthorized"/>
1661 
1662<t>
1663   The request requires user authentication (see Section 3.1 of <xref target="Part7"/>).
1664</t>
1665</section>
1666
1667<section title="402 Payment Required" anchor="status.402">
1668  <iref primary="true" item="402 Payment Required (status code)"/>
1669  <iref primary="true" item="Status Codes" subitem="402 Payment Required"/>
1670<t>
1671   This code is reserved for future use.
1672</t>
1673</section>
1674
1675<section title="403 Forbidden" anchor="status.403">
1676  <iref primary="true" item="403 Forbidden (status code)"/>
1677  <iref primary="true" item="Status Codes" subitem="403 Forbidden"/>
1678<t>
1679   The server understood the request, but refuses to authorize it. Providing
1680   different user authentication credentials might be successful, but any
1681   credentials that were provided in the request are insufficient. The request
1682   SHOULD NOT be repeated with the same credentials.
1683</t>
1684<t>
1685   If the request method was not HEAD and the server wishes to make
1686   public why the request has not been fulfilled, it SHOULD describe the
1687   reason for the refusal in the representation.  If the server does not wish to
1688   make this information available to the client, the status code 404
1689   (Not Found) MAY be used instead.
1690</t>
1691</section>
1692
1693<section title="404 Not Found" anchor="status.404">
1694  <iref primary="true" item="404 Not Found (status code)"/>
1695  <iref primary="true" item="Status Codes" subitem="404 Not Found"/>
1696<t>
1697   The server has not found anything matching the effective request URI. No
1698   indication is given of whether the condition is temporary or
1699   permanent. The 410 (Gone) status code SHOULD be used if the server
1700   knows, through some internally configurable mechanism, that an old
1701   resource is permanently unavailable and has no forwarding address.
1702   This status code is commonly used when the server does not wish to
1703   reveal exactly why the request has been refused, or when no other
1704   response is applicable.
1705</t>
1706</section>
1707
1708<section title="405 Method Not Allowed" anchor="status.405">
1709  <iref primary="true" item="405 Method Not Allowed (status code)"/>
1710  <iref primary="true" item="Status Codes" subitem="405 Method Not Allowed"/>
1711<t>
1712   The method specified in the Request-Line is not allowed for the target
1713   resource. The response MUST include an Allow header field containing a
1714   list of valid methods for the requested resource.
1715</t>
1716</section>
1717
1718<section title="406 Not Acceptable" anchor="status.406">
1719  <iref primary="true" item="406 Not Acceptable (status code)"/>
1720  <iref primary="true" item="Status Codes" subitem="406 Not Acceptable"/>
1721<t>
1722   The resource identified by the request is only capable of generating
1723   response representations which have content characteristics not acceptable
1724   according to the Accept and Accept-* header fields sent in the request
1725   (see Section 6 of <xref target="Part3"/>).
1726</t>
1727<t>
1728   Unless it was a HEAD request, the response SHOULD include a representation
1729   containing a list of available representation characteristics and location(s)
1730   from which the user or user agent can choose the one most
1731   appropriate. The data format is specified by the media type given
1732   in the Content-Type header field. Depending upon the format and the
1733   capabilities of the user agent, selection of the most appropriate
1734   choice MAY be performed automatically. However, this specification
1735   does not define any standard for such automatic selection.
1736</t>
1737<t><list>
1738  <t>
1739    Note: HTTP/1.1 servers are allowed to return responses which are
1740    not acceptable according to the accept header fields sent in the
1741    request. In some cases, this might even be preferable to sending a
1742    406 response. User agents are encouraged to inspect the header fields of
1743    an incoming response to determine if it is acceptable.
1744  </t>
1745</list></t>
1746<t>
1747   If the response could be unacceptable, a user agent SHOULD
1748   temporarily stop receipt of more data and query the user for a
1749   decision on further actions.
1750</t>
1751</section>
1752
1753<section title="407 Proxy Authentication Required" anchor="status.407">
1754  <iref primary="true" item="407 Proxy Authentication Required (status code)"/>
1755  <iref primary="true" item="Status Codes" subitem="407 Proxy Authentication Required"/>
1756<t>
1757   This code is similar to 401 (Unauthorized), but indicates that the
1758   client must first authenticate itself with the proxy (see Section 3.2 of <xref target="Part7"/>).
1759</t>
1760</section>
1761
1762<section title="408 Request Timeout" anchor="status.408">
1763  <iref primary="true" item="408 Request Timeout (status code)"/>
1764  <iref primary="true" item="Status Codes" subitem="408 Request Timeout"/>
1765<t>
1766   The client did not produce a request within the time that the server
1767   was prepared to wait. The client MAY repeat the request without
1768   modifications at any later time.
1769</t>
1770</section>
1771
1772<section title="409 Conflict" anchor="status.409">
1773  <iref primary="true" item="409 Conflict (status code)"/>
1774  <iref primary="true" item="Status Codes" subitem="409 Conflict"/>
1775<t>
1776   The request could not be completed due to a conflict with the current
1777   state of the resource. This code is only allowed in situations where
1778   it is expected that the user might be able to resolve the conflict
1779   and resubmit the request. The response body SHOULD include enough
1780   information for the user to recognize the source of the conflict.
1781   Ideally, the response representation would include enough information for the
1782   user or user agent to fix the problem; however, that might not be
1783   possible and is not required.
1784</t>
1785<t>
1786   Conflicts are most likely to occur in response to a PUT request. For
1787   example, if versioning were being used and the representation being PUT
1788   included changes to a resource which conflict with those made by an
1789   earlier (third-party) request, the server might use the 409 response
1790   to indicate that it can't complete the request. In this case, the
1791   response representation would likely contain a list of the differences
1792   between the two versions in a format defined by the response
1793   Content-Type.
1794</t>
1795</section>
1796
1797<section title="410 Gone" anchor="status.410">
1798  <iref primary="true" item="410 Gone (status code)"/>
1799  <iref primary="true" item="Status Codes" subitem="410 Gone"/>
1800<t>
1801   The target resource is no longer available at the server and no
1802   forwarding address is known. This condition is expected to be
1803   considered permanent. Clients with link editing capabilities SHOULD
1804   delete references to the effective request URI after user approval. If the
1805   server does not know, or has no facility to determine, whether or not
1806   the condition is permanent, the status code 404 (Not Found) SHOULD be
1807   used instead.
1808</t>
1809<t>
1810   The 410 response is primarily intended to assist the task of web
1811   maintenance by notifying the recipient that the resource is
1812   intentionally unavailable and that the server owners desire that
1813   remote links to that resource be removed. Such an event is common for
1814   limited-time, promotional services and for resources belonging to
1815   individuals no longer working at the server's site. It is not
1816   necessary to mark all permanently unavailable resources as "gone" or
1817   to keep the mark for any length of time — that is left to the
1818   discretion of the server owner.
1819</t>
1820<t>
1821   Caches MAY use a heuristic (see Section 2.3.1.1 of <xref target="Part6"/>) to determine freshness
1822   for 410 responses.
1823</t>
1824
1825</section>
1826
1827<section title="411 Length Required" anchor="status.411">
1828  <iref primary="true" item="411 Length Required (status code)"/>
1829  <iref primary="true" item="Status Codes" subitem="411 Length Required"/>
1830<t>
1831   The server refuses to accept the request without a defined Content-Length.
1832   The client MAY repeat the request if it adds a valid
1833   Content-Length header field containing the length of the message-body
1834   in the request message.
1835</t>
1836</section>
1837
1838<section title="412 Precondition Failed" anchor="status.412">
1839  <iref primary="true" item="412 Precondition Failed (status code)"/>
1840  <iref primary="true" item="Status Codes" subitem="412 Precondition Failed"/>
1841 
1842<t>
1843   The precondition given in one or more of the header fields
1844   evaluated to false when it was tested on the server, as defined in
1845   Section 4.2 of <xref target="Part4"/>.
1846</t>
1847</section>
1848
1849<section title="413 Request Representation Too Large" anchor="status.413">
1850  <iref primary="true" item="413 Request Representation Too Large (status code)"/>
1851  <iref primary="true" item="Status Codes" subitem="413 Request Representation Too Large"/>
1852<t>
1853   The server is refusing to process a request because the request
1854   representation is larger than the server is willing or able to process. The
1855   server MAY close the connection to prevent the client from continuing
1856   the request.
1857</t>
1858<t>
1859   If the condition is temporary, the server SHOULD include a Retry-After
1860   header field to indicate that it is temporary and after what
1861   time the client MAY try again.
1862</t>
1863</section>
1864
1865<section title="414 URI Too Long" anchor="status.414">
1866  <iref primary="true" item="414 URI Too Long (status code)"/>
1867  <iref primary="true" item="Status Codes" subitem="414 URI Too Long"/>
1868<t>
1869   The server is refusing to service the request because the effective request URI
1870   is longer than the server is willing to interpret. This rare
1871   condition is only likely to occur when a client has improperly
1872   converted a POST request to a GET request with long query
1873   information, when the client has descended into a URI "black hole" of
1874   redirection (e.g., a redirected URI prefix that points to a suffix of
1875   itself), or when the server is under attack by a client attempting to
1876   exploit security holes present in some servers using fixed-length
1877   buffers for reading or manipulating the effective request URI.
1878</t>
1879</section>
1880
1881<section title="415 Unsupported Media Type" anchor="status.415">
1882  <iref primary="true" item="415 Unsupported Media Type (status code)"/>
1883  <iref primary="true" item="Status Codes" subitem="415 Unsupported Media Type"/>
1884<t>
1885   The server is refusing to service the request because the request
1886   payload is in a format not supported by this request method on the
1887   target resource.
1888</t>
1889</section>
1890
1891<section title="416 Requested Range Not Satisfiable" anchor="status.416">
1892  <iref primary="true" item="416 Requested Range Not Satisfiable (status code)"/>
1893  <iref primary="true" item="Status Codes" subitem="416 Requested Range Not Satisfiable"/>
1894 
1895<t>
1896   The request included a Range header field (Section 5.4 of <xref target="Part5"/>) and none of
1897   the range-specifier values in this field overlap the current extent
1898   of the selected resource. See Section 3.2 of <xref target="Part5"/>.
1899</t>
1900</section>
1901
1902<section title="417 Expectation Failed" anchor="status.417">
1903  <iref primary="true" item="417 Expectation Failed (status code)"/>
1904  <iref primary="true" item="Status Codes" subitem="417 Expectation Failed"/>
1905<t>
1906   The expectation given in an Expect header field (see <xref target="header.expect"/>)
1907   could not be met by this server, or, if the server is a proxy,
1908   the server has unambiguous evidence that the request could not be met
1909   by the next-hop server.
1910</t>
1911</section>
1912
1913<section title="426 Upgrade Required" anchor="status.426">
1914  <iref primary="true" item="426 Upgrade Required (status code)"/>
1915  <iref primary="true" item="Status Codes" subitem="426 Upgrade Required"/>
1916<t>
1917   The request can not be completed without a prior protocol upgrade. This
1918   response MUST include an Upgrade header field (Section 9.8 of <xref target="Part1"/>)
1919   specifying the required protocols.
1920</t>
1921<figure>
1922<preamble>Example:</preamble>
1923<artwork type="message/http; msgtype=&#34;request&#34;"><![CDATA[
1924  HTTP/1.1 426 Upgrade Required
1925  Upgrade: HTTP/2.0
1926  Connection: Upgrade
1927 
1928  ]]></artwork></figure>
1929<t>
1930   The server SHOULD include a message body in the 426 response which
1931   indicates in human readable form the reason for the error and describes any
1932   alternative courses which may be available to the user.
1933</t>
1934</section>
1935</section>
1936
1937<section title="Server Error 5xx" anchor="status.5xx">
1938<t>
1939   Response status codes beginning with the digit "5" indicate cases in
1940   which the server is aware that it has erred or is incapable of
1941   performing the request. Except when responding to a HEAD request, the
1942   server SHOULD include a representation containing an explanation of the
1943   error situation, and whether it is a temporary or permanent
1944   condition. User agents SHOULD display any included representation to the
1945   user. These response codes are applicable to any request method.
1946</t>
1947
1948<section title="500 Internal Server Error" anchor="status.500">
1949  <iref primary="true" item="500 Internal Server Error (status code)"/>
1950  <iref primary="true" item="Status Codes" subitem="500 Internal Server Error"/>
1951<t>
1952   The server encountered an unexpected condition which prevented it
1953   from fulfilling the request.
1954</t>
1955</section>
1956
1957<section title="501 Not Implemented" anchor="status.501">
1958  <iref primary="true" item="501 Not Implemented (status code)"/>
1959  <iref primary="true" item="Status Codes" subitem="501 Not Implemented"/>
1960<t>
1961   The server does not support the functionality required to fulfill the
1962   request. This is the appropriate response when the server does not
1963   recognize the request method and is not capable of supporting it for
1964   any resource.
1965</t>
1966</section>
1967
1968<section title="502 Bad Gateway" anchor="status.502">
1969  <iref primary="true" item="502 Bad Gateway (status code)"/>
1970  <iref primary="true" item="Status Codes" subitem="502 Bad Gateway"/>
1971<t>
1972   The server, while acting as a gateway or proxy, received an invalid
1973   response from the upstream server it accessed in attempting to
1974   fulfill the request.
1975</t>
1976</section>
1977
1978<section title="503 Service Unavailable" anchor="status.503">
1979  <iref primary="true" item="503 Service Unavailable (status code)"/>
1980  <iref primary="true" item="Status Codes" subitem="503 Service Unavailable"/>
1981<t>
1982   The server is currently unable or unwilling to handle the request due to
1983   reasons such as temporary overloading, maintenance of the server, or rate
1984   limiting of the client.
1985</t>
1986<t>
1987   The implication is that this is a temporary condition which will be
1988   alleviated after some delay. If known, the length of the delay MAY be
1989   indicated in a Retry-After header field (<xref target="header.retry-after"/>).
1990   If no Retry-After is given, the client SHOULD handle the response as it
1991   would for a 500 response.
1992</t>
1993<t><list>
1994  <t>
1995    Note: The existence of the 503 status code does not imply that a
1996    server must use it when becoming overloaded. Some servers might wish
1997    to simply refuse the connection.
1998  </t>
1999</list></t>
2000</section>
2001
2002<section title="504 Gateway Timeout" anchor="status.504">
2003  <iref primary="true" item="504 Gateway Timeout (status code)"/>
2004  <iref primary="true" item="Status Codes" subitem="504 Gateway Timeout"/>
2005<t>
2006   The server, while acting as a gateway or proxy, did not receive a
2007   timely response from the upstream server specified by the URI (e.g.,
2008   HTTP, FTP, LDAP) or some other auxiliary server (e.g., DNS) it needed
2009   to access in attempting to complete the request.
2010</t>
2011<t><list>
2012  <t>
2013    Note to implementors: some deployed proxies are known to
2014    return 400 or 500 when DNS lookups time out.
2015  </t>
2016</list></t>
2017</section>
2018
2019<section title="505 HTTP Version Not Supported" anchor="status.505">
2020  <iref primary="true" item="505 HTTP Version Not Supported (status code)"/>
2021  <iref primary="true" item="Status Codes" subitem="505 HTTP Version Not Supported"/>
2022<t>
2023   The server does not support, or refuses to support, the protocol
2024   version that was used in the request message. The server is
2025   indicating that it is unable or unwilling to complete the request
2026   using the same major version as the client, as described in Section 2.6 of <xref target="Part1"/>,
2027   other than with this error message. The response SHOULD contain
2028   a representation describing why that version is not supported and what other
2029   protocols are supported by that server.
2030</t>
2031
2032</section>
2033</section>
2034</section>
2035
2036
2037<section title="Header Field Definitions" anchor="header.fields">
2038<t>
2039   This section defines the syntax and semantics of HTTP/1.1 header fields
2040   related to request and response semantics.
2041</t>
2042
2043<section title="Allow" anchor="header.allow">
2044  <iref primary="true" item="Allow header field"/>
2045  <iref primary="true" item="Header Fields" subitem="Allow"/>
2046 
2047<t>
2048   The "Allow" header field lists the set of methods advertised as
2049   supported by the target resource. The purpose of this field is strictly to
2050   inform the recipient of valid request methods associated with the resource.
2051</t>
2052<figure><iref primary="true" item="Grammar" subitem="Allow"/><artwork type="abnf2616"><![CDATA[
2053  Allow = #Method
2054]]></artwork></figure>
2055<t>
2056   Example of use:
2057</t>
2058<figure><artwork type="example"><![CDATA[
2059  Allow: GET, HEAD, PUT
2060]]></artwork></figure>
2061<t>
2062   The actual set of allowed methods is defined by the origin server at the
2063   time of each request.
2064</t>
2065<t>
2066   A proxy MUST NOT modify the Allow header field — it does not need to
2067   understand all the methods specified in order to handle them according to
2068   the generic message handling rules.
2069</t>
2070</section>
2071
2072<section title="Expect" anchor="header.expect">
2073  <iref primary="true" item="Expect header field"/>
2074  <iref primary="true" item="Header Fields" subitem="Expect"/>
2075 
2076 
2077 
2078 
2079<t>
2080   The "Expect" header field is used to indicate that particular
2081   server behaviors are required by the client.
2082</t>
2083<figure><iref primary="true" item="Grammar" subitem="Expect"/><iref primary="true" item="Grammar" subitem="expectation"/><iref primary="true" item="Grammar" subitem="expectation-extension"/><iref primary="true" item="Grammar" subitem="expect-params"/><artwork type="abnf2616"><![CDATA[
2084  Expect       = 1#expectation
2085 
2086  expectation  = "100-continue" / expectation-extension
2087  expectation-extension = token [ "=" ( token / quoted-string )
2088                           *expect-params ]
2089  expect-params = ";" token [ "=" ( token / quoted-string ) ]
2090]]></artwork></figure>
2091<t>
2092   A server that does not understand or is unable to comply with any of
2093   the expectation values in the Expect field of a request MUST respond
2094   with appropriate error status code. The server MUST respond with a 417
2095   (Expectation Failed) status code if any of the expectations cannot be met
2096   or, if there are other problems with the request, some other 4xx
2097   status code.
2098</t>
2099<t>
2100   This header field is defined with extensible syntax to allow for
2101   future extensions. If a server receives a request containing an
2102   Expect field that includes an expectation-extension that it does not
2103   support, it MUST respond with a 417 (Expectation Failed) status code.
2104</t>
2105<t>
2106   Comparison of expectation values is case-insensitive for unquoted
2107   tokens (including the 100-continue token), and is case-sensitive for
2108   quoted-string expectation-extensions.
2109</t>
2110<t>
2111   The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST
2112   return a 417 (Expectation Failed) status code if it receives a request
2113   with an expectation that it cannot meet. However, the Expect
2114   header field itself is end-to-end; it MUST be forwarded if the
2115   request is forwarded.
2116</t>
2117<t>
2118   Many older HTTP/1.0 and HTTP/1.1 applications do not understand the
2119   Expect header field.
2120</t>
2121<t>
2122   See Section 7.2.3 of <xref target="Part1"/> for the use of the 100 (Continue) status code.
2123</t>
2124</section>
2125
2126<section title="From" anchor="header.from">
2127  <iref primary="true" item="From header field"/>
2128  <iref primary="true" item="Header Fields" subitem="From"/>
2129 
2130 
2131<t>
2132   The "From" header field, if given, SHOULD contain an Internet
2133   e-mail address for the human user who controls the requesting user
2134   agent. The address SHOULD be machine-usable, as defined by "mailbox"
2135   in Section 3.4 of <xref target="RFC5322"/>:
2136</t>
2137<figure><iref primary="true" item="Grammar" subitem="From"/><artwork type="abnf2616"><![CDATA[
2138  From    = mailbox
2139 
2140  mailbox = <mailbox, defined in [RFC5322], Section 3.4>
2141]]></artwork></figure>
2142<t>
2143   An example is:
2144</t>
2145<figure><artwork type="example"><![CDATA[
2146  From: webmaster@example.org
2147]]></artwork></figure>
2148<t>
2149   This header field MAY be used for logging purposes and as a means for
2150   identifying the source of invalid or unwanted requests. It SHOULD NOT
2151   be used as an insecure form of access protection. The interpretation
2152   of this field is that the request is being performed on behalf of the
2153   person given, who accepts responsibility for the method performed. In
2154   particular, robot agents SHOULD include this header field so that the
2155   person responsible for running the robot can be contacted if problems
2156   occur on the receiving end.
2157</t>
2158<t>
2159   The Internet e-mail address in this field MAY be separate from the
2160   Internet host which issued the request. For example, when a request
2161   is passed through a proxy the original issuer's address SHOULD be
2162   used.
2163</t>
2164<t>
2165   The client SHOULD NOT  send the From header field without the user's
2166   approval, as it might conflict with the user's privacy interests or
2167   their site's security policy. It is strongly recommended that the
2168   user be able to disable, enable, and modify the value of this field
2169   at any time prior to a request.
2170</t>
2171</section>
2172
2173<section title="Location" anchor="header.location">
2174  <iref primary="true" item="Location header field"/>
2175  <iref primary="true" item="Header Fields" subitem="Location"/>
2176 
2177<t>
2178   The "Location" header field is used to identify a newly created
2179   resource, or to redirect the recipient to a different location for
2180   completion of the request.
2181</t>
2182<t>
2183   For 201 (Created) responses, the Location is the URI of the new resource
2184   which was created by the request. For 3xx responses, the location SHOULD
2185   indicate the server's preferred URI for automatic redirection to the
2186   resource.
2187</t>
2188<t>
2189   The field value consists of a single URI-reference. When it has the form
2190   of a relative reference (<xref target="RFC3986"/>, Section 4.2),
2191   the final value is computed by resolving it against the effective request
2192   URI (<xref target="RFC3986"/>, Section 5).
2193</t>
2194<figure><iref primary="true" item="Grammar" subitem="Location"/><artwork type="abnf2616"><![CDATA[
2195  Location = URI-reference
2196]]></artwork></figure>
2197<figure>
2198<preamble>Examples are:</preamble><!--DO NOT DARE changing the vertical WSP below, it's necessary this way for xml2rfc-->
2199<artwork type="example"><![CDATA[
2200  Location: http://www.example.org/pub/WWW/People.html#tim
2201]]></artwork></figure><figure><artwork type="example"><![CDATA[  Location: /index.html
2202]]></artwork></figure>
2203<t>
2204   There are circumstances in which a fragment identifier in a Location URI
2205   would not be appropriate. For instance, when it appears in a 201 Created
2206   response, where the Location header field specifies the URI for the entire
2207   created resource.
2208</t>
2209<t><list>
2210  <t>
2211    Note: This specification does not define precedence rules
2212    for the case where the original URI, as navigated to by the user
2213    agent, and the Location header field value both contain fragment
2214    identifiers. Thus be aware that including fragment identifiers might
2215    inconvenience anyone relying on the semantics of the original URI's
2216    fragment identifier.
2217  </t>
2218</list></t>
2219<t><list>
2220  <t>
2221    Note: The Content-Location header field (Section 6.7 of <xref target="Part3"/>) differs
2222    from Location in that the Content-Location identifies the most specific
2223    resource corresponding to the enclosed representation.
2224    It is therefore possible for a response to contain header fields for
2225    both Location and Content-Location.
2226  </t>
2227</list></t>
2228</section>
2229
2230<section title="Max-Forwards" anchor="header.max-forwards">
2231  <iref primary="true" item="Max-Forwards header field"/>
2232  <iref primary="true" item="Header Fields" subitem="Max-Forwards"/>
2233 
2234<t>
2235   The "Max-Forwards" header field provides a mechanism with the
2236   TRACE (<xref target="TRACE"/>) and OPTIONS (<xref target="OPTIONS"/>)
2237   methods to limit the number of times that the request is forwarded by
2238   proxies. This can be useful when the client is attempting to
2239   trace a request which appears to be failing or looping in mid-chain.
2240</t>
2241<figure><iref primary="true" item="Grammar" subitem="Max-Forwards"/><artwork type="abnf2616"><![CDATA[
2242  Max-Forwards = 1*DIGIT
2243]]></artwork></figure>
2244<t>
2245   The Max-Forwards value is a decimal integer indicating the remaining
2246   number of times this request message can be forwarded.
2247</t>
2248<t>
2249   Each recipient of a TRACE or OPTIONS request
2250   containing a Max-Forwards header field MUST check and update its
2251   value prior to forwarding the request. If the received value is zero
2252   (0), the recipient MUST NOT forward the request; instead, it MUST
2253   respond as the final recipient. If the received Max-Forwards value is
2254   greater than zero, then the forwarded message MUST contain an updated
2255   Max-Forwards field with a value decremented by one (1).
2256</t>
2257<t>
2258   The Max-Forwards header field MAY be ignored for all other request
2259   methods.
2260</t>
2261</section>
2262
2263<section title="Referer" anchor="header.referer">
2264  <iref primary="true" item="Referer header field"/>
2265  <iref primary="true" item="Header Fields" subitem="Referer"/>
2266 
2267<t>
2268   The "Referer" [sic] header field allows the client to specify the
2269   URI of the resource from which the effective request URI was obtained (the
2270   "referrer", although the header field is misspelled.).
2271</t>
2272<t>
2273   The Referer header field allows servers to generate lists of back-links to
2274   resources for interest, logging, optimized caching, etc. It also allows
2275   obsolete or mistyped links to be traced for maintenance. Some servers use
2276   Referer as a means of controlling where they allow links from (so-called
2277   "deep linking"), but legitimate requests do not always
2278   contain a Referer header field.
2279</t>
2280<t>
2281   If the effective request URI was obtained from a source that does not have its own
2282   URI (e.g., input from the user keyboard), the Referer field MUST either be
2283   sent with the value "about:blank", or not be sent at all. Note that this
2284   requirement does not apply to sources with non-HTTP URIs (e.g., FTP).
2285</t>
2286<figure><iref primary="true" item="Grammar" subitem="Referer"/><artwork type="abnf2616"><![CDATA[
2287  Referer = absolute-URI / partial-URI
2288]]></artwork></figure>
2289<t>
2290   Example:
2291</t>
2292<figure><artwork type="example"><![CDATA[
2293  Referer: http://www.example.org/hypertext/Overview.html
2294]]></artwork></figure>
2295<t>
2296   If the field value is a relative URI, it SHOULD be interpreted
2297   relative to the effective request URI. The URI MUST NOT include a fragment. See
2298   <xref target="encoding.sensitive.information.in.uris"/> for security considerations.
2299</t>
2300</section>
2301
2302<section title="Retry-After" anchor="header.retry-after">
2303  <iref primary="true" item="Retry-After header field"/>
2304  <iref primary="true" item="Header Fields" subitem="Retry-After"/>
2305 
2306<t>
2307   The header "Retry-After" field can be used with a 503 (Service
2308   Unavailable) response to indicate how long the service is expected to
2309   be unavailable to the requesting client. This field MAY also be used
2310   with any 3xx (Redirection) response to indicate the minimum time the
2311   user-agent is asked wait before issuing the redirected request.
2312</t>
2313<t>
2314   The value of this field can be either an HTTP-date or an integer number
2315   of seconds (in decimal) after the time of the response.
2316</t>
2317<figure><iref primary="true" item="Grammar" subitem="Retry-After"/><artwork type="abnf2616"><![CDATA[
2318  Retry-After = HTTP-date / delta-seconds
2319]]></artwork></figure>
2320<t anchor="rule.delta-seconds">
2321 
2322   Time spans are non-negative decimal integers, representing time in
2323   seconds.
2324</t>
2325<figure><iref primary="true" item="Grammar" subitem="delta-seconds"/><artwork type="abnf2616"><![CDATA[
2326  delta-seconds  = 1*DIGIT
2327]]></artwork></figure>
2328<t>
2329   Two examples of its use are
2330</t>
2331<figure><artwork type="example"><![CDATA[
2332  Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
2333  Retry-After: 120
2334]]></artwork></figure>
2335<t>
2336   In the latter example, the delay is 2 minutes.
2337</t>
2338</section>
2339
2340<section title="Server" anchor="header.server">
2341  <iref primary="true" item="Server header field"/>
2342  <iref primary="true" item="Header Fields" subitem="Server"/>
2343 
2344<t>
2345   The "Server" header field contains information about the
2346   software used by the origin server to handle the request.
2347</t>
2348<t>
2349   The field can contain multiple product tokens (Section 6.3 of <xref target="Part1"/>) and
2350   comments (Section 3.2 of <xref target="Part1"/>) identifying the server and any significant
2351   subproducts. The product tokens are listed in order of their significance
2352   for identifying the application.
2353</t>
2354<figure><iref primary="true" item="Grammar" subitem="Server"/><artwork type="abnf2616"><![CDATA[
2355  Server = product *( RWS ( product / comment ) )
2356]]></artwork></figure>
2357<t>
2358   Example:
2359</t>
2360<figure><artwork type="example"><![CDATA[
2361  Server: CERN/3.0 libwww/2.17
2362]]></artwork></figure>
2363<t>
2364   If the response is being forwarded through a proxy, the proxy
2365   application MUST NOT modify the Server header field. Instead, it
2366   MUST include a Via field (as described in Section 9.9 of <xref target="Part1"/>).
2367</t>
2368<t><list>
2369  <t>
2370    Note: Revealing the specific software version of the server might
2371    allow the server machine to become more vulnerable to attacks
2372    against software that is known to contain security holes. Server
2373    implementors are encouraged to make this field a configurable
2374    option.
2375  </t>
2376</list></t>
2377</section>
2378
2379<section title="User-Agent" anchor="header.user-agent">
2380  <iref primary="true" item="User-Agent header field"/>
2381  <iref primary="true" item="Header Fields" subitem="User-Agent"/>
2382 
2383<t>
2384   The "User-Agent" header field contains information about the user
2385   agent originating the request. User agents SHOULD include this field with
2386   requests.
2387</t>
2388<t>
2389   Typically, it is used for statistical purposes, the tracing of protocol
2390   violations, and tailoring responses to avoid particular user agent
2391   limitations.
2392</t>
2393<t>
2394   The field can contain multiple product tokens (Section 6.3 of <xref target="Part1"/>)
2395   and comments (Section 3.2 of <xref target="Part1"/>) identifying the agent and its
2396   significant subproducts. By convention, the product tokens are listed in
2397   order of their significance for identifying the application.
2398</t>
2399<t>
2400   Because this field is usually sent on every request a user agent makes,
2401   implementations are encouraged not to include needlessly fine-grained
2402   detail, and to limit (or even prohibit) the addition of subproducts by third
2403   parties. Overly long and detailed User-Agent field values make requests
2404   larger and can also be used to identify ("fingerprint") the user against
2405   their wishes.
2406</t>
2407<t>
2408   Likewise, implementations are encouraged not to use the product tokens of
2409   other implementations in order to declare compatibility with them, as this
2410   circumvents the purpose of the field. Finally, they are encouraged not to
2411   use comments to identify products; doing so makes the field value more
2412   difficult to parse.
2413</t>
2414<figure><iref primary="true" item="Grammar" subitem="User-Agent"/><artwork type="abnf2616"><![CDATA[
2415  User-Agent = product *( RWS ( product / comment ) )
2416]]></artwork></figure>
2417<t>
2418   Example:
2419</t>
2420<figure><artwork type="example"><![CDATA[
2421  User-Agent: CERN-LineMode/2.15 libwww/2.17b3
2422]]></artwork></figure>
2423</section>
2424
2425</section>
2426
2427<section title="IANA Considerations" anchor="IANA.considerations">
2428
2429<section title="Method Registry" anchor="method.registration">
2430<t>
2431  The registration procedure for HTTP request methods is defined by
2432  <xref target="method.registry"/> of this document.
2433</t>
2434<t>
2435   The HTTP Method Registry shall be created at <eref target="http://www.iana.org/assignments/http-methods"/>
2436   and be populated with the registrations below:
2437</t>
2438
2439<!--AUTOGENERATED FROM extract-method-defs.xslt, do not edit manually-->
2440<texttable align="left" suppress-title="true" anchor="iana.method.registration.table">
2441   <ttcol>Method</ttcol>
2442   <ttcol>Safe</ttcol>
2443   <ttcol>Reference</ttcol>
2444   <c>CONNECT</c>
2445   <c>no</c>
2446   <c>
2447      <xref target="CONNECT"/>
2448   </c>
2449   <c>DELETE</c>
2450   <c>no</c>
2451   <c>
2452      <xref target="DELETE"/>
2453   </c>
2454   <c>GET</c>
2455   <c>yes</c>
2456   <c>
2457      <xref target="GET"/>
2458   </c>
2459   <c>HEAD</c>
2460   <c>yes</c>
2461   <c>
2462      <xref target="HEAD"/>
2463   </c>
2464   <c>OPTIONS</c>
2465   <c>yes</c>
2466   <c>
2467      <xref target="OPTIONS"/>
2468   </c>
2469   <c>POST</c>
2470   <c>no</c>
2471   <c>
2472      <xref target="POST"/>
2473   </c>
2474   <c>PUT</c>
2475   <c>no</c>
2476   <c>
2477      <xref target="PUT"/>
2478   </c>
2479   <c>TRACE</c>
2480   <c>yes</c>
2481   <c>
2482      <xref target="TRACE"/>
2483   </c>
2484</texttable>
2485<!--(END)-->
2486
2487</section>
2488
2489<section title="Status Code Registry" anchor="status.code.registration">
2490<t>
2491   The registration procedure for HTTP Status Codes — previously defined
2492   in Section 7.1 of <xref target="RFC2817"/> — is now defined
2493   by <xref target="status.code.registry"/> of this document.
2494</t>
2495<t>
2496   The HTTP Status Code Registry located at <eref target="http://www.iana.org/assignments/http-status-codes"/>
2497   shall be updated with the registrations below:
2498</t>
2499
2500<!--AUTOGENERATED FROM extract-status-code-defs.xslt, do not edit manually-->
2501<texttable align="left" suppress-title="true" anchor="iana.status.code.registration.table">
2502   <ttcol>Value</ttcol>
2503   <ttcol>Description</ttcol>
2504   <ttcol>Reference</ttcol>
2505   <c>100</c>
2506   <c>Continue</c>
2507   <c>
2508      <xref target="status.100"/>
2509   </c>
2510   <c>101</c>
2511   <c>Switching Protocols</c>
2512   <c>
2513      <xref target="status.101"/>
2514   </c>
2515   <c>200</c>
2516   <c>OK</c>
2517   <c>
2518      <xref target="status.200"/>
2519   </c>
2520   <c>201</c>
2521   <c>Created</c>
2522   <c>
2523      <xref target="status.201"/>
2524   </c>
2525   <c>202</c>
2526   <c>Accepted</c>
2527   <c>
2528      <xref target="status.202"/>
2529   </c>
2530   <c>203</c>
2531   <c>Non-Authoritative Information</c>
2532   <c>
2533      <xref target="status.203"/>
2534   </c>
2535   <c>204</c>
2536   <c>No Content</c>
2537   <c>
2538      <xref target="status.204"/>
2539   </c>
2540   <c>205</c>
2541   <c>Reset Content</c>
2542   <c>
2543      <xref target="status.205"/>
2544   </c>
2545   <c>300</c>
2546   <c>Multiple Choices</c>
2547   <c>
2548      <xref target="status.300"/>
2549   </c>
2550   <c>301</c>
2551   <c>Moved Permanently</c>
2552   <c>
2553      <xref target="status.301"/>
2554   </c>
2555   <c>302</c>
2556   <c>Found</c>
2557   <c>
2558      <xref target="status.302"/>
2559   </c>
2560   <c>303</c>
2561   <c>See Other</c>
2562   <c>
2563      <xref target="status.303"/>
2564   </c>
2565   <c>305</c>
2566   <c>Use Proxy</c>
2567   <c>
2568      <xref target="status.305"/>
2569   </c>
2570   <c>306</c>
2571   <c>(Unused)</c>
2572   <c>
2573      <xref target="status.306"/>
2574   </c>
2575   <c>307</c>
2576   <c>Temporary Redirect</c>
2577   <c>
2578      <xref target="status.307"/>
2579   </c>
2580   <c>400</c>
2581   <c>Bad Request</c>
2582   <c>
2583      <xref target="status.400"/>
2584   </c>
2585   <c>402</c>
2586   <c>Payment Required</c>
2587   <c>
2588      <xref target="status.402"/>
2589   </c>
2590   <c>403</c>
2591   <c>Forbidden</c>
2592   <c>
2593      <xref target="status.403"/>
2594   </c>
2595   <c>404</c>
2596   <c>Not Found</c>
2597   <c>
2598      <xref target="status.404"/>
2599   </c>
2600   <c>405</c>
2601   <c>Method Not Allowed</c>
2602   <c>
2603      <xref target="status.405"/>
2604   </c>
2605   <c>406</c>
2606   <c>Not Acceptable</c>
2607   <c>
2608      <xref target="status.406"/>
2609   </c>
2610   <c>407</c>
2611   <c>Proxy Authentication Required</c>
2612   <c>
2613      <xref target="status.407"/>
2614   </c>
2615   <c>408</c>
2616   <c>Request Timeout</c>
2617   <c>
2618      <xref target="status.408"/>
2619   </c>
2620   <c>409</c>
2621   <c>Conflict</c>
2622   <c>
2623      <xref target="status.409"/>
2624   </c>
2625   <c>410</c>
2626   <c>Gone</c>
2627   <c>
2628      <xref target="status.410"/>
2629   </c>
2630   <c>411</c>
2631   <c>Length Required</c>
2632   <c>
2633      <xref target="status.411"/>
2634   </c>
2635   <c>413</c>
2636   <c>Request Representation Too Large</c>
2637   <c>
2638      <xref target="status.413"/>
2639   </c>
2640   <c>414</c>
2641   <c>URI Too Long</c>
2642   <c>
2643      <xref target="status.414"/>
2644   </c>
2645   <c>415</c>
2646   <c>Unsupported Media Type</c>
2647   <c>
2648      <xref target="status.415"/>
2649   </c>
2650   <c>417</c>
2651   <c>Expectation Failed</c>
2652   <c>
2653      <xref target="status.417"/>
2654   </c>
2655   <c>426</c>
2656   <c>Upgrade Required</c>
2657   <c>
2658      <xref target="status.426"/>
2659   </c>
2660   <c>500</c>
2661   <c>Internal Server Error</c>
2662   <c>
2663      <xref target="status.500"/>
2664   </c>
2665   <c>501</c>
2666   <c>Not Implemented</c>
2667   <c>
2668      <xref target="status.501"/>
2669   </c>
2670   <c>502</c>
2671   <c>Bad Gateway</c>
2672   <c>
2673      <xref target="status.502"/>
2674   </c>
2675   <c>503</c>
2676   <c>Service Unavailable</c>
2677   <c>
2678      <xref target="status.503"/>
2679   </c>
2680   <c>504</c>
2681   <c>Gateway Timeout</c>
2682   <c>
2683      <xref target="status.504"/>
2684   </c>
2685   <c>505</c>
2686   <c>HTTP Version Not Supported</c>
2687   <c>
2688      <xref target="status.505"/>
2689   </c>
2690</texttable>
2691<!--(END)-->
2692
2693</section>
2694<section title="Header Field Registration" anchor="header.field.registration">
2695<t>
2696   The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> shall be updated
2697   with the permanent registrations below (see <xref target="RFC3864"/>):
2698</t>
2699
2700<!--AUTOGENERATED FROM extract-header-defs.xslt, do not edit manually-->
2701<texttable align="left" suppress-title="true" anchor="iana.header.registration.table">
2702   <ttcol>Header Field Name</ttcol>
2703   <ttcol>Protocol</ttcol>
2704   <ttcol>Status</ttcol>
2705   <ttcol>Reference</ttcol>
2706
2707   <c>Allow</c>
2708   <c>http</c>
2709   <c>standard</c>
2710   <c>
2711      <xref target="header.allow"/>
2712   </c>
2713   <c>Expect</c>
2714   <c>http</c>
2715   <c>standard</c>
2716   <c>
2717      <xref target="header.expect"/>
2718   </c>
2719   <c>From</c>
2720   <c>http</c>
2721   <c>standard</c>
2722   <c>
2723      <xref target="header.from"/>
2724   </c>
2725   <c>Location</c>
2726   <c>http</c>
2727   <c>standard</c>
2728   <c>
2729      <xref target="header.location"/>
2730   </c>
2731   <c>Max-Forwards</c>
2732   <c>http</c>
2733   <c>standard</c>
2734   <c>
2735      <xref target="header.max-forwards"/>
2736   </c>
2737   <c>Referer</c>
2738   <c>http</c>
2739   <c>standard</c>
2740   <c>
2741      <xref target="header.referer"/>
2742   </c>
2743   <c>Retry-After</c>
2744   <c>http</c>
2745   <c>standard</c>
2746   <c>
2747      <xref target="header.retry-after"/>
2748   </c>
2749   <c>Server</c>
2750   <c>http</c>
2751   <c>standard</c>
2752   <c>
2753      <xref target="header.server"/>
2754   </c>
2755   <c>User-Agent</c>
2756   <c>http</c>
2757   <c>standard</c>
2758   <c>
2759      <xref target="header.user-agent"/>
2760   </c>
2761</texttable>
2762<!--(END)-->
2763
2764<t>
2765   The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".
2766</t>
2767</section>
2768</section>
2769
2770<section title="Security Considerations" anchor="security.considerations">
2771<t>
2772   This section is meant to inform application developers, information
2773   providers, and users of the security limitations in HTTP/1.1 as
2774   described by this document. The discussion does not include
2775   definitive solutions to the problems revealed, though it does make
2776   some suggestions for reducing security risks.
2777</t>
2778
2779<section title="Transfer of Sensitive Information" anchor="security.sensitive">
2780<t>
2781   Like any generic data transfer protocol, HTTP cannot regulate the
2782   content of the data that is transferred, nor is there any a priori
2783   method of determining the sensitivity of any particular piece of
2784   information within the context of any given request. Therefore,
2785   applications SHOULD supply as much control over this information as
2786   possible to the provider of that information. Four header fields are
2787   worth special mention in this context: Server, Via, Referer and From.
2788</t>
2789<t>
2790   Revealing the specific software version of the server might allow the
2791   server machine to become more vulnerable to attacks against software
2792   that is known to contain security holes. Implementors SHOULD make the
2793   Server header field a configurable option.
2794</t>
2795<t>
2796   Proxies which serve as a portal through a network firewall SHOULD
2797   take special precautions regarding the transfer of header information
2798   that identifies the hosts behind the firewall. In particular, they
2799   SHOULD remove, or replace with sanitized versions, any Via fields
2800   generated behind the firewall.
2801</t>
2802<t>
2803   The Referer header field allows reading patterns to be studied and reverse
2804   links drawn. Although it can be very useful, its power can be abused
2805   if user details are not separated from the information contained in
2806   the Referer. Even when the personal information has been removed, the
2807   Referer header field might indicate a private document's URI whose
2808   publication would be inappropriate.
2809</t>
2810<t>
2811   The information sent in the From field might conflict with the user's
2812   privacy interests or their site's security policy, and hence it
2813   SHOULD NOT  be transmitted without the user being able to disable,
2814   enable, and modify the contents of the field. The user MUST be able
2815   to set the contents of this field within a user preference or
2816   application defaults configuration.
2817</t>
2818<t>
2819   We suggest, though do not require, that a convenient toggle interface
2820   be provided for the user to enable or disable the sending of From and
2821   Referer information.
2822</t>
2823<t>
2824   The User-Agent (<xref target="header.user-agent"/>) or Server (<xref target="header.server"/>) header fields can sometimes be used to determine
2825   that a specific client or server have a particular security hole which might
2826   be exploited. Unfortunately, this same information is often used for other
2827   valuable purposes for which HTTP currently has no better mechanism.
2828</t>
2829<t>
2830   Furthermore, the User-Agent header field may contain enough entropy to be
2831   used, possibly in conjunction with other material, to uniquely identify the
2832   user.
2833</t>
2834<t>
2835   Some request methods, like TRACE (<xref target="TRACE"/>), expose information
2836   that was sent in request header fields within the body of their response.
2837   Clients SHOULD be careful with sensitive information, like Cookies,
2838   Authorization credentials, and other header fields that might be used to
2839   collect data from the client.
2840</t> 
2841</section>
2842
2843<section title="Encoding Sensitive Information in URIs" anchor="encoding.sensitive.information.in.uris">
2844<t>
2845   Because the source of a link might be private information or might
2846   reveal an otherwise private information source, it is strongly
2847   recommended that the user be able to select whether or not the
2848   Referer field is sent. For example, a browser client could have a
2849   toggle switch for browsing openly/anonymously, which would
2850   respectively enable/disable the sending of Referer and From
2851   information.
2852</t>
2853<t>
2854   Clients SHOULD NOT include a Referer header field in a (non-secure)
2855   HTTP request if the referring page was transferred with a secure
2856   protocol.
2857</t>
2858<t>
2859   Authors of services SHOULD NOT use GET-based forms for the submission of
2860   sensitive data because that data will be placed in the request-target. Many
2861   existing servers, proxies, and user agents log or display the request-target
2862   in places where it might be visible to third parties. Such services can
2863   use POST-based form submission instead.
2864</t>
2865</section>
2866
2867<section title="Location Headers and Spoofing" anchor="location.spoofing">
2868<t>
2869   If a single server supports multiple organizations that do not trust
2870   one another, then it MUST check the values of Location and Content-Location
2871   header fields in responses that are generated under control of
2872   said organizations to make sure that they do not attempt to
2873   invalidate resources over which they have no authority.
2874</t>
2875</section>
2876
2877<section title="Security Considerations for CONNECT">
2878<t>
2879   Since tunneled data is opaque to the proxy, there are additional
2880   risks to tunneling to other well-known or reserved ports.
2881   A HTTP client CONNECTing to port 25 could relay spam
2882   via SMTP, for example. As such, proxies SHOULD restrict CONNECT
2883   access to a small number of known ports.
2884</t>
2885</section>
2886
2887</section>
2888
2889<section title="Acknowledgments" anchor="acks">
2890<t>
2891  See Section 12 of <xref target="Part1"/>.
2892</t>
2893</section>
2894</middle>
2895<back>
2896
2897<references title="Normative References">
2898
2899<reference anchor="Part1">
2900  <front>
2901    <title abbrev="HTTP/1.1">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</title>
2902    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
2903      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
2904      <address><email>fielding@gbiv.com</email></address>
2905    </author>
2906    <author initials="J." surname="Gettys" fullname="Jim Gettys">
2907      <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization>
2908      <address><email>jg@freedesktop.org</email></address>
2909    </author>
2910    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
2911      <organization abbrev="HP">Hewlett-Packard Company</organization>
2912      <address><email>JeffMogul@acm.org</email></address>
2913    </author>
2914    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
2915      <organization abbrev="Microsoft">Microsoft Corporation</organization>
2916      <address><email>henrikn@microsoft.com</email></address>
2917    </author>
2918    <author initials="L." surname="Masinter" fullname="Larry Masinter">
2919      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
2920      <address><email>LMM@acm.org</email></address>
2921    </author>
2922    <author initials="P." surname="Leach" fullname="Paul J. Leach">
2923      <organization abbrev="Microsoft">Microsoft Corporation</organization>
2924      <address><email>paulle@microsoft.com</email></address>
2925    </author>
2926    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
2927      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
2928      <address><email>timbl@w3.org</email></address>
2929    </author>
2930    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
2931      <organization abbrev="W3C">World Wide Web Consortium</organization>
2932      <address><email>ylafon@w3.org</email></address>
2933    </author>
2934    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
2935      <organization abbrev="greenbytes">greenbytes GmbH</organization>
2936      <address><email>julian.reschke@greenbytes.de</email></address>
2937    </author>
2938    <date month="August" year="2011"/>
2939  </front>
2940  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-16"/>
2941 
2942</reference>
2943
2944<reference anchor="Part3">
2945  <front>
2946    <title abbrev="HTTP/1.1">HTTP/1.1, part 3: Message Payload and Content Negotiation</title>
2947    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
2948      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
2949      <address><email>fielding@gbiv.com</email></address>
2950    </author>
2951    <author initials="J." surname="Gettys" fullname="Jim Gettys">
2952      <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization>
2953      <address><email>jg@freedesktop.org</email></address>
2954    </author>
2955    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
2956      <organization abbrev="HP">Hewlett-Packard Company</organization>
2957      <address><email>JeffMogul@acm.org</email></address>
2958    </author>
2959    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
2960      <organization abbrev="Microsoft">Microsoft Corporation</organization>
2961      <address><email>henrikn@microsoft.com</email></address>
2962    </author>
2963    <author initials="L." surname="Masinter" fullname="Larry Masinter">
2964      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
2965      <address><email>LMM@acm.org</email></address>
2966    </author>
2967    <author initials="P." surname="Leach" fullname="Paul J. Leach">
2968      <organization abbrev="Microsoft">Microsoft Corporation</organization>
2969      <address><email>paulle@microsoft.com</email></address>
2970    </author>
2971    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
2972      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
2973      <address><email>timbl@w3.org</email></address>
2974    </author>
2975    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
2976      <organization abbrev="W3C">World Wide Web Consortium</organization>
2977      <address><email>ylafon@w3.org</email></address>
2978    </author>
2979    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
2980      <organization abbrev="greenbytes">greenbytes GmbH</organization>
2981      <address><email>julian.reschke@greenbytes.de</email></address>
2982    </author>
2983    <date month="August" year="2011"/>
2984  </front>
2985  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p3-payload-16"/>
2986 
2987</reference>
2988
2989<reference anchor="Part4">
2990  <front>
2991    <title abbrev="HTTP/1.1">HTTP/1.1, part 4: Conditional Requests</title>
2992    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
2993      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
2994      <address><email>fielding@gbiv.com</email></address>
2995    </author>
2996    <author initials="J." surname="Gettys" fullname="Jim Gettys">
2997      <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization>
2998      <address><email>jg@freedesktop.org</email></address>
2999    </author>
3000    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
3001      <organization abbrev="HP">Hewlett-Packard Company</organization>
3002      <address><email>JeffMogul@acm.org</email></address>
3003    </author>
3004    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
3005      <organization abbrev="Microsoft">Microsoft Corporation</organization>
3006      <address><email>henrikn@microsoft.com</email></address>
3007    </author>
3008    <author initials="L." surname="Masinter" fullname="Larry Masinter">
3009      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
3010      <address><email>LMM@acm.org</email></address>
3011    </author>
3012    <author initials="P." surname="Leach" fullname="Paul J. Leach">
3013      <organization abbrev="Microsoft">Microsoft Corporation</organization>
3014      <address><email>paulle@microsoft.com</email></address>
3015    </author>
3016    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
3017      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
3018      <address><email>timbl@w3.org</email></address>
3019    </author>
3020    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
3021      <organization abbrev="W3C">World Wide Web Consortium</organization>
3022      <address><email>ylafon@w3.org</email></address>
3023    </author>
3024    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
3025      <organization abbrev="greenbytes">greenbytes GmbH</organization>
3026      <address><email>julian.reschke@greenbytes.de</email></address>
3027    </author>
3028    <date month="August" year="2011"/>
3029  </front>
3030  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p4-conditional-16"/>
3031 
3032</reference>
3033
3034<reference anchor="Part5">
3035  <front>
3036    <title abbrev="HTTP/1.1">HTTP/1.1, part 5: Range Requests and Partial Responses</title>
3037    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
3038      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
3039      <address><email>fielding@gbiv.com</email></address>
3040    </author>
3041    <author initials="J." surname="Gettys" fullname="Jim Gettys">
3042      <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization>
3043      <address><email>jg@freedesktop.org</email></address>
3044    </author>
3045    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
3046      <organization abbrev="HP">Hewlett-Packard Company</organization>
3047      <address><email>JeffMogul@acm.org</email></address>
3048    </author>
3049    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
3050      <organization abbrev="Microsoft">Microsoft Corporation</organization>
3051      <address><email>henrikn@microsoft.com</email></address>
3052    </author>
3053    <author initials="L." surname="Masinter" fullname="Larry Masinter">
3054      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
3055      <address><email>LMM@acm.org</email></address>
3056    </author>
3057    <author initials="P." surname="Leach" fullname="Paul J. Leach">
3058      <organization abbrev="Microsoft">Microsoft Corporation</organization>
3059      <address><email>paulle@microsoft.com</email></address>
3060    </author>
3061    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
3062      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
3063      <address><email>timbl@w3.org</email></address>
3064    </author>
3065    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
3066      <organization abbrev="W3C">World Wide Web Consortium</organization>
3067      <address><email>ylafon@w3.org</email></address>
3068    </author>
3069    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
3070      <organization abbrev="greenbytes">greenbytes GmbH</organization>
3071      <address><email>julian.reschke@greenbytes.de</email></address>
3072    </author>
3073    <date month="August" year="2011"/>
3074  </front>
3075  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p5-range-16"/>
3076 
3077</reference>
3078
3079<reference anchor="Part6">
3080  <front>
3081    <title abbrev="HTTP/1.1">HTTP/1.1, part 6: Caching</title>
3082    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
3083      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
3084      <address><email>fielding@gbiv.com</email></address>
3085    </author>
3086    <author initials="J." surname="Gettys" fullname="Jim Gettys">
3087      <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization>
3088      <address><email>jg@freedesktop.org</email></address>
3089    </author>
3090    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
3091      <organization abbrev="HP">Hewlett-Packard Company</organization>
3092      <address><email>JeffMogul@acm.org</email></address>
3093    </author>
3094    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
3095      <organization abbrev="Microsoft">Microsoft Corporation</organization>
3096      <address><email>henrikn@microsoft.com</email></address>
3097    </author>
3098    <author initials="L." surname="Masinter" fullname="Larry Masinter">
3099      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
3100      <address><email>LMM@acm.org</email></address>
3101    </author>
3102    <author initials="P." surname="Leach" fullname="Paul J. Leach">
3103      <organization abbrev="Microsoft">Microsoft Corporation</organization>
3104      <address><email>paulle@microsoft.com</email></address>
3105    </author>
3106    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
3107      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
3108      <address><email>timbl@w3.org</email></address>
3109    </author>
3110    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
3111      <organization abbrev="W3C">World Wide Web Consortium</organization>
3112      <address><email>ylafon@w3.org</email></address>
3113    </author>
3114    <author initials="M." surname="Nottingham" fullname="Mark Nottingham" role="editor">
3115      <address><email>mnot@mnot.net</email></address>
3116    </author>
3117    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
3118      <organization abbrev="greenbytes">greenbytes GmbH</organization>
3119      <address><email>julian.reschke@greenbytes.de</email></address>
3120    </author>
3121    <date month="August" year="2011"/>
3122  </front>
3123  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-16"/>
3124 
3125</reference>
3126
3127<reference anchor="Part7">
3128  <front>
3129    <title abbrev="HTTP/1.1">HTTP/1.1, part 7: Authentication</title>
3130    <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
3131      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
3132      <address><email>fielding@gbiv.com</email></address>
3133    </author>
3134    <author initials="J." surname="Gettys" fullname="Jim Gettys">
3135      <organization abbrev="Alcatel-Lucent">Alcatel-Lucent Bell Labs</organization>
3136      <address><email>jg@freedesktop.org</email></address>
3137    </author>
3138    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
3139      <organization abbrev="HP">Hewlett-Packard Company</organization>
3140      <address><email>JeffMogul@acm.org</email></address>
3141    </author>
3142    <author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
3143      <organization abbrev="Microsoft">Microsoft Corporation</organization>
3144      <address><email>henrikn@microsoft.com</email></address>
3145    </author>
3146    <author initials="L." surname="Masinter" fullname="Larry Masinter">
3147      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
3148      <address><email>LMM@acm.org</email></address>
3149    </author>
3150    <author initials="P." surname="Leach" fullname="Paul J. Leach">
3151      <organization abbrev="Microsoft">Microsoft Corporation</organization>
3152      <address><email>paulle@microsoft.com</email></address>
3153    </author>
3154    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
3155      <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
3156      <address><email>timbl@w3.org</email></address>
3157    </author>
3158    <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
3159      <organization abbrev="W3C">World Wide Web Consortium</organization>
3160      <address><email>ylafon@w3.org</email></address>
3161    </author>
3162    <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
3163      <organization abbrev="greenbytes">greenbytes GmbH</organization>
3164      <address><email>julian.reschke@greenbytes.de</email></address>
3165    </author>
3166    <date month="August" year="2011"/>
3167  </front>
3168  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p7-auth-16"/>
3169 
3170</reference>
3171
3172<reference anchor="RFC2119">
3173  <front>
3174    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
3175    <author initials="S." surname="Bradner" fullname="Scott Bradner">
3176      <organization>Harvard University</organization>
3177      <address><email>sob@harvard.edu</email></address>
3178    </author>
3179    <date month="March" year="1997"/>
3180  </front>
3181  <seriesInfo name="BCP" value="14"/>
3182  <seriesInfo name="RFC" value="2119"/>
3183</reference>
3184
3185<reference anchor="RFC3986">
3186 <front>
3187  <title abbrev="URI Generic Syntax">Uniform Resource Identifier (URI): Generic Syntax</title>
3188  <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
3189    <organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
3190    <address>
3191       <email>timbl@w3.org</email>
3192       <uri>http://www.w3.org/People/Berners-Lee/</uri>
3193    </address>
3194  </author>
3195  <author initials="R." surname="Fielding" fullname="Roy T. Fielding">
3196    <organization abbrev="Day Software">Day Software</organization>
3197    <address>
3198      <email>fielding@gbiv.com</email>
3199      <uri>http://roy.gbiv.com/</uri>
3200    </address>
3201  </author>
3202  <author initials="L." surname="Masinter" fullname="Larry Masinter">
3203    <organization abbrev="Adobe Systems">Adobe Systems Incorporated</organization>
3204    <address>
3205      <email>LMM@acm.org</email>
3206      <uri>http://larry.masinter.net/</uri>
3207    </address>
3208  </author>
3209  <date month="January" year="2005"/>
3210 </front>
3211 <seriesInfo name="STD" value="66"/>
3212 <seriesInfo name="RFC" value="3986"/>
3213</reference>
3214
3215<reference anchor="RFC5234">
3216  <front>
3217    <title abbrev="ABNF for Syntax Specifications">Augmented BNF for Syntax Specifications: ABNF</title>
3218    <author initials="D." surname="Crocker" fullname="Dave Crocker" role="editor">
3219      <organization>Brandenburg InternetWorking</organization>
3220      <address>
3221        <email>dcrocker@bbiw.net</email>
3222      </address> 
3223    </author>
3224    <author initials="P." surname="Overell" fullname="Paul Overell">
3225      <organization>THUS plc.</organization>
3226      <address>
3227        <email>paul.overell@thus.net</email>
3228      </address>
3229    </author>
3230    <date month="January" year="2008"/>
3231  </front>
3232  <seriesInfo name="STD" value="68"/>
3233  <seriesInfo name="RFC" value="5234"/>
3234</reference>
3235
3236</references>
3237
3238<references title="Informative References">
3239
3240<reference anchor="RFC1945">
3241  <front>
3242    <title abbrev="HTTP/1.0">Hypertext Transfer Protocol -- HTTP/1.0</title>
3243    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
3244      <organization>MIT, Laboratory for Computer Science</organization>
3245      <address><email>timbl@w3.org</email></address>
3246    </author>
3247    <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding">
3248      <organization>University of California, Irvine, Department of Information and Computer Science</organization>
3249      <address><email>fielding@ics.uci.edu</email></address>
3250    </author>
3251    <author initials="H.F." surname="Nielsen" fullname="Henrik Frystyk Nielsen">
3252      <organization>W3 Consortium, MIT Laboratory for Computer Science</organization>
3253      <address><email>frystyk@w3.org</email></address>
3254    </author>
3255    <date month="May" year="1996"/>
3256  </front>
3257  <seriesInfo name="RFC" value="1945"/>
3258</reference>
3259
3260<reference anchor="RFC2068">
3261  <front>
3262    <title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title>
3263    <author initials="R." surname="Fielding" fullname="Roy T. Fielding">
3264      <organization>University of California, Irvine, Department of Information and Computer Science</organization>
3265      <address><email>fielding@ics.uci.edu</email></address>
3266    </author>
3267    <author initials="J." surname="Gettys" fullname="Jim Gettys">
3268      <organization>MIT Laboratory for Computer Science</organization>
3269      <address><email>jg@w3.org</email></address>
3270    </author>
3271    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
3272      <organization>Digital Equipment Corporation, Western Research Laboratory</organization>
3273      <address><email>mogul@wrl.dec.com</email></address>
3274    </author>
3275    <author initials="H." surname="Nielsen" fullname="Henrik Frystyk Nielsen">
3276      <organization>MIT Laboratory for Computer Science</organization>
3277      <address><email>frystyk@w3.org</email></address>
3278    </author>
3279    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
3280      <organization>MIT Laboratory for Computer Science</organization>
3281      <address><email>timbl@w3.org</email></address>
3282    </author>
3283    <date month="January" year="1997"/>
3284  </front>
3285  <seriesInfo name="RFC" value="2068"/>
3286</reference>
3287
3288<reference anchor="RFC2616">
3289  <front>
3290    <title>Hypertext Transfer Protocol -- HTTP/1.1</title>
3291    <author initials="R." surname="Fielding" fullname="R. Fielding">
3292      <organization>University of California, Irvine</organization>
3293      <address><email>fielding@ics.uci.edu</email></address>
3294    </author>
3295    <author initials="J." surname="Gettys" fullname="J. Gettys">
3296      <organization>W3C</organization>
3297      <address><email>jg@w3.org</email></address>
3298    </author>
3299    <author initials="J." surname="Mogul" fullname="J. Mogul">
3300      <organization>Compaq Computer Corporation</organization>
3301      <address><email>mogul@wrl.dec.com</email></address>
3302    </author>
3303    <author initials="H." surname="Frystyk" fullname="H. Frystyk">
3304      <organization>MIT Laboratory for Computer Science</organization>
3305      <address><email>frystyk@w3.org</email></address>
3306    </author>
3307    <author initials="L." surname="Masinter" fullname="L. Masinter">
3308      <organization>Xerox Corporation</organization>
3309      <address><email>masinter@parc.xerox.com</email></address>
3310    </author>
3311    <author initials="P." surname="Leach" fullname="P. Leach">
3312      <organization>Microsoft Corporation</organization>
3313      <address><email>paulle@microsoft.com</email></address>
3314    </author>
3315    <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
3316      <organization>W3C</organization>
3317      <address><email>timbl@w3.org</email></address>
3318    </author>
3319    <date month="June" year="1999"/>
3320  </front>
3321  <seriesInfo name="RFC" value="2616"/>
3322</reference>
3323
3324<reference anchor="RFC2817">
3325  <front>
3326    <title>Upgrading to TLS Within HTTP/1.1</title>
3327    <author initials="R." surname="Khare" fullname="R. Khare">
3328      <organization>4K Associates / UC Irvine</organization>
3329      <address><email>rohit@4K-associates.com</email></address>
3330    </author>
3331    <author initials="S." surname="Lawrence" fullname="S. Lawrence">
3332      <organization>Agranat Systems, Inc.</organization>
3333      <address><email>lawrence@agranat.com</email></address>
3334    </author>
3335    <date year="2000" month="May"/>
3336  </front>
3337  <seriesInfo name="RFC" value="2817"/>
3338</reference>
3339
3340<reference anchor="RFC3864">
3341  <front>
3342    <title>Registration Procedures for Message Header Fields</title>
3343    <author initials="G." surname="Klyne" fullname="G. Klyne">
3344      <organization>Nine by Nine</organization>
3345      <address><email>GK-IETF@ninebynine.org</email></address>
3346    </author>
3347    <author initials="M." surname="Nottingham" fullname="M. Nottingham">
3348      <organization>BEA Systems</organization>
3349      <address><email>mnot@pobox.com</email></address>
3350    </author>
3351    <author initials="J." surname="Mogul" fullname="J. Mogul">
3352      <organization>HP Labs</organization>
3353      <address><email>JeffMogul@acm.org</email></address>
3354    </author>
3355    <date year="2004" month="September"/>
3356  </front>
3357  <seriesInfo name="BCP" value="90"/>
3358  <seriesInfo name="RFC" value="3864"/>
3359</reference>
3360
3361<reference anchor="RFC5226">
3362  <front>
3363    <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
3364    <author initials="T." surname="Narten" fullname="T. Narten">
3365      <organization>IBM</organization>
3366      <address><email>narten@us.ibm.com</email></address>
3367    </author>
3368    <author initials="H." surname="Alvestrand" fullname="H. Alvestrand">
3369      <organization>Google</organization>
3370      <address><email>Harald@Alvestrand.no</email></address>
3371    </author>
3372    <date year="2008" month="May"/>
3373  </front>
3374  <seriesInfo name="BCP" value="26"/>
3375  <seriesInfo name="RFC" value="5226"/>
3376</reference>
3377
3378<reference anchor="RFC5322">
3379  <front>
3380    <title>Internet Message Format</title>
3381    <author initials="P." surname="Resnick" fullname="P. Resnick">
3382      <organization>Qualcomm Incorporated</organization>
3383    </author>
3384    <date year="2008" month="October"/>
3385  </front> 
3386  <seriesInfo name="RFC" value="5322"/>
3387</reference>
3388
3389<reference anchor="RFC5789">
3390  <front>
3391    <title>PATCH Method for HTTP</title>
3392    <author initials="L." surname="Dusseault" fullname="L. Dusseault">
3393      <organization>Linden Lab</organization>
3394    </author>
3395    <author initials="J." surname="Snell" fullname="J. Snell"/>
3396    <date year="2010" month="March"/>
3397  </front>
3398  <seriesInfo name="RFC" value="5789"/>
3399</reference>
3400
3401</references>
3402
3403<section title="Changes from RFC 2616" anchor="changes.from.rfc.2616">
3404<t>
3405  This document takes over the Status Code Registry, previously defined
3406  in Section 7.1 of <xref target="RFC2817"/>.
3407  (<xref target="status.code.registry"/>)
3408</t>
3409<t>
3410  Clarify definition of POST.
3411  (<xref target="POST"/>)
3412</t>
3413<t>
3414  Remove requirement to handle all Content-* header fields; ban use of
3415  Content-Range with PUT.
3416  (<xref target="PUT"/>)
3417</t>
3418<t>
3419  Take over definition of CONNECT method from <xref target="RFC2817"/>.
3420  (<xref target="CONNECT"/>)
3421</t>
3422<t>
3423  Broadened the definition of 203 (Non-Authoritative Information) to include
3424  cases of payload transformations as well.
3425  (<xref target="status.203"/>)
3426</t>
3427<t>
3428  Failed to consider that there are
3429  many other request methods that are safe to automatically redirect,
3430  and further that the user agent is able to make that determination
3431  based on the request method semantics.
3432  (Sections <xref format="counter" target="status.301"/>,
3433  <xref format="counter" target="status.302"/> and
3434  <xref format="counter" target="status.307"/>)
3435</t>
3436<t>
3437  Deprecate 305 Use Proxy status code, because user agents did not implement it.
3438  It used to indicate that the target resource must be accessed through the
3439  proxy given by the Location field. The Location field gave the URI of the
3440  proxy. The recipient was expected to repeat this single request via the proxy.
3441  (<xref target="status.305"/>)
3442</t>
3443<t>
3444  Define status 426 (Upgrade Required) (this was incorporated from
3445  <xref target="RFC2817"/>).
3446  (<xref target="status.426"/>)
3447</t>
3448<t>
3449  Change ABNF productions for header fields to only define the field value.
3450  (<xref target="header.fields"/>)
3451</t>
3452<t>
3453  Reclassify "Allow" as response header field, removing the option to
3454  specify it in a PUT request.
3455  Relax the server requirement on the contents of the Allow header field and
3456  remove requirement on clients to always trust the header field value.
3457  (<xref target="header.allow"/>)
3458</t>
3459<t>
3460  Correct syntax of Location header field to allow URI references (including
3461  relative references and fragments), as referred symbol "absoluteURI" wasn't
3462  what was expected, and add some clarifications as to when use of fragments
3463  would not be appropriate.
3464  (<xref target="header.location"/>)
3465</t>
3466<t>
3467  Restrict Max-Forwards header field to OPTIONS and TRACE (previously,
3468  extension methods could have used it as well).
3469  (<xref target="header.max-forwards"/>)
3470</t>
3471<t>
3472  Allow Referer field value of "about:blank" as alternative to not specifying it.
3473  (<xref target="header.referer"/>)
3474</t>
3475<t>
3476  In the description of the Server header field, the Via field
3477  was described as a SHOULD. The requirement was and is stated
3478  correctly in the description of the Via header field in Section 9.9 of <xref target="Part1"/>.
3479  (<xref target="header.server"/>)
3480</t>
3481</section>
3482
3483
3484<section title="Collected ABNF" anchor="collected.abnf">
3485<figure>
3486<artwork type="abnf" name="p2-semantics.parsed-abnf"><![CDATA[
3487Allow = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ]
3488
3489Expect = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] )
3490
3491From = mailbox
3492
3493HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>
3494
3495Location = URI-reference
3496
3497Max-Forwards = 1*DIGIT
3498Method = token
3499
3500OWS = <OWS, defined in [Part1], Section 1.2.2>
3501
3502RWS = <RWS, defined in [Part1], Section 1.2.2>
3503Reason-Phrase = *( WSP / VCHAR / obs-text )
3504Referer = absolute-URI / partial-URI
3505Retry-After = HTTP-date / delta-seconds
3506
3507Server = product *( RWS ( product / comment ) )
3508Status-Code = 3DIGIT
3509
3510URI-reference = <URI-reference, defined in [Part1], Section 2.7>
3511User-Agent = product *( RWS ( product / comment ) )
3512
3513absolute-URI = <absolute-URI, defined in [Part1], Section 2.7>
3514
3515comment = <comment, defined in [Part1], Section 3.2>
3516
3517delta-seconds = 1*DIGIT
3518
3519expect-params = ";" token [ "=" ( token / quoted-string ) ]
3520expectation = "100-continue" / expectation-extension
3521expectation-extension = token [ "=" ( token / quoted-string )
3522 *expect-params ]
3523
3524mailbox = <mailbox, defined in [RFC5322], Section 3.4>
3525
3526obs-text = <obs-text, defined in [Part1], Section 1.2.2>
3527
3528partial-URI = <partial-URI, defined in [Part1], Section 2.7>
3529product = <product, defined in [Part1], Section 6.3>
3530
3531quoted-string = <quoted-string, defined in [Part1], Section 3.2.3>
3532
3533token = <token, defined in [Part1], Section 3.2.3>
3534]]></artwork>
3535</figure>
3536<figure><preamble>ABNF diagnostics:</preamble><artwork type="inline"><![CDATA[
3537; Allow defined but not used
3538; Expect defined but not used
3539; From defined but not used
3540; Location defined but not used
3541; Max-Forwards defined but not used
3542; Reason-Phrase defined but not used
3543; Referer defined but not used
3544; Retry-After defined but not used
3545; Server defined but not used
3546; Status-Code defined but not used
3547; User-Agent defined but not used
3548]]></artwork></figure></section>
3549
3550
3551<section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log">
3552
3553<section title="Since RFC 2616">
3554<t>
3555  Extracted relevant partitions from <xref target="RFC2616"/>.
3556</t>
3557</section>
3558
3559<section title="Since draft-ietf-httpbis-p2-semantics-00">
3560<t>
3561  Closed issues:
3562  <list style="symbols"> 
3563    <t>
3564      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/5"/>:
3565      "Via is a MUST"
3566      (<eref target="http://purl.org/NET/http-errata#via-must"/>)
3567    </t>
3568    <t>
3569      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/6"/>:
3570      "Fragments allowed in Location"
3571      (<eref target="http://purl.org/NET/http-errata#location-fragments"/>)
3572    </t>
3573    <t>
3574      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/10"/>:
3575      "Safe Methods vs Redirection"
3576      (<eref target="http://purl.org/NET/http-errata#saferedirect"/>)
3577    </t>
3578    <t>
3579      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/17"/>:
3580      "Revise description of the POST method"
3581      (<eref target="http://purl.org/NET/http-errata#post"/>)
3582    </t>
3583    <t>
3584      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/35"/>:
3585      "Normative and Informative references"
3586    </t>
3587    <t>
3588      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/42"/>:
3589      "RFC2606 Compliance"
3590    </t>
3591    <t>
3592      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/65"/>:
3593      "Informative references"
3594    </t>
3595    <t>
3596      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/84"/>:
3597      "Redundant cross-references"
3598    </t>
3599  </list>
3600</t>
3601<t>
3602  Other changes:
3603  <list style="symbols"> 
3604    <t>
3605      Move definitions of 304 and 412 condition codes to <xref target="Part4"/>
3606    </t>
3607  </list>
3608</t>
3609</section>
3610
3611<section title="Since draft-ietf-httpbis-p2-semantics-01">
3612<t>
3613  Closed issues:
3614  <list style="symbols"> 
3615    <t>
3616      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/21"/>:
3617      "PUT side effects"
3618    </t>
3619    <t>
3620      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/91"/>:
3621      "Duplicate Host header requirements"
3622    </t>
3623  </list>
3624</t>
3625<t>
3626  Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>):
3627  <list style="symbols"> 
3628    <t>
3629      Move "Product Tokens" section (back) into Part 1, as "token" is used
3630      in the definition of the Upgrade header field.
3631    </t>
3632    <t>
3633      Add explicit references to BNF syntax and rules imported from other parts of the specification.
3634    </t>
3635    <t>
3636      Copy definition of delta-seconds from Part6 instead of referencing it.
3637    </t>
3638  </list>
3639</t>
3640</section>
3641
3642<section title="Since draft-ietf-httpbis-p2-semantics-02" anchor="changes.since.02">
3643<t>
3644  Closed issues:
3645  <list style="symbols"> 
3646    <t>
3647      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/24"/>:
3648      "Requiring Allow in 405 responses"
3649    </t>
3650    <t>
3651      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/59"/>:
3652      "Status Code Registry"
3653    </t>
3654    <t>
3655      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/61"/>:
3656      "Redirection vs. Location"
3657    </t>
3658    <t>
3659      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/70"/>:
3660      "Cacheability of 303 response"
3661    </t>
3662    <t>
3663      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/76"/>:
3664      "305 Use Proxy"
3665    </t>
3666    <t>
3667      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/105"/>:
3668      "Classification for Allow header"
3669    </t>
3670    <t>
3671      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/112"/>:
3672      "PUT - 'store under' vs 'store at'"
3673    </t>
3674  </list>
3675</t>
3676<t>
3677  Ongoing work on IANA Message Header Field Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40"/>):
3678  <list style="symbols"> 
3679    <t>
3680      Reference RFC 3984, and update header field registrations for headers defined
3681      in this document.
3682    </t>
3683  </list>
3684</t>
3685<t>
3686  Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>):
3687  <list style="symbols"> 
3688    <t>
3689      Replace string literals when the string really is case-sensitive (method).
3690    </t>
3691  </list>
3692</t>
3693</section>
3694
3695<section title="Since draft-ietf-httpbis-p2-semantics-03" anchor="changes.since.03">
3696<t>
3697  Closed issues:
3698  <list style="symbols"> 
3699    <t>
3700      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/98"/>:
3701      "OPTIONS request bodies"
3702    </t>
3703    <t>
3704      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/119"/>:
3705      "Description of CONNECT should refer to RFC2817"
3706    </t>
3707    <t>
3708      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/125"/>:
3709      "Location Content-Location reference request/response mixup"
3710    </t>
3711  </list>
3712</t>
3713<t>
3714  Ongoing work on Method Registry (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/72"/>):
3715  <list style="symbols"> 
3716    <t>
3717      Added initial proposal for registration process, plus initial
3718      content (non-HTTP/1.1 methods to be added by a separate specification).
3719    </t>
3720  </list>
3721</t>
3722</section>
3723
3724<section title="Since draft-ietf-httpbis-p2-semantics-04" anchor="changes.since.04">
3725<t>
3726  Closed issues:
3727  <list style="symbols"> 
3728    <t>
3729      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/103"/>:
3730      "Content-*"
3731    </t>
3732    <t>
3733      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/132"/>:
3734      "RFC 2822 is updated by RFC 5322"
3735    </t>
3736  </list>
3737</t>
3738<t>
3739  Ongoing work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>):
3740  <list style="symbols"> 
3741    <t>
3742      Use "/" instead of "|" for alternatives.
3743    </t>
3744    <t>
3745      Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
3746      whitespace ("OWS") and required whitespace ("RWS").
3747    </t>
3748    <t>
3749      Rewrite ABNFs to spell out whitespace rules, factor out
3750      header field value format definitions.
3751    </t>
3752  </list>
3753</t>
3754</section>
3755
3756<section title="Since draft-ietf-httpbis-p2-semantics-05" anchor="changes.since.05">
3757<t>
3758  Closed issues:
3759  <list style="symbols"> 
3760    <t>
3761      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/94"/>:
3762      "Reason-Phrase BNF"
3763    </t>
3764  </list>
3765</t>
3766<t>
3767  Final work on ABNF conversion (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/36"/>):
3768  <list style="symbols"> 
3769    <t>
3770      Add appendix containing collected and expanded ABNF, reorganize ABNF introduction.
3771    </t>
3772  </list>
3773</t>
3774</section>
3775
3776<section title="Since draft-ietf-httpbis-p2-semantics-06" anchor="changes.since.06">
3777<t>
3778  Closed issues:
3779  <list style="symbols"> 
3780    <t>
3781      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/144"/>:
3782      "Clarify when Referer is sent"
3783    </t>
3784    <t>
3785      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/164"/>:
3786      "status codes vs methods"
3787    </t>
3788    <t>
3789      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/170"/>:
3790      "Do not require "updates" relation for specs that register status codes or method names"
3791    </t>
3792  </list>
3793</t>
3794</section>
3795
3796<section title="Since draft-ietf-httpbis-p2-semantics-07" anchor="changes.since.07">
3797<t>
3798  Closed issues:
3799  <list style="symbols"> 
3800    <t>
3801      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/27"/>:
3802      "Idempotency"
3803    </t>
3804    <t>
3805      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/33"/>:
3806      "TRACE security considerations"
3807    </t>
3808    <t>
3809      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/110"/>:
3810      "Clarify rules for determining what entities a response carries"
3811    </t>
3812    <t>
3813      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/140"/>:
3814      "update note citing RFC 1945 and 2068"
3815    </t>
3816    <t>
3817      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/182"/>:
3818      "update note about redirect limit"
3819    </t>
3820    <t>
3821      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/191"/>:
3822      "Location header ABNF should use 'URI'"
3823    </t>
3824    <t>
3825      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/192"/>:
3826      "fragments in Location vs status 303"
3827    </t>
3828    <t>
3829      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/198"/>:
3830      "move IANA registrations for optional status codes"
3831    </t>
3832  </list>
3833</t>
3834<t>
3835  Partly resolved issues:
3836  <list style="symbols"> 
3837    <t>
3838      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/171"/>:
3839      "Are OPTIONS and TRACE safe?"
3840    </t>
3841  </list>
3842</t>
3843</section>
3844
3845<section title="Since draft-ietf-httpbis-p2-semantics-08" anchor="changes.since.08">
3846<t>
3847  Closed issues:
3848  <list style="symbols"> 
3849    <t>
3850      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/10"/>:
3851      "Safe Methods vs Redirection" (we missed the introduction to the 3xx
3852      status codes when fixing this previously)
3853    </t>
3854  </list>
3855</t>
3856</section>
3857
3858<section title="Since draft-ietf-httpbis-p2-semantics-09" anchor="changes.since.09">
3859<t>
3860  Closed issues:
3861  <list style="symbols"> 
3862    <t>
3863      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/43"/>:
3864      "Fragment combination / precedence during redirects"
3865    </t>
3866  </list>
3867</t>
3868<t>
3869  Partly resolved issues:
3870  <list style="symbols"> 
3871    <t>
3872      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/185"/>:
3873      "Location header payload handling"
3874    </t>
3875    <t>
3876      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/196"/>:
3877      "Term for the requested resource's URI"
3878    </t>
3879  </list>
3880</t>
3881</section>
3882
3883<section title="Since draft-ietf-httpbis-p2-semantics-10" anchor="changes.since.10">
3884<t>
3885  Closed issues:
3886  <list style="symbols"> 
3887    <t>
3888      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/69"/>:
3889      "Clarify 'Requested Variant'"
3890    </t>
3891    <t>
3892      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/109"/>:
3893      "Clarify entity / representation / variant terminology"
3894    </t>
3895    <t>
3896      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/139"/>:
3897      "Methods and Caching"
3898    </t>
3899    <t>
3900      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/190"/>:
3901      "OPTIONS vs Max-Forwards"
3902    </t>
3903    <t>
3904      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/199"/>:
3905      "Status codes and caching"
3906    </t>
3907    <t>
3908      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/220"/>:
3909      "consider removing the 'changes from 2068' sections"
3910    </t>
3911  </list>
3912</t>
3913</section>
3914
3915<section title="Since draft-ietf-httpbis-p2-semantics-11" anchor="changes.since.11">
3916<t>
3917  Closed issues:
3918  <list style="symbols"> 
3919    <t>
3920      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/229"/>:
3921      "Considerations for new status codes"
3922    </t>
3923    <t>
3924      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/230"/>:
3925      "Considerations for new methods"
3926    </t>
3927    <t>
3928      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/232"/>:
3929      "User-Agent guidelines" (relating to the 'User-Agent' header field)
3930    </t>
3931  </list>
3932</t>
3933</section>
3934
3935<section title="Since draft-ietf-httpbis-p2-semantics-12" anchor="changes.since.12">
3936<t>
3937  Closed issues:
3938  <list style="symbols"> 
3939    <t>
3940      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/43"/>:
3941      "Fragment combination / precedence during redirects" (added warning
3942      about having a fragid on the redirect may cause inconvenience in
3943      some cases)
3944    </t>
3945    <t>
3946      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/79"/>:
3947      "Content-* vs. PUT"
3948    </t>
3949    <t>
3950      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/88"/>:
3951      "205 Bodies"
3952    </t>
3953    <t>
3954      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/102"/>:
3955      "Understanding Content-* on non-PUT requests"
3956    </t>
3957    <t>
3958      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/103"/>:
3959      "Content-*"
3960    </t>
3961    <t>
3962      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/104"/>:
3963      "Header type defaulting"
3964    </t>
3965    <t>
3966      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/112"/>:
3967      "PUT - 'store under' vs 'store at'"
3968    </t>
3969    <t>
3970      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/137"/>:
3971      "duplicate ABNF for Reason-Phrase"
3972    </t>
3973    <t>
3974      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/180"/>:
3975      "Note special status of Content-* prefix in header registration procedures"
3976    </t>
3977    <t>
3978      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/203"/>:
3979      "Max-Forwards vs extension methods"
3980    </t>
3981    <t>
3982      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/213"/>:
3983      "What is the value space of HTTP status codes?" (actually fixed in
3984      draft-ietf-httpbis-p2-semantics-11)
3985    </t>
3986    <t>
3987      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/224"/>:
3988      "Header Classification"
3989    </t>
3990    <t>
3991      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/225"/>:
3992      "PUT side effect: invalidation or just stale?"
3993    </t>
3994    <t>
3995      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/226"/>:
3996      "proxies not supporting certain methods"
3997    </t>
3998    <t>
3999      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/239"/>:
4000      "Migrate CONNECT from RFC2817 to p2"
4001    </t>
4002    <t>
4003      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/240"/>:
4004      "Migrate Upgrade details from RFC2817"
4005    </t>
4006    <t>
4007      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/267"/>:
4008      "clarify PUT semantics'"
4009    </t>
4010    <t>
4011      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/275"/>:
4012      "duplicate ABNF for 'Method'"
4013    </t>
4014    <t>
4015      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/276"/>:
4016      "untangle ABNFs for header fields"
4017    </t>
4018  </list>
4019</t>
4020</section>
4021
4022<section title="Since draft-ietf-httpbis-p2-semantics-13" anchor="changes.since.13">
4023<t>
4024  Closed issues:
4025  <list style="symbols"> 
4026    <t>
4027      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/276"/>:
4028      "untangle ABNFs for header fields"
4029    </t>
4030    <t>
4031      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/251"/>:
4032      "message-body in CONNECT request"
4033    </t>
4034  </list>
4035</t>
4036</section>
4037
4038<section title="Since draft-ietf-httpbis-p2-semantics-14" anchor="changes.since.14">
4039<t>
4040  Closed issues:
4041  <list style="symbols"> 
4042    <t>
4043      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/255"/>:
4044      "Clarify status code for rate limiting"
4045    </t>
4046    <t>
4047      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/294"/>:
4048      "clarify 403 forbidden"
4049    </t>
4050    <t>
4051      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/296"/>:
4052      "Clarify 203 Non-Authoritative Information"
4053    </t>
4054    <t>
4055      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/298"/>:
4056      "update default reason phrase for 413"
4057    </t>
4058  </list>
4059</t>
4060</section>
4061
4062<section title="Since draft-ietf-httpbis-p2-semantics-15" anchor="changes.since.15">
4063<t>
4064  Closed issues:
4065  <list style="symbols"> 
4066    <t>
4067      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/285"/>:
4068      "Strength of requirements on Accept re: 406"
4069    </t>
4070    <t>
4071      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/303"/>:
4072      "400 response isn't generic"
4073    </t>
4074  </list>
4075</t>
4076</section>
4077</section>
4078
4079</back>
4080</rfc>
Note: See TracBrowser for help on using the repository browser.