source: draft-ietf-httpbis/10/draft-ietf-httpbis-p2-semantics-10.xml @ 1697

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

fix mime types

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