source: draft-ietf-httpbis/latest/p2-semantics.xml @ 1401

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

prepare for publication of -16 on Aug 24.

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