source: draft-ietf-httpbis/11/draft-ietf-httpbis-p2-semantics-11.xml @ 973

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

prepare publication of -11 drafts on 2010-08-04.

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