Changeset 698 for draft-ietf-httpbis/latest
- Timestamp:
- 26/09/09 10:09:09 (13 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 14 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r697 r698 400 400 <meta name="DC.Creator" content="Reschke, J. F."> 401 401 <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 402 <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-2 5">402 <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-26"> 403 403 <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2616"> 404 404 <meta name="DC.Description.Abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 1 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides an overview of HTTP and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations."> … … 437 437 </tr> 438 438 <tr> 439 <td class="header left">Expires: March 29, 2010</td>439 <td class="header left">Expires: March 30, 2010</td> 440 440 <td class="header right">H. Frystyk</td> 441 441 </tr> … … 486 486 <tr> 487 487 <td class="header left"></td> 488 <td class="header right">September 2 5, 2009</td>488 <td class="header right">September 26, 2009</td> 489 489 </tr> 490 490 </table> … … 510 510 <p>The list of Internet-Draft Shadow Directories can be accessed at <<a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>>. 511 511 </p> 512 <p>This Internet-Draft will expire in March 29, 2010.</p>512 <p>This Internet-Draft will expire in March 30, 2010.</p> 513 513 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 514 514 <p>Copyright © 2009 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1843 1843 <div id="rfc.iref.h.7"></div> 1844 1844 <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a> <a id="header.content-length" href="#header.content-length">Content-Length</a></h2> 1845 <p id="rfc.section.9.2.p.1">The "Content-Length" entity-header field indicates the size of the entity-body, in number of OCTETs , sent to the recipient1846 or, in the case of the HEAD method,the size of the entity-body that would have been sent had the request been a GET.1845 <p id="rfc.section.9.2.p.1">The "Content-Length" entity-header field indicates the size of the entity-body, in number of OCTETs. In the case of responses 1846 to the HEAD method, it indicates the size of the entity-body that would have been sent had the request been a GET. 1847 1847 </p> 1848 1848 <div id="rfc.figure.u.54"></div><pre class="inline"><span id="rfc.iref.g.92"></span><span id="rfc.iref.g.93"></span> <a href="#header.content-length" class="smpl">Content-Length</a> = "Content-Length" ":" <a href="#rule.whitespace" class="smpl">OWS</a> 1*<a href="#header.content-length" class="smpl">Content-Length-v</a> … … 1898 1898 <div id="rfc.iref.h.10"></div> 1899 1899 <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a> <a id="header.host" href="#header.host">Host</a></h2> 1900 <p id="rfc.section.9.4.p.1">The "Host" request-header field specifies the Internet host and port number of the resource being requested, as obtained from 1901 the original URI given by the user or referring resource (generally an http URI, as described in <a href="#http.uri" title="http URI scheme">Section 2.6.1</a>). The Host field value <em class="bcp14">MUST</em> represent the naming authority of the origin server or gateway given by the original URL. This allows the origin server or 1902 gateway to differentiate between internally-ambiguous URLs, such as the root "/" URL of a server for multiple host names on 1903 a single IP address. 1900 <p id="rfc.section.9.4.p.1">The "Host" request-header field specifies the Internet host and port number of the resource being requested, allowing the 1901 origin server or gateway to differentiate between internally-ambiguous URLs, such as the root "/" URL of a server for multiple 1902 host names on a single IP address. 1903 </p> 1904 <p id="rfc.section.9.4.p.2">The Host field value <em class="bcp14">MUST</em> represent the naming authority of the origin server or gateway given by the original URL obtained from the user or referring 1905 resource (generally an http URI, as described in <a href="#http.uri" title="http URI scheme">Section 2.6.1</a>). 1904 1906 </p> 1905 1907 <div id="rfc.figure.u.58"></div><pre class="inline"><span id="rfc.iref.g.96"></span><span id="rfc.iref.g.97"></span> <a href="#header.host" class="smpl">Host</a> = "Host" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.host" class="smpl">Host-v</a> 1906 1908 <a href="#header.host" class="smpl">Host-v</a> = <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section 2.6.1</a> 1907 </pre><p id="rfc.section.9.4.p. 3">A "host" without any trailing port information implies the default port for the service requested (e.g., "80" for an HTTP1909 </pre><p id="rfc.section.9.4.p.4">A "host" without any trailing port information implies the default port for the service requested (e.g., "80" for an HTTP 1908 1910 URL). For example, a request on the origin server for <http://www.example.org/pub/WWW/> would properly include: 1909 1911 </p> 1910 1912 <div id="rfc.figure.u.59"></div><pre class="text"> GET /pub/WWW/ HTTP/1.1 1911 1913 Host: www.example.org 1912 </pre><p id="rfc.section.9.4.p. 5">A client <em class="bcp14">MUST</em> include a Host header field in all HTTP/1.1 request messages. If the requested URI does not include an Internet host name1914 </pre><p id="rfc.section.9.4.p.6">A client <em class="bcp14">MUST</em> include a Host header field in all HTTP/1.1 request messages. If the requested URI does not include an Internet host name 1913 1915 for the service being requested, then the Host header field <em class="bcp14">MUST</em> be given with an empty value. An HTTP/1.1 proxy <em class="bcp14">MUST</em> ensure that any request message it forwards does contain an appropriate Host header field that identifies the service being 1914 1916 requested by the proxy. All Internet-based HTTP/1.1 servers <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status code to any HTTP/1.1 request message which lacks a Host header field. 1915 1917 </p> 1916 <p id="rfc.section.9.4.p. 6">See Sections <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">4.2</a> and <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses">B.1.1</a> for other requirements relating to Host.1918 <p id="rfc.section.9.4.p.7">See Sections <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">4.2</a> and <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses">B.1.1</a> for other requirements relating to Host. 1917 1919 </p> 1918 1920 <div id="rfc.iref.t.2"></div> 1919 1921 <div id="rfc.iref.h.11"></div> 1920 1922 <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a> <a id="header.te" href="#header.te">TE</a></h2> 1921 <p id="rfc.section.9.5.p.1">The "TE" request-header field indicates what extension transfer-codings it is willing to accept in the response and whether 1922 or not it is willing to accept trailer fields in a chunked transfer-coding. Its value may consist of the keyword "trailers" 1923 and/or a comma-separated list of extension transfer-coding names with optional accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section 6.2</a>). 1923 <p id="rfc.section.9.5.p.1">The "TE" request-header field indicates what extension transfer-codings it is willing to accept in the response, and whether 1924 or not it is willing to accept trailer fields in a chunked transfer-coding. 1925 </p> 1926 <p id="rfc.section.9.5.p.2">Its value may consist of the keyword "trailers" and/or a comma-separated list of extension transfer-coding names with optional 1927 accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section 6.2</a>). 1924 1928 </p> 1925 1929 <div id="rfc.figure.u.60"></div><pre class="inline"><span id="rfc.iref.g.98"></span><span id="rfc.iref.g.99"></span><span id="rfc.iref.g.100"></span><span id="rfc.iref.g.101"></span><span id="rfc.iref.g.102"></span> <a href="#header.te" class="smpl">TE</a> = "TE" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.te" class="smpl">TE-v</a> … … 1928 1932 <a href="#header.te" class="smpl">te-params</a> = <a href="#rule.whitespace" class="smpl">OWS</a> ";" <a href="#rule.whitespace" class="smpl">OWS</a> "q=" <a href="#quality.values" class="smpl">qvalue</a> *( <a href="#header.te" class="smpl">te-ext</a> ) 1929 1933 <a href="#header.te" class="smpl">te-ext</a> = <a href="#rule.whitespace" class="smpl">OWS</a> ";" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#rule.token.separators" class="smpl">token</a> [ "=" ( <a href="#rule.token.separators" class="smpl">token</a> / <a href="#rule.quoted-string" class="smpl">quoted-string</a> ) ] 1930 </pre><p id="rfc.section.9.5.p. 3">The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer-coding,1934 </pre><p id="rfc.section.9.5.p.4">The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer-coding, 1931 1935 as defined in <a href="#chunked.encoding" title="Chunked Transfer Coding">Section 6.2.1</a>. This keyword is reserved for use with transfer-coding values even though it does not itself represent a transfer-coding. 1932 1936 </p> 1933 <p id="rfc.section.9.5.p. 4">Examples of its use are:</p>1937 <p id="rfc.section.9.5.p.5">Examples of its use are:</p> 1934 1938 <div id="rfc.figure.u.61"></div><pre class="text"> TE: deflate 1935 1939 TE: 1936 1940 TE: trailers, deflate;q=0.5 1937 </pre><p id="rfc.section.9.5.p. 6">The TE header field only applies to the immediate connection. Therefore, the keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section 9.1</a>) whenever TE is present in an HTTP/1.1 message.1938 </p> 1939 <p id="rfc.section.9.5.p. 7">A server tests whether a transfer-coding is acceptable, according to a TE field, using these rules: </p>1941 </pre><p id="rfc.section.9.5.p.7">The TE header field only applies to the immediate connection. Therefore, the keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section 9.1</a>) whenever TE is present in an HTTP/1.1 message. 1942 </p> 1943 <p id="rfc.section.9.5.p.8">A server tests whether a transfer-coding is acceptable, according to a TE field, using these rules: </p> 1940 1944 <ol> 1941 1945 <li> … … 1960 1964 </li> 1961 1965 </ol> 1962 <p id="rfc.section.9.5.p. 8">If the TE field-value is empty or if no TE field is present, the only transfer-coding is "chunked". A message with no transfer-coding1966 <p id="rfc.section.9.5.p.9">If the TE field-value is empty or if no TE field is present, the only transfer-coding is "chunked". A message with no transfer-coding 1963 1967 is always acceptable. 1964 1968 </p> … … 1986 1990 <div id="rfc.iref.h.13"></div> 1987 1991 <h2 id="rfc.section.9.7"><a href="#rfc.section.9.7">9.7</a> <a id="header.transfer-encoding" href="#header.transfer-encoding">Transfer-Encoding</a></h2> 1988 <p id="rfc.section.9.7.p.1">The "Transfer-Encoding" general-header field indicates what (if any) type of transformation has been applied to the message1989 body in order to safely transfer it between the sender and the recipient. This differs from the content-coding in that the1990 transfer-coding is a property of the message, not of the entity.1992 <p id="rfc.section.9.7.p.1">The "Transfer-Encoding" general-header field indicates what transfer-codings (if any) have been applied to the message body. 1993 It differs from Content-Encoding (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) in that transfer-codings are a property of the message (and therefore are removed by intermediaries), whereas content-codings 1994 are not. 1991 1995 </p> 1992 1996 <div id="rfc.figure.u.63"></div><pre class="inline"><span id="rfc.iref.g.105"></span><span id="rfc.iref.g.106"></span> <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = "Transfer-Encoding" ":" <a href="#rule.whitespace" class="smpl">OWS</a> … … 2002 2006 <div id="rfc.iref.h.14"></div> 2003 2007 <h2 id="rfc.section.9.8"><a href="#rfc.section.9.8">9.8</a> <a id="header.upgrade" href="#header.upgrade">Upgrade</a></h2> 2004 <p id="rfc.section.9.8.p.1">The "Upgrade" general-header field allows the client to specify what additional communication protocols it supports and would 2005 like to use if the server finds it appropriate to switch protocols. The server <em class="bcp14">MUST</em> use the Upgrade header field within a 101 (Switching Protocols) response to indicate which protocol(s) are being switched. 2008 <p id="rfc.section.9.8.p.1">The "Upgrade" general-header field allows the client to specify what additional communication protocols it would like to use, 2009 if the server chooses to switch protocols. Additionally, the server <em class="bcp14">MUST</em> use the Upgrade header field within a 101 (Switching Protocols) response to indicate which protocol(s) are being switched 2010 to. 2006 2011 </p> 2007 2012 <div id="rfc.figure.u.65"></div><pre class="inline"><span id="rfc.iref.g.107"></span><span id="rfc.iref.g.108"></span> <a href="#header.upgrade" class="smpl">Upgrade</a> = "Upgrade" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.upgrade" class="smpl">Upgrade-v</a> … … 2683 2688 </p> 2684 2689 <p id="rfc.section.A.p.4">The character set of an entity-body <em class="bcp14">SHOULD</em> be labeled as the lowest common denominator of the character codes used within that body, with the exception that not labeling 2685 the entity is preferred over labeling the entity with the labels US-ASCII or ISO-8859-1. See <a href="#Part3" id="rfc.xref.Part3. 8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.2690 the entity is preferred over labeling the entity with the labels US-ASCII or ISO-8859-1. See <a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. 2686 2691 </p> 2687 2692 <p id="rfc.section.A.p.5">Additional rules for requirements on parsing and encoding of dates and other potential problems with date encodings include:</p> … … 2773 2778 <p id="rfc.section.B.3.p.2">Transfer-coding and message lengths all interact in ways that required fixing exactly when chunked encoding is used (to allow 2774 2779 for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are 2775 computed. (Sections <a href="#transfer.codings" title="Transfer Codings">6.2</a>, <a href="#message.length" title="Message Length">3.4</a>, <a href="#header.content-length" id="rfc.xref.header.content-length.3" title="Content-Length">9.2</a>, see also <a href="#Part3" id="rfc.xref.Part3. 9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a> and <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>)2780 computed. (Sections <a href="#transfer.codings" title="Transfer Codings">6.2</a>, <a href="#message.length" title="Message Length">3.4</a>, <a href="#header.content-length" id="rfc.xref.header.content-length.3" title="Content-Length">9.2</a>, see also <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a> and <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) 2776 2781 </p> 2777 2782 <p id="rfc.section.B.3.p.3">The use and interpretation of HTTP version numbers has been clarified by <a href="#RFC2145" id="rfc.xref.RFC2145.3"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a>. Require proxies to upgrade requests to highest protocol version they support to deal with problems discovered in HTTP/1.0 … … 3444 3449 </ul> 3445 3450 </li> 3446 <li class="indline1"><em>Part3</em> <a class="iref" href="#rfc.xref.Part3.1">1</a>, <a class="iref" href="#rfc.xref.Part3.2">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.3">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.4">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.5">4</a>, <a class="iref" href="#rfc.xref.Part3.6">5</a>, <a class="iref" href="#rfc.xref.Part3.7">6.4</a>, <a class="iref" href="#Part3"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part3.8">A</a>, <a class="iref" href="#rfc.xref.Part3.9">B.3</a><ul class="ind"> 3451 <li class="indline1"><em>Part3</em> <a class="iref" href="#rfc.xref.Part3.1">1</a>, <a class="iref" href="#rfc.xref.Part3.2">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.3">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.4">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.5">4</a>, <a class="iref" href="#rfc.xref.Part3.6">5</a>, <a class="iref" href="#rfc.xref.Part3.7">6.4</a>, <a class="iref" href="#rfc.xref.Part3.8">9.7</a>, <a class="iref" href="#Part3"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part3.9">A</a>, <a class="iref" href="#rfc.xref.Part3.10">B.3</a><ul class="ind"> 3452 <li class="indline1"><em>Section 2.2</em> <a class="iref" href="#rfc.xref.Part3.8">9.7</a></li> 3447 3453 <li class="indline1"><em>Section 2.3</em> <a class="iref" href="#rfc.xref.Part3.2">1.2.2</a></li> 3448 3454 <li class="indline1"><em>Section 3.1</em> <a class="iref" href="#rfc.xref.Part3.4">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.5">4</a>, <a class="iref" href="#rfc.xref.Part3.6">5</a></li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r697 r698 2554 2554 <t> 2555 2555 The "Content-Length" entity-header field indicates the size of the 2556 entity-body, in number of OCTETs , sent to the recipient or,2557 in the case of the HEAD method, the size of the entity-body that2558 would have been senthad the request been a GET.2556 entity-body, in number of OCTETs. In the case of responses to the HEAD 2557 method, it indicates the size of the entity-body that would have been sent 2558 had the request been a GET. 2559 2559 </t> 2560 2560 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Length"/><iref primary="true" item="Grammar" subitem="Content-Length-v"/> … … 2674 2674 <t> 2675 2675 The "Host" request-header field specifies the Internet host and port 2676 number of the resource being requested, as obtained from the original 2677 URI given by the user or referring resource (generally an http URI, 2678 as described in <xref target="http.uri"/>). The Host field value &MUST; represent 2679 the naming authority of the origin server or gateway given by the 2680 original URL. This allows the origin server or gateway to 2681 differentiate between internally-ambiguous URLs, such as the root "/" 2682 URL of a server for multiple host names on a single IP address. 2676 number of the resource being requested, allowing the origin server or 2677 gateway to differentiate between internally-ambiguous URLs, such as the root 2678 "/" URL of a server for multiple host names on a single IP address. 2679 </t> 2680 <t> 2681 The Host field value &MUST; represent the naming authority of the origin 2682 server or gateway given by the original URL obtained from the user or 2683 referring resource (generally an http URI, as described in 2684 <xref target="http.uri"/>). 2683 2685 </t> 2684 2686 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Host"/><iref primary="true" item="Grammar" subitem="Host-v"/> … … 2724 2726 <t> 2725 2727 The "TE" request-header field indicates what extension transfer-codings 2726 it is willing to accept in the response and whether or not it is 2727 willing to accept trailer fields in a chunked transfer-coding. Its 2728 value may consist of the keyword "trailers" and/or a comma-separated 2728 it is willing to accept in the response, and whether or not it is 2729 willing to accept trailer fields in a chunked transfer-coding. 2730 </t> 2731 <t> 2732 Its value may consist of the keyword "trailers" and/or a comma-separated 2729 2733 list of extension transfer-coding names with optional accept 2730 2734 parameters (as described in <xref target="transfer.codings"/>). … … 2838 2842 <x:anchor-alias value="Transfer-Encoding-v"/> 2839 2843 <t> 2840 The "Transfer-Encoding" general-header field indicates what (if any)2841 type of transformation has been applied to the message body in order2842 to safely transfer it between the sender and the recipient. This2843 differs from the content-coding in that the transfer-coding is a2844 property of the message, not of the entity.2844 The "Transfer-Encoding" general-header field indicates what transfer-codings 2845 (if any) have been applied to the message body. It differs from 2846 Content-Encoding (&content-codings;) in that transfer-codings are a property 2847 of the message (and therefore are removed by intermediaries), whereas 2848 content-codings are not. 2845 2849 </t> 2846 2850 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Transfer-Encoding"/><iref primary="true" item="Grammar" subitem="Transfer-Encoding-v"/> … … 2874 2878 <t> 2875 2879 The "Upgrade" general-header field allows the client to specify what 2876 additional communication protocols it supports and would like to use2877 if the server finds it appropriate to switch protocols. The server2878 &MUST; use the Upgrade header field within a 101 (Switching Protocols)2879 response to indicate which protocol(s) are being switched.2880 additional communication protocols it would like to use, if the server 2881 chooses to switch protocols. Additionally, the server &MUST; use the Upgrade 2882 header field within a 101 (Switching Protocols) response to indicate which 2883 protocol(s) are being switched to. 2880 2884 </t> 2881 2885 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Upgrade"/><iref primary="true" item="Grammar" subitem="Upgrade-v"/> -
draft-ietf-httpbis/latest/p2-semantics.html
r697 r698 399 399 <meta name="DC.Creator" content="Reschke, J. F."> 400 400 <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 401 <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-2 5">401 <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-26"> 402 402 <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2616"> 403 403 <meta name="DC.Description.Abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request-header fields, response status codes, and response-header fields."> … … 436 436 </tr> 437 437 <tr> 438 <td class="header left">Expires: March 29, 2010</td>438 <td class="header left">Expires: March 30, 2010</td> 439 439 <td class="header right">H. Frystyk</td> 440 440 </tr> … … 485 485 <tr> 486 486 <td class="header left"></td> 487 <td class="header right">September 2 5, 2009</td>487 <td class="header right">September 26, 2009</td> 488 488 </tr> 489 489 </table> … … 509 509 <p>The list of Internet-Draft Shadow Directories can be accessed at <<a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>>. 510 510 </p> 511 <p>This Internet-Draft will expire in March 29, 2010.</p>511 <p>This Internet-Draft will expire in March 30, 2010.</p> 512 512 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 513 513 <p>Copyright © 2009 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1504 1504 <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a> <a id="header.allow" href="#header.allow">Allow</a></h2> 1505 1505 <p id="rfc.section.9.1.p.1">The "Allow" response-header field lists the set of methods advertised as supported by the resource identified by the request-target. 1506 The purpose of this field is strictly to inform the recipient of valid methods associated with the resource. An Allow header 1507 field <em class="bcp14">MUST</em> be present in a 405 (Method Not Allowed) response. 1506 The purpose of this field is strictly to inform the recipient of valid methods associated with the resource. 1508 1507 </p> 1509 1508 <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span> <a href="#header.allow" class="smpl">Allow</a> = "Allow" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.allow" class="smpl">Allow-v</a> … … 1566 1565 <div id="rfc.iref.h.5"></div> 1567 1566 <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a> <a id="header.location" href="#header.location">Location</a></h2> 1568 <p id="rfc.section.9.4.p.1">The "Location" response-header field is used for the identification of a new resource or to redirect the recipient to a location 1569 other than the request-target for completion of the request. For 201 (Created) responses, the Location is that of the new 1570 resource which was created by the request. For 3xx responses, the location <em class="bcp14">SHOULD</em> indicate the server's preferred URI for automatic redirection to the resource. The field value consists of a single URI. 1571 </p> 1567 <p id="rfc.section.9.4.p.1">The "Location" response-header field is used to identify a newly created resource, or to redirect the recipient to a different 1568 location for completion of the request. 1569 </p> 1570 <p id="rfc.section.9.4.p.2">For 201 (Created) responses, the Location is the URI of the new resource which was created by the request. For 3xx responses, 1571 the location <em class="bcp14">SHOULD</em> indicate the server's preferred URI for automatic redirection to the resource. 1572 </p> 1573 <p id="rfc.section.9.4.p.3">The field value consists of a single URI.</p> 1572 1574 <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span> <a href="#header.location" class="smpl">Location</a> = "Location" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.location" class="smpl">Location-v</a> 1573 1575 <a href="#header.location" class="smpl">Location-v</a> = <a href="#abnf.dependencies" class="smpl">URI</a> 1574 </pre><p id="rfc.section.9.4.p. 3">An example is:</p>1576 </pre><p id="rfc.section.9.4.p.5">An example is:</p> 1575 1577 <div id="rfc.figure.u.18"></div><pre class="text"> Location: http://www.example.org/pub/WWW/People.html 1576 </pre><p id="rfc.section.9.4.p. 5">There are circumstances in which a fragment identifier in a Location URI would not be appropriate: </p>1578 </pre><p id="rfc.section.9.4.p.7">There are circumstances in which a fragment identifier in a Location URI would not be appropriate: </p> 1577 1579 <ul> 1578 1580 <li>With a 201 Created response, because in this usage the Location header specifies the URI for the entire created resource.</li> … … 1587 1589 <div id="rfc.iref.h.6"></div> 1588 1590 <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a> <a id="header.max-forwards" href="#header.max-forwards">Max-Forwards</a></h2> 1589 <p id="rfc.section.9.5.p.1">The "Max-Forwards" request-header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section 7.8</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section 7.2</a>) methods to limit the number of proxies or gateways that can forward the request to the next inbound server. This can be1590 useful when the client is attempting to trace a request chainwhich appears to be failing or looping in mid-chain.1591 <p id="rfc.section.9.5.p.1">The "Max-Forwards" request-header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section 7.8</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section 7.2</a>) methods to limit the number of times that the request is forwarded by proxies or gateways. This can be useful when the client 1592 is attempting to trace a request which appears to be failing or looping in mid-chain. 1591 1593 </p> 1592 1594 <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.20"></span><span id="rfc.iref.g.21"></span> <a href="#header.max-forwards" class="smpl">Max-Forwards</a> = "Max-Forwards" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.max-forwards" class="smpl">Max-Forwards-v</a> … … 1601 1603 <div id="rfc.iref.h.7"></div> 1602 1604 <h2 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a> <a id="header.referer" href="#header.referer">Referer</a></h2> 1603 <p id="rfc.section.9.6.p.1">The "Referer" [sic] request-header field allows the client to specify , for the server's benefit, the address (URI) of the1604 resource from which the request-targetwas obtained (the "referrer", although the header field is misspelled.).1605 <p id="rfc.section.9.6.p.1">The "Referer" [sic] request-header field allows the client to specify the URI of the resource from which the request-target 1606 was obtained (the "referrer", although the header field is misspelled.). 1605 1607 </p> 1606 1608 <p id="rfc.section.9.6.p.2">The Referer header allows servers to generate lists of back-links to resources for interest, logging, optimized caching, etc. … … 1624 1626 <p id="rfc.section.9.7.p.1">The response-header "Retry-After" field can be used with a 503 (Service Unavailable) response to indicate how long the service 1625 1627 is expected to be unavailable to the requesting client. This field <em class="bcp14">MAY</em> also be used with any 3xx (Redirection) response to indicate the minimum time the user-agent is asked wait before issuing 1626 the redirected request. The value of this field can be either an HTTP-date or an integer number of seconds (in decimal) after1627 the time of the response.1628 < /p>1628 the redirected request. 1629 </p> 1630 <p id="rfc.section.9.7.p.2">The value of this field can be either an HTTP-date or an integer number of seconds (in decimal) after the time of the response.</p> 1629 1631 <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span> <a href="#header.retry-after" class="smpl">Retry-After</a> = "Retry-After" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.retry-after" class="smpl">Retry-After-v</a> 1630 1632 <a href="#header.retry-after" class="smpl">Retry-After-v</a> = <a href="#abnf.dependencies" class="smpl">HTTP-date</a> / <a href="#rule.delta-seconds" class="smpl">delta-seconds</a> 1631 1633 </pre><div id="rule.delta-seconds"> 1632 <p id="rfc.section.9.7.p. 3"> Time spans are non-negative decimal integers, representing time in seconds.</p>1634 <p id="rfc.section.9.7.p.4"> Time spans are non-negative decimal integers, representing time in seconds.</p> 1633 1635 </div> 1634 1636 <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.26"></span> <a href="#rule.delta-seconds" class="smpl">delta-seconds</a> = 1*<a href="#notation" class="smpl">DIGIT</a> 1635 </pre><p id="rfc.section.9.7.p. 5">Two examples of its use are</p>1637 </pre><p id="rfc.section.9.7.p.6">Two examples of its use are</p> 1636 1638 <div id="rfc.figure.u.24"></div><pre class="text"> Retry-After: Fri, 31 Dec 1999 23:59:59 GMT 1637 1639 Retry-After: 120 1638 </pre><p id="rfc.section.9.7.p. 7">In the latter example, the delay is 2 minutes.</p>1640 </pre><p id="rfc.section.9.7.p.8">In the latter example, the delay is 2 minutes.</p> 1639 1641 <div id="rfc.iref.s.43"></div> 1640 1642 <div id="rfc.iref.h.9"></div> 1641 1643 <h2 id="rfc.section.9.8"><a href="#rfc.section.9.8">9.8</a> <a id="header.server" href="#header.server">Server</a></h2> 1642 <p id="rfc.section.9.8.p.1">The "Server" response-header field contains information about the software used by the origin server to handle the request. 1643 The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance1644 foridentifying the application.1644 <p id="rfc.section.9.8.p.1">The "Server" response-header field contains information about the software used by the origin server to handle the request.</p> 1645 <p id="rfc.section.9.8.p.2">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for 1646 identifying the application. 1645 1647 </p> 1646 1648 <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.27"></span><span id="rfc.iref.g.28"></span> <a href="#header.server" class="smpl">Server</a> = "Server" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.server" class="smpl">Server-v</a> 1647 1649 <a href="#header.server" class="smpl">Server-v</a> = <a href="#abnf.dependencies" class="smpl">product</a> 1648 1650 *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#abnf.dependencies" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) ) 1649 </pre><p id="rfc.section.9.8.p. 3">Example:</p>1651 </pre><p id="rfc.section.9.8.p.4">Example:</p> 1650 1652 <div id="rfc.figure.u.26"></div><pre class="text"> Server: CERN/3.0 libwww/2.17 1651 </pre><p id="rfc.section.9.8.p. 5">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server response-header. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).1653 </pre><p id="rfc.section.9.8.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server response-header. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 1652 1654 </p> 1653 1655 <div class="note"> … … 1662 1664 <p id="rfc.section.9.9.p.1">The "User-Agent" request-header field contains information about the user agent originating the request. This is for statistical 1663 1665 purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses 1664 to avoid particular user agent limitations. User agents <em class="bcp14">SHOULD</em> include this field with requests. The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments identifying the agent and any subproducts which form a significant part of the user agent. By convention, the 1665 product tokens are listed in order of their significance for identifying the application. 1666 to avoid particular user agent limitations. 1667 </p> 1668 <p id="rfc.section.9.9.p.2">User agents <em class="bcp14">SHOULD</em> include this field with requests. The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the agent and any subproducts which form a significant part of the user agent. By convention, the product tokens 1669 are listed in order of their significance for identifying the application. 1666 1670 </p> 1667 1671 <div id="rfc.figure.u.27"></div><pre class="inline"><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span> <a href="#header.user-agent" class="smpl">User-Agent</a> = "User-Agent" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.user-agent" class="smpl">User-Agent-v</a> 1668 1672 <a href="#header.user-agent" class="smpl">User-Agent-v</a> = <a href="#abnf.dependencies" class="smpl">product</a> 1669 1673 *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#abnf.dependencies" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) ) 1670 </pre><p id="rfc.section.9.9.p. 3">Example:</p>1674 </pre><p id="rfc.section.9.9.p.4">Example:</p> 1671 1675 <div id="rfc.figure.u.28"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3 1672 1676 </pre><h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> … … 2290 2294 </p> 2291 2295 <p id="rfc.section.A.2.p.8">In the description of the Server header, the Via field was described as a SHOULD. The requirement was and is stated correctly 2292 in the description of the Via header in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1. 28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 9.8</a>)2296 in the description of the Via header in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 9.8</a>) 2293 2297 </p> 2294 2298 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> … … 2719 2723 </li> 2720 2724 <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind"> 2721 <li class="indline1"><em>Part1</em> <a class="iref" href="#rfc.xref.Part1.1">1</a>, <a class="iref" href="#rfc.xref.Part1.2">1.2</a>, <a class="iref" href="#rfc.xref.Part1.3">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.7">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.8">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.9">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.11">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.12">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.14">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.15">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.16">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.17">3</a>, <a class="iref" href="#rfc.xref.Part1.18">3</a>, <a class="iref" href="#rfc.xref.Part1.19">6</a>, <a class="iref" href="#rfc.xref.Part1.20">7.8</a>, <a class="iref" href="#rfc.xref.Part1.21">7.8</a>, <a class="iref" href="#rfc.xref.Part1.22">8.1.1</a>, <a class="iref" href="#rfc.xref.Part1.23">8.5.6</a>, <a class="iref" href="#rfc.xref.Part1.24">9.2</a>, <a class="iref" href="#rfc.xref.Part1.25">9.8</a>, <a class="iref" href="#rfc.xref.Part1.26">9.8</a>, <a class="iref" href="#rfc.xref.Part1.27">9. 9</a>, <a class="iref" href="#Part1"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part1.28">A.2</a><ul class="ind">2725 <li class="indline1"><em>Part1</em> <a class="iref" href="#rfc.xref.Part1.1">1</a>, <a class="iref" href="#rfc.xref.Part1.2">1.2</a>, <a class="iref" href="#rfc.xref.Part1.3">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.7">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.8">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.9">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.11">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.12">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.14">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.15">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.16">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.17">3</a>, <a class="iref" href="#rfc.xref.Part1.18">3</a>, <a class="iref" href="#rfc.xref.Part1.19">6</a>, <a class="iref" href="#rfc.xref.Part1.20">7.8</a>, <a class="iref" href="#rfc.xref.Part1.21">7.8</a>, <a class="iref" href="#rfc.xref.Part1.22">8.1.1</a>, <a class="iref" href="#rfc.xref.Part1.23">8.5.6</a>, <a class="iref" href="#rfc.xref.Part1.24">9.2</a>, <a class="iref" href="#rfc.xref.Part1.25">9.8</a>, <a class="iref" href="#rfc.xref.Part1.26">9.8</a>, <a class="iref" href="#rfc.xref.Part1.27">9.8</a>, <a class="iref" href="#rfc.xref.Part1.28">9.9</a>, <a class="iref" href="#rfc.xref.Part1.29">9.9</a>, <a class="iref" href="#Part1"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part1.30">A.2</a><ul class="ind"> 2722 2726 <li class="indline1"><em>Section 1.2</em> <a class="iref" href="#rfc.xref.Part1.2">1.2</a></li> 2723 2727 <li class="indline1"><em>Section 1.2.2</em> <a class="iref" href="#rfc.xref.Part1.3">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.7">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.8">1.2.1</a></li> 2724 2728 <li class="indline1"><em>Section 2.5</em> <a class="iref" href="#rfc.xref.Part1.23">8.5.6</a></li> 2725 2729 <li class="indline1"><em>Section 2.6</em> <a class="iref" href="#rfc.xref.Part1.9">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.11">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.16">1.2.2</a></li> 2726 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.Part1.10">1.2.2</a> </li>2730 <li class="indline1"><em>Section 3.2</em> <a class="iref" href="#rfc.xref.Part1.10">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.26">9.8</a>, <a class="iref" href="#rfc.xref.Part1.29">9.9</a></li> 2727 2731 <li class="indline1"><em>Section 3.3</em> <a class="iref" href="#rfc.xref.Part1.19">6</a></li> 2728 2732 <li class="indline1"><em>Section 6.1</em> <a class="iref" href="#rfc.xref.Part1.12">1.2.2</a></li> 2729 <li class="indline1"><em>Section 6.3</em> <a class="iref" href="#rfc.xref.Part1.14">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.25">9.8</a>, <a class="iref" href="#rfc.xref.Part1.2 7">9.9</a></li>2733 <li class="indline1"><em>Section 6.3</em> <a class="iref" href="#rfc.xref.Part1.14">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.25">9.8</a>, <a class="iref" href="#rfc.xref.Part1.28">9.9</a></li> 2730 2734 <li class="indline1"><em>Section 7.2.3</em> <a class="iref" href="#rfc.xref.Part1.22">8.1.1</a>, <a class="iref" href="#rfc.xref.Part1.24">9.2</a></li> 2731 2735 <li class="indline1"><em>Section 9.4</em> <a class="iref" href="#rfc.xref.Part1.17">3</a></li> 2732 2736 <li class="indline1"><em>Section 9.8</em> <a class="iref" href="#rfc.xref.Part1.15">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.18">3</a></li> 2733 <li class="indline1"><em>Section 9.9</em> <a class="iref" href="#rfc.xref.Part1.20">7.8</a>, <a class="iref" href="#rfc.xref.Part1.2 6">9.8</a>, <a class="iref" href="#rfc.xref.Part1.28">A.2</a></li>2737 <li class="indline1"><em>Section 9.9</em> <a class="iref" href="#rfc.xref.Part1.20">7.8</a>, <a class="iref" href="#rfc.xref.Part1.27">9.8</a>, <a class="iref" href="#rfc.xref.Part1.30">A.2</a></li> 2734 2738 <li class="indline1"><em>Section 10.3.1</em> <a class="iref" href="#rfc.xref.Part1.21">7.8</a></li> 2735 2739 </ul> -
draft-ietf-httpbis/latest/p2-semantics.xml
r697 r698 1871 1871 supported by the resource identified by the request-target. The purpose of 1872 1872 this field is strictly to inform the recipient of valid methods 1873 associated with the resource. An Allow header field &MUST; be 1874 present in a 405 (Method Not Allowed) response. 1873 associated with the resource. 1875 1874 </t> 1876 1875 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Allow"/><iref primary="true" item="Grammar" subitem="Allow-v"/> … … 2006 2005 <x:anchor-alias value="Location-v"/> 2007 2006 <t> 2008 The "Location" response-header field is used for the identification of a 2009 new resource or to redirect the recipient to a location other than the 2010 request-target for completion of the request. For 201 (Created) 2011 responses, the Location is that of the new resource which was created 2012 by the request. For 3xx responses, the location &SHOULD; indicate the 2013 server's preferred URI for automatic redirection to the resource. The 2014 field value consists of a single URI. 2007 The "Location" response-header field is used to identify a newly created 2008 resource, or to redirect the recipient to a different location for 2009 completion of the request. 2010 </t> 2011 <t> 2012 For 201 (Created) responses, the Location is the URI of the new resource 2013 which was created by the request. For 3xx responses, the location &SHOULD; 2014 indicate the server's preferred URI for automatic redirection to the 2015 resource. 2016 </t> 2017 <t> 2018 The field value consists of a single URI. 2015 2019 </t> 2016 2020 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Location"/><iref primary="true" item="Grammar" subitem="Location-v"/> … … 2049 2053 <t> 2050 2054 The "Max-Forwards" request-header field provides a mechanism with the 2051 TRACE (<xref target="TRACE"/>) and OPTIONS (<xref target="OPTIONS"/>) methods to limit the 2052 number of proxies or gateways that can forward the request to the 2053 next inbound server. This can be useful when the client is attempting 2054 to trace a request chain which appears to be failing or looping in 2055 mid-chain. 2055 TRACE (<xref target="TRACE"/>) and OPTIONS (<xref target="OPTIONS"/>) 2056 methods to limit the number of times that the request is forwarded by 2057 proxies or gateways. This can be useful when the client is attempting to 2058 trace a request which appears to be failing or looping in mid-chain. 2056 2059 </t> 2057 2060 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Max-Forwards"/><iref primary="true" item="Grammar" subitem="Max-Forwards-v"/> … … 2085 2088 <x:anchor-alias value="Referer-v"/> 2086 2089 <t> 2087 The "Referer" [sic] request-header field allows the client to specify, for 2088 the server's benefit, the address (URI) of the resource from which the 2089 request-target was obtained (the "referrer", although the header field is 2090 misspelled.). 2090 The "Referer" [sic] request-header field allows the client to specify the 2091 URI of the resource from which the request-target was obtained (the 2092 "referrer", although the header field is misspelled.). 2091 2093 </t> 2092 2094 <t> … … 2131 2133 be unavailable to the requesting client. This field &MAY; also be used 2132 2134 with any 3xx (Redirection) response to indicate the minimum time the 2133 user-agent is asked wait before issuing the redirected request. The 2134 value of this field can be either an HTTP-date or an integer number 2135 user-agent is asked wait before issuing the redirected request. 2136 </t> 2137 <t> 2138 The value of this field can be either an HTTP-date or an integer number 2135 2139 of seconds (in decimal) after the time of the response. 2136 2140 </t> … … 2166 2170 <t> 2167 2171 The "Server" response-header field contains information about the 2168 software used by the origin server to handle the request. The field 2169 can contain multiple product tokens (&product-tokens;) and comments 2170 identifying the server and any significant subproducts. The product 2171 tokens are listed in order of their significance for identifying the 2172 application. 2172 software used by the origin server to handle the request. 2173 </t> 2174 <t> 2175 The field can contain multiple product tokens (&product-tokens;) and 2176 comments (&header-fields;) identifying the server and any significant 2177 subproducts. The product tokens are listed in order of their significance 2178 for identifying the application. 2173 2179 </t> 2174 2180 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Server"/><iref primary="true" item="Grammar" subitem="Server-v"/> … … 2209 2215 the tracing of protocol violations, and automated recognition of user 2210 2216 agents for the sake of tailoring responses to avoid particular user 2211 agent limitations. User agents &SHOULD; include this field with 2212 requests. The field can contain multiple product tokens (&product-tokens;) 2213 and comments identifying the agent and any subproducts which form a 2214 significant part of the user agent. By convention, the product tokens 2215 are listed in order of their significance for identifying the 2216 application. 2217 agent limitations. 2218 </t> 2219 <t> 2220 User agents &SHOULD; include this field with requests. The field can contain 2221 multiple product tokens (&product-tokens;) and comments (&header-fields;) 2222 identifying the agent and any subproducts which form a significant part of 2223 the user agent. By convention, the product tokens are listed in order of 2224 their significance for identifying the application. 2217 2225 </t> 2218 2226 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="User-Agent"/><iref primary="true" item="Grammar" subitem="User-Agent-v"/> -
draft-ietf-httpbis/latest/p3-payload.html
r697 r698 407 407 <meta name="DC.Creator" content="Reschke, J. F."> 408 408 <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest"> 409 <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-2 5">409 <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-26"> 410 410 <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2616"> 411 411 <meta name="DC.Description.Abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 3 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation."> … … 439 439 </tr> 440 440 <tr> 441 <td class="header left">Expires: March 29, 2010</td>441 <td class="header left">Expires: March 30, 2010</td> 442 442 <td class="header right">HP</td> 443 443 </tr> … … 492 492 <tr> 493 493 <td class="header left"></td> 494 <td class="header right">September 2 5, 2009</td>494 <td class="header right">September 26, 2009</td> 495 495 </tr> 496 496 </table> … … 516 516 <p>The list of Internet-Draft Shadow Directories can be accessed at <<a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>>. 517 517 </p> 518 <p>This Internet-Draft will expire in March 29, 2010.</p>518 <p>This Internet-Draft will expire in March 30, 2010.</p> 519 519 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 520 520 <p>Copyright © 2009 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1010 1010 <div id="rfc.iref.h.1"></div> 1011 1011 <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a> <a id="header.accept" href="#header.accept">Accept</a></h2> 1012 <p id="rfc.section.5.1.p.1">The "Accept" request-header field can be used to specify certain media types which are acceptable for the response. Accept1013 headers can be used to indicate that the request is specifically limited to a small set of desired types, as in the case of1014 a requestfor an in-line image.1012 <p id="rfc.section.5.1.p.1">The "Accept" request-header field can be used by user agents to specify response media types that are acceptable. Accept headers 1013 can be used to indicate that the request is specifically limited to a small set of desired types, as in the case of a request 1014 for an in-line image. 1015 1015 </p> 1016 1016 <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span> <a href="#header.accept" class="smpl">Accept</a> = "Accept" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.accept" class="smpl">Accept-v</a> … … 1112 1112 <div id="rfc.iref.h.2"></div> 1113 1113 <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a> <a id="header.accept-charset" href="#header.accept-charset">Accept-Charset</a></h2> 1114 <p id="rfc.section.5.2.p.1">The "Accept-Charset" request-header field can be used to indicate what character sets are acceptable for the response. This1115 field allows clients capable of understanding more comprehensive or special-purpose character sets to signal that capability1114 <p id="rfc.section.5.2.p.1">The "Accept-Charset" request-header field can be used by user agents to indicate what response character sets are acceptable. 1115 This field allows clients capable of understanding more comprehensive or special-purpose character sets to signal that capability 1116 1116 to a server which is capable of representing documents in those character sets. 1117 1117 </p> … … 1135 1135 <div id="rfc.iref.h.3"></div> 1136 1136 <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a> <a id="header.accept-encoding" href="#header.accept-encoding">Accept-Encoding</a></h2> 1137 <p id="rfc.section.5.3.p.1">The "Accept-Encoding" request-header field is similar to Accept, but restricts the content-codings (<a href="#content.codings" title="Content Codings">Section 2.2</a>) thatare acceptable in the response.1137 <p id="rfc.section.5.3.p.1">The "Accept-Encoding" request-header field can be used by user agents to indicate what response content-codings (<a href="#content.codings" title="Content Codings">Section 2.2</a>) are acceptable in the response. 1138 1138 </p> 1139 1139 <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span> <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> = "Accept-Encoding" ":" <a href="#core.rules" class="smpl">OWS</a> … … 1186 1186 <div id="rfc.iref.h.4"></div> 1187 1187 <h2 id="rfc.section.5.4"><a href="#rfc.section.5.4">5.4</a> <a id="header.accept-language" href="#header.accept-language">Accept-Language</a></h2> 1188 <p id="rfc.section.5.4.p.1">The "Accept-Language" request-header field is similar to Accept, but restrictsthe set of natural languages that are preferred1189 as a response to the request. Language tags are defined in <a href="#language.tags" title="Language Tags">Section 2.4</a>.1188 <p id="rfc.section.5.4.p.1">The "Accept-Language" request-header field can be used by user agents to indicate the set of natural languages that are preferred 1189 in the response. Language tags are defined in <a href="#language.tags" title="Language Tags">Section 2.4</a>. 1190 1190 </p> 1191 1191 <div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span><span id="rfc.iref.g.26"></span> <a href="#header.accept-language" class="smpl">Accept-Language</a> = "Accept-Language" ":" <a href="#core.rules" class="smpl">OWS</a> … … 1237 1237 <div id="rfc.iref.h.5"></div> 1238 1238 <h2 id="rfc.section.5.5"><a href="#rfc.section.5.5">5.5</a> <a id="header.content-encoding" href="#header.content-encoding">Content-Encoding</a></h2> 1239 <p id="rfc.section.5.5.p.1">The "Content-Encoding" entity-header field is used as a modifier to the media-type. When present, its value indicates what 1240 additional content codings have been applied to the entity-body, and thus what decoding mechanisms must be applied in order 1241 to obtain the media-type referenced by the Content-Type header field. Content-Encoding is primarily used to allow a document 1242 to be compressed without losing the identity of its underlying media type. 1239 <p id="rfc.section.5.5.p.1">The "Content-Encoding" entity-header field indicates what content-codings have been applied to the entity-body, and thus what 1240 decoding mechanisms must be applied in order to obtain the media-type referenced by the Content-Type header field. Content-Encoding 1241 is primarily used to allow a document to be compressed without losing the identity of its underlying media type. 1243 1242 </p> 1244 1243 <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.27"></span><span id="rfc.iref.g.28"></span> <a href="#header.content-encoding" class="smpl">Content-Encoding</a> = "Content-Encoding" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-encoding" class="smpl">Content-Encoding-v</a> … … 1260 1259 <div id="rfc.iref.h.6"></div> 1261 1260 <h2 id="rfc.section.5.6"><a href="#rfc.section.5.6">5.6</a> <a id="header.content-language" href="#header.content-language">Content-Language</a></h2> 1262 <p id="rfc.section.5.6.p.1">The "Content-Language" entity-header field describes the natural language(s) of the intended audience for the en closed entity.1263 Notethat this might not be equivalent to all the languages used within the entity-body.1261 <p id="rfc.section.5.6.p.1">The "Content-Language" entity-header field describes the natural language(s) of the intended audience for the entity. Note 1262 that this might not be equivalent to all the languages used within the entity-body. 1264 1263 </p> 1265 1264 <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span> <a href="#header.content-language" class="smpl">Content-Language</a> = "Content-Language" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-language" class="smpl">Content-Language-v</a> … … 1286 1285 <div id="rfc.iref.h.7"></div> 1287 1286 <h2 id="rfc.section.5.7"><a href="#rfc.section.5.7">5.7</a> <a id="header.content-location" href="#header.content-location">Content-Location</a></h2> 1288 <p id="rfc.section.5.7.p.1">The "Content-Location" entity-header field <em class="bcp14">MAY</em> be used to supply the resource location for the entity enclosed in the message when that entity is accessible from a location 1289 separate from the requested resource's URI. A server <em class="bcp14">SHOULD</em> provide a Content-Location for the variant corresponding to the response entity; especially in the case where a resource has 1287 <p id="rfc.section.5.7.p.1">The "Content-Location" entity-header field is used to supply a URI for the entity in the message when it is accessible from 1288 a location separate from the requested resource's URI. 1289 </p> 1290 <p id="rfc.section.5.7.p.2">A server <em class="bcp14">SHOULD</em> provide a Content-Location for the variant corresponding to the response entity, especially in the case where a resource has 1290 1291 multiple entities associated with it, and those entities actually have separate locations by which they might be individually 1291 1292 accessed, the server <em class="bcp14">SHOULD</em> provide a Content-Location for the particular variant which is returned. … … 1295 1296 <a href="#header.content-location" class="smpl">Content-Location-v</a> = 1296 1297 <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a> 1297 </pre><p id="rfc.section.5.7.p. 3">The value of Content-Location also defines the base URI for the entity.</p>1298 <p id="rfc.section.5.7.p. 4">The Content-Location value is not a replacement for the original requested URI; it is only a statement of the location of1298 </pre><p id="rfc.section.5.7.p.4">The value of Content-Location also defines the base URI for the entity.</p> 1299 <p id="rfc.section.5.7.p.5">The Content-Location value is not a replacement for the original requested URI; it is only a statement of the location of 1299 1300 the resource corresponding to this particular entity at the time of the request. Future requests <em class="bcp14">MAY</em> specify the Content-Location URI as the request-target if the desire is to identify the source of that particular entity. 1300 1301 </p> 1301 <p id="rfc.section.5.7.p. 5">A cache cannot assume that an entity with a Content-Location different from the URI used to retrieve it can be used to respond1302 <p id="rfc.section.5.7.p.6">A cache cannot assume that an entity with a Content-Location different from the URI used to retrieve it can be used to respond 1302 1303 to later requests on that Content-Location URI. However, the Content-Location can be used to differentiate between multiple 1303 1304 entities retrieved from a single requested resource, as described in <a href="p6-cache.html#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.6</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. 1304 1305 </p> 1305 <p id="rfc.section.5.7.p. 6">If the Content-Location is a relative URI, the relative URI is interpreted relative to the request-target.</p>1306 <p id="rfc.section.5.7.p. 7">The meaning of the Content-Location header in requests is undefined; servers are free to ignore it in those cases.</p>1306 <p id="rfc.section.5.7.p.7">If the Content-Location is a relative URI, the relative URI is interpreted relative to the request-target.</p> 1307 <p id="rfc.section.5.7.p.8">The meaning of the Content-Location header in requests is undefined; servers are free to ignore it in those cases.</p> 1307 1308 <div id="rfc.iref.c.10"></div> 1308 1309 <div id="rfc.iref.h.8"></div> … … 1346 1347 <div id="rfc.iref.h.9"></div> 1347 1348 <h2 id="rfc.section.5.9"><a href="#rfc.section.5.9">5.9</a> <a id="header.content-type" href="#header.content-type">Content-Type</a></h2> 1348 <p id="rfc.section.5.9.p.1">The "Content-Type" entity-header field indicates the media type of the entity-body sent to the recipient or, in the case of1349 the HEAD method, the media type thatwould have been sent had the request been a GET.1349 <p id="rfc.section.5.9.p.1">The "Content-Type" entity-header field indicates the media type of the entity-body. In the case of responses to the HEAD method, 1350 the media type is that which would have been sent had the request been a GET. 1350 1351 </p> 1351 1352 <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.35"></span><span id="rfc.iref.g.36"></span> <a href="#header.content-type" class="smpl">Content-Type</a> = "Content-Type" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-type" class="smpl">Content-Type-v</a> -
draft-ietf-httpbis/latest/p3-payload.xml
r697 r698 983 983 <x:anchor-alias value="media-range"/> 984 984 <t> 985 The "Accept" request-header field can be used to specify certain media 986 types which are acceptable for the response. Accept headers can be 987 used to indicate that the request is specifically limited to a small 988 set of desired types, as in the case of a request for an in-line 989 image. 985 The "Accept" request-header field can be used by user agents to specify 986 response media types that are acceptable. Accept headers can be used to 987 indicate that the request is specifically limited to a small set of desired 988 types, as in the case of a request for an in-line image. 990 989 </t> 991 990 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept"/><iref primary="true" item="Grammar" subitem="Accept-v"/><iref primary="true" item="Grammar" subitem="media-range"/><iref primary="true" item="Grammar" subitem="accept-params"/><iref primary="true" item="Grammar" subitem="accept-ext"/> … … 1110 1109 <x:anchor-alias value="Accept-Charset-v"/> 1111 1110 <t> 1112 The "Accept-Charset" request-header field can be used to indicate what1113 character sets are acceptable for the response. This field allows1111 The "Accept-Charset" request-header field can be used by user agents to 1112 indicate what response character sets are acceptable. This field allows 1114 1113 clients capable of understanding more comprehensive or special-purpose 1115 character sets to signal that capability to a server which is 1116 capable ofrepresenting documents in those character sets.1114 character sets to signal that capability to a server which is capable of 1115 representing documents in those character sets. 1117 1116 </t> 1118 1117 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Charset"/><iref primary="true" item="Grammar" subitem="Accept-Charset-v"/> … … 1155 1154 <x:anchor-alias value="codings"/> 1156 1155 <t> 1157 The "Accept-Encoding" request-header field is similar to Accept, but1158 restricts the content-codings (<xref target="content.codings"/>) that are acceptable in1159 the response.1156 The "Accept-Encoding" request-header field can be used by user agents to 1157 indicate what response content-codings (<xref target="content.codings"/>) 1158 are acceptable in the response. 1160 1159 </t> 1161 1160 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Encoding"/><iref primary="true" item="Grammar" subitem="Accept-Encoding-v"/><iref primary="true" item="Grammar" subitem="codings"/> … … 1245 1244 <x:anchor-alias value="language-range"/> 1246 1245 <t> 1247 The "Accept-Language" request-header field is similar to Accept, but1248 restricts the set of natural languages that are preferred as a1249 response to the request.Language tags are defined in <xref target="language.tags"/>.1246 The "Accept-Language" request-header field can be used by user agents to 1247 indicate the set of natural languages that are preferred in the response. 1248 Language tags are defined in <xref target="language.tags"/>. 1250 1249 </t> 1251 1250 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Language"/><iref primary="true" item="Grammar" subitem="Accept-Language-v"/><iref primary="true" item="Grammar" subitem="language-range"/> … … 1341 1340 <x:anchor-alias value="Content-Encoding-v"/> 1342 1341 <t> 1343 The "Content-Encoding" entity-header field is used as a modifier to the 1344 media-type. When present, its value indicates what additional content 1345 codings have been applied to the entity-body, and thus what decoding 1346 mechanisms must be applied in order to obtain the media-type 1347 referenced by the Content-Type header field. Content-Encoding is 1348 primarily used to allow a document to be compressed without losing 1349 the identity of its underlying media type. 1342 The "Content-Encoding" entity-header field indicates what content-codings 1343 have been applied to the entity-body, and thus what decoding mechanisms 1344 must be applied in order to obtain the media-type referenced by the 1345 Content-Type header field. Content-Encoding is primarily used to allow a 1346 document to be compressed without losing the identity of its underlying 1347 media type. 1350 1348 </t> 1351 1349 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Encoding"/><iref primary="true" item="Grammar" subitem="Content-Encoding-v"/> … … 1392 1390 <t> 1393 1391 The "Content-Language" entity-header field describes the natural 1394 language(s) of the intended audience for the enclosed entity. Note 1395 that this might not be equivalent to all the languages used within 1396 the entity-body. 1392 language(s) of the intended audience for the entity. Note that this might 1393 not be equivalent to all the languages used within the entity-body. 1397 1394 </t> 1398 1395 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Language"/><iref primary="true" item="Grammar" subitem="Content-Language-v"/> … … 1445 1442 <x:anchor-alias value="Content-Location-v"/> 1446 1443 <t> 1447 The "Content-Location" entity-header field &MAY; be used to supply the 1448 resource location for the entity enclosed in the message when that 1449 entity is accessible from a location separate from the requested 1450 resource's URI. A server &SHOULD; provide a Content-Location for the 1451 variant corresponding to the response entity; especially in the case 1452 where a resource has multiple entities associated with it, and those 1453 entities actually have separate locations by which they might be 1454 individually accessed, the server &SHOULD; provide a Content-Location 1455 for the particular variant which is returned. 1444 The "Content-Location" entity-header field is used to supply a URI for the 1445 entity in the message when it is accessible from a location separate from 1446 the requested resource's URI. 1447 </t> 1448 <t> 1449 A server &SHOULD; provide a Content-Location for the variant corresponding 1450 to the response entity, especially in the case where a resource has multiple 1451 entities associated with it, and those entities actually have separate 1452 locations by which they might be individually accessed, the server &SHOULD; 1453 provide a Content-Location for the particular variant which is returned. 1456 1454 </t> 1457 1455 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Location"/><iref primary="true" item="Grammar" subitem="Content-Location-v"/> … … 1574 1572 <t> 1575 1573 The "Content-Type" entity-header field indicates the media type of the 1576 entity-body sent to the recipient or, in the case of the HEAD method,1577 th e media type thatwould have been sent had the request been a GET.1574 entity-body. In the case of responses to the HEAD method, the media type is 1575 that which would have been sent had the request been a GET. 1578 1576 </t> 1579 1577 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Type"/><iref primary="true" item="Grammar" subitem="Content-Type-v"/> -
draft-ietf-httpbis/latest/p4-conditional.html
r697 r698 396 396 <meta name="DC.Creator" content="Reschke, J. F."> 397 397 <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest"> 398 <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-2 5">398 <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-26"> 399 399 <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2616"> 400 400 <meta name="DC.Description.Abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests."> … … 428 428 </tr> 429 429 <tr> 430 <td class="header left">Expires: March 29, 2010</td>430 <td class="header left">Expires: March 30, 2010</td> 431 431 <td class="header right">HP</td> 432 432 </tr> … … 481 481 <tr> 482 482 <td class="header left"></td> 483 <td class="header right">September 2 5, 2009</td>483 <td class="header right">September 26, 2009</td> 484 484 </tr> 485 485 </table> … … 505 505 <p>The list of Internet-Draft Shadow Directories can be accessed at <<a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>>. 506 506 </p> 507 <p>This Internet-Draft will expire in March 29, 2010.</p>507 <p>This Internet-Draft will expire in March 30, 2010.</p> 508 508 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 509 509 <p>Copyright © 2009 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 858 858 <div id="rfc.iref.h.1"></div> 859 859 <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="header.etag" href="#header.etag">ETag</a></h2> 860 <p id="rfc.section.6.1.p.1">The "ETag" response-header field provides the current value of the entity tag (see <a href="#entity.tags" title="Entity Tags">Section 2</a>) for the requested variant . The headers used with entity tags are described in Sections <a href="#header.if-match" id="rfc.xref.header.if-match.2" title="If-Match">6.2</a> and <a href="#header.if-none-match" id="rfc.xref.header.if-none-match.2" title="If-None-Match">6.4</a> of this document, and in <a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5.4"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. The entity tag <em class="bcp14">MAY</em>be used for comparison with other entities from the same resource (see <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a>).860 <p id="rfc.section.6.1.p.1">The "ETag" response-header field provides the current value of the entity tag (see <a href="#entity.tags" title="Entity Tags">Section 2</a>) for the requested variant, which may be used for comparison with other entities from the same resource (see <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a>). 861 861 </p> 862 862 <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span> <a href="#header.etag" class="smpl">ETag</a> = "ETag" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.etag" class="smpl">ETag-v</a> … … 879 879 <div id="rfc.iref.h.2"></div> 880 880 <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a> <a id="header.if-match" href="#header.if-match">If-Match</a></h2> 881 <p id="rfc.section.6.2.p.1">The "If-Match" request-header field is used with a method to make itconditional. A client that has one or more entities previously881 <p id="rfc.section.6.2.p.1">The "If-Match" request-header field is used to make a request method conditional. A client that has one or more entities previously 882 882 obtained from the resource can verify that one of those entities is current by including a list of their associated entity 883 tags in the If-Match header field. Entity tags are defined in <a href="#entity.tags" title="Entity Tags">Section 2</a>. The purpose of this feature is to allow efficient updates of cached information with a minimum amount of transaction overhead. 884 It is also used, on updating requests, to prevent inadvertent modification of the wrong version of a resource. As a special 885 case, the value "*" matches any current entity of the resource. 883 tags in the If-Match header field. 884 </p> 885 <p id="rfc.section.6.2.p.2">This allows efficient updates of cached information with a minimum amount of transaction overhead. It is also used when updating 886 resources, to prevent inadvertent modification of the wrong version of a resource. As a special case, the value "*" matches 887 any current entity of the resource. 886 888 </p> 887 889 <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.6"></span><span id="rfc.iref.g.7"></span> <a href="#header.if-match" class="smpl">If-Match</a> = "If-Match" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.if-match" class="smpl">If-Match-v</a> 888 890 <a href="#header.if-match" class="smpl">If-Match-v</a> = "*" / 1#<a href="#entity.tags" class="smpl">entity-tag</a> 889 </pre><p id="rfc.section.6.2.p. 3">If any of the entity tags match the entity tag of the entity that would have been returned in the response to a similar GET891 </pre><p id="rfc.section.6.2.p.4">If any of the entity tags match the entity tag of the entity that would have been returned in the response to a similar GET 890 892 request (without the If-Match header) on that resource, or if "*" is given and any current entity exists for that resource, 891 893 then the server <em class="bcp14">MAY</em> perform the requested method as if the If-Match header field did not exist. 892 894 </p> 893 <p id="rfc.section.6.2.p. 4">If none of the entity tags match, or if "*" is given and no current entity exists, the server <em class="bcp14">MUST NOT</em> perform the requested method, and <em class="bcp14">MUST</em> return a 412 (Precondition Failed) response. This behavior is most useful when the client wants to prevent an updating method,895 <p id="rfc.section.6.2.p.5">If none of the entity tags match, or if "*" is given and no current entity exists, the server <em class="bcp14">MUST NOT</em> perform the requested method, and <em class="bcp14">MUST</em> return a 412 (Precondition Failed) response. This behavior is most useful when the client wants to prevent an updating method, 894 896 such as PUT, from modifying a resource that has changed since the client last retrieved it. 895 897 </p> 896 <p id="rfc.section.6.2.p. 5">If the request would, without the If-Match header field, result in anything other than a 2xx or 412 status, then the If-Match898 <p id="rfc.section.6.2.p.6">If the request would, without the If-Match header field, result in anything other than a 2xx or 412 status, then the If-Match 897 899 header <em class="bcp14">MUST</em> be ignored. 898 900 </p> 899 <p id="rfc.section.6.2.p. 6">The meaning of "If-Match: *" is that the method <em class="bcp14">SHOULD</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">MUST NOT</em> be performed if the representation does not exist.900 </p> 901 <p id="rfc.section.6.2.p. 7">A request intended to update a resource (e.g., a PUT) <em class="bcp14">MAY</em> include an If-Match header field to signal that the request method <em class="bcp14">MUST NOT</em> be applied if the entity corresponding to the If-Match value (a single entity tag) is no longer a representation of that resource.901 <p id="rfc.section.6.2.p.7">The meaning of "If-Match: *" is that the method <em class="bcp14">SHOULD</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">MUST NOT</em> be performed if the representation does not exist. 902 </p> 903 <p id="rfc.section.6.2.p.8">A request intended to update a resource (e.g., a PUT) <em class="bcp14">MAY</em> include an If-Match header field to signal that the request method <em class="bcp14">MUST NOT</em> be applied if the entity corresponding to the If-Match value (a single entity tag) is no longer a representation of that resource. 902 904 This allows the user to indicate that they do not wish the request to be successful if the resource has been changed without 903 905 their knowledge. Examples: … … 906 908 If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" 907 909 If-Match: * 908 </pre><p id="rfc.section.6.2.p. 9">The result of a request having both an If-Match header field and either an If-None-Match or an If-Modified-Since header fields910 </pre><p id="rfc.section.6.2.p.10">The result of a request having both an If-Match header field and either an If-None-Match or an If-Modified-Since header fields 909 911 is undefined by this specification. 910 912 </p> … … 912 914 <div id="rfc.iref.h.3"></div> 913 915 <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a> <a id="header.if-modified-since" href="#header.if-modified-since">If-Modified-Since</a></h2> 914 <p id="rfc.section.6.3.p.1">The "If-Modified-Since" request-header field is used with a method to make itconditional: if the requested variant has not915 been modified since the time specified in this field, an entity will not be returned from the server; instead, a 304 (Not916 Modified) response will be returned without any message-body.916 <p id="rfc.section.6.3.p.1">The "If-Modified-Since" request-header field is used to make a request method conditional: if the requested variant has not 917 been modified since the time specified in this field, the server will not return an entity; instead, a 304 (Not Modified) 918 response will be returned. 917 919 </p> 918 920 <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.8"></span><span id="rfc.iref.g.9"></span> <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> = "If-Modified-Since" ":" <a href="#core.rules" class="smpl">OWS</a> … … 935 937 <p id="rfc.section.6.3.p.6">The purpose of this feature is to allow efficient updates of cached information with a minimum amount of transaction overhead. </p> 936 938 <dl class="empty"> 937 <dd> <b>Note:</b> The Range request-header field modifies the meaning of If-Modified-Since; see <a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5. 5"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a> for full details.939 <dd> <b>Note:</b> The Range request-header field modifies the meaning of If-Modified-Since; see <a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.4"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a> for full details. 938 940 </dd> 939 941 <dd> <b>Note:</b> If-Modified-Since times are interpreted by the server, whose clock might not be synchronized with the client. … … 959 961 <div id="rfc.iref.h.4"></div> 960 962 <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a> <a id="header.if-none-match" href="#header.if-none-match">If-None-Match</a></h2> 961 <p id="rfc.section.6.4.p.1">The "If-None-Match" request-header field is used with a method to make itconditional. A client that has one or more entities963 <p id="rfc.section.6.4.p.1">The "If-None-Match" request-header field is used to make a request method conditional. A client that has one or more entities 962 964 previously obtained from the resource can verify that none of those entities is current by including a list of their associated 963 entity tags in the If-None-Match header field. The purpose of this feature is to allow efficient updates of cached information 964 with a minimum amount of transaction overhead. It is also used to prevent a method (e.g. PUT) from inadvertently modifying 965 an existing resource when the client believes that the resource does not exist. 966 </p> 967 <p id="rfc.section.6.4.p.2">As a special case, the value "*" matches any current entity of the resource.</p> 965 entity tags in the If-None-Match header field. 966 </p> 967 <p id="rfc.section.6.4.p.2">This allows efficient updates of cached information with a minimum amount of transaction overhead. It is also used to prevent 968 a method (e.g. PUT) from inadvertently modifying an existing resource when the client believes that the resource does not 969 exist. 970 </p> 971 <p id="rfc.section.6.4.p.3">As a special case, the value "*" matches any current entity of the resource.</p> 968 972 <div id="rfc.figure.u.10"></div><pre class="inline"><span id="rfc.iref.g.10"></span><span id="rfc.iref.g.11"></span> <a href="#header.if-none-match" class="smpl">If-None-Match</a> = "If-None-Match" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.if-none-match" class="smpl">If-None-Match-v</a> 969 973 <a href="#header.if-none-match" class="smpl">If-None-Match-v</a> = "*" / 1#<a href="#entity.tags" class="smpl">entity-tag</a> 970 </pre><p id="rfc.section.6.4.p. 4">If any of the entity tags match the entity tag of the entity that would have been returned in the response to a similar GET974 </pre><p id="rfc.section.6.4.p.5">If any of the entity tags match the entity tag of the entity that would have been returned in the response to a similar GET 971 975 request (without the If-None-Match header) on that resource, or if "*" is given and any current entity exists for that resource, 972 976 then the server <em class="bcp14">MUST NOT</em> perform the requested method, unless required to do so because the resource's modification date fails to match that supplied … … 974 978 that matched. For all other request methods, the server <em class="bcp14">MUST</em> respond with a status of 412 (Precondition Failed). 975 979 </p> 976 <p id="rfc.section.6.4.p. 5">If none of the entity tags match, then the server <em class="bcp14">MAY</em> perform the requested method as if the If-None-Match header field did not exist, but <em class="bcp14">MUST</em> also ignore any If-Modified-Since header field(s) in the request. That is, if no entity tags match, then the server <em class="bcp14">MUST NOT</em> return a 304 (Not Modified) response.977 </p> 978 <p id="rfc.section.6.4.p. 6">If the request would, without the If-None-Match header field, result in anything other than a 2xx or 304 status, then the980 <p id="rfc.section.6.4.p.6">If none of the entity tags match, then the server <em class="bcp14">MAY</em> perform the requested method as if the If-None-Match header field did not exist, but <em class="bcp14">MUST</em> also ignore any If-Modified-Since header field(s) in the request. That is, if no entity tags match, then the server <em class="bcp14">MUST NOT</em> return a 304 (Not Modified) response. 981 </p> 982 <p id="rfc.section.6.4.p.7">If the request would, without the If-None-Match header field, result in anything other than a 2xx or 304 status, then the 979 983 If-None-Match header <em class="bcp14">MUST</em> be ignored. (See <a href="#rules.for.when.to.use.entity.tags.and.last-modified.dates" title="Rules for When to Use Entity Tags and Last-Modified Dates">Section 5</a> for a discussion of server behavior when both If-Modified-Since and If-None-Match appear in the same request.) 980 984 </p> 981 <p id="rfc.section.6.4.p. 7">The meaning of "If-None-Match: *" is that the method <em class="bcp14">MUST NOT</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">SHOULD</em> be performed if the representation does not exist. This feature is intended to be useful in preventing races between PUT operations.982 </p> 983 <p id="rfc.section.6.4.p. 8">Examples:</p>985 <p id="rfc.section.6.4.p.8">The meaning of "If-None-Match: *" is that the method <em class="bcp14">MUST NOT</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">SHOULD</em> be performed if the representation does not exist. This feature is intended to be useful in preventing races between PUT operations. 986 </p> 987 <p id="rfc.section.6.4.p.9">Examples:</p> 984 988 <div id="rfc.figure.u.11"></div><pre class="text"> If-None-Match: "xyzzy" 985 989 If-None-Match: W/"xyzzy" … … 987 991 If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz" 988 992 If-None-Match: * 989 </pre><p id="rfc.section.6.4.p.1 0">The result of a request having both an If-None-Match header field and either an If-Match or an If-Unmodified-Since header993 </pre><p id="rfc.section.6.4.p.11">The result of a request having both an If-None-Match header field and either an If-Match or an If-Unmodified-Since header 990 994 fields is undefined by this specification. 991 995 </p> … … 993 997 <div id="rfc.iref.h.5"></div> 994 998 <h2 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a> <a id="header.if-unmodified-since" href="#header.if-unmodified-since">If-Unmodified-Since</a></h2> 995 <p id="rfc.section.6.5.p.1">The "If-Unmodified-Since" request-header field is used with a method to make itconditional. If the requested resource has999 <p id="rfc.section.6.5.p.1">The "If-Unmodified-Since" request-header field is used to make a request method conditional. If the requested resource has 996 1000 not been modified since the time specified in this field, the server <em class="bcp14">SHOULD</em> perform the requested operation as if the If-Unmodified-Since header were not present. 997 1001 </p> … … 1064 1068 <td>http</td> 1065 1069 <td>standard</td> 1066 <td> <a href="#header.if-match" id="rfc.xref.header.if-match. 3" title="If-Match">Section 6.2</a>1070 <td> <a href="#header.if-match" id="rfc.xref.header.if-match.2" title="If-Match">Section 6.2</a> 1067 1071 </td> 1068 1072 </tr> … … 1078 1082 <td>http</td> 1079 1083 <td>standard</td> 1080 <td> <a href="#header.if-none-match" id="rfc.xref.header.if-none-match. 3" title="If-None-Match">Section 6.4</a>1084 <td> <a href="#header.if-none-match" id="rfc.xref.header.if-none-match.2" title="If-None-Match">Section 6.4</a> 1081 1085 </td> 1082 1086 </tr> … … 1168 1172 <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a> <a id="compatibility" href="#compatibility">Compatibility with Previous Versions</a></h1> 1169 1173 <h2 id="rfc.section.A.1"><a href="#rfc.section.A.1">A.1</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2> 1170 <p id="rfc.section.A.1.p.1">Allow weak entity tags in all requests except range requests (Sections <a href="#weak.and.strong.validators" title="Weak and Strong Validators">4</a> and <a href="#header.if-none-match" id="rfc.xref.header.if-none-match. 4" title="If-None-Match">6.4</a>).1174 <p id="rfc.section.A.1.p.1">Allow weak entity tags in all requests except range requests (Sections <a href="#weak.and.strong.validators" title="Weak and Strong Validators">4</a> and <a href="#header.if-none-match" id="rfc.xref.header.if-none-match.3" title="If-None-Match">6.4</a>). 1171 1175 </p> 1172 1176 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> … … 1320 1324 <ul class="ind"> 1321 1325 <li class="indline1">ETag <a class="iref" href="#rfc.xref.header.etag.1">2</a>, <a class="iref" href="#rfc.iref.h.1"><b>6.1</b></a>, <a class="iref" href="#rfc.xref.header.etag.2">7.1</a></li> 1322 <li class="indline1">If-Match <a class="iref" href="#rfc.xref.header.if-match.1">2</a>, <a class="iref" href="#rfc. xref.header.if-match.2">6.1</a>, <a class="iref" href="#rfc.iref.h.2"><b>6.2</b></a>, <a class="iref" href="#rfc.xref.header.if-match.3">7.1</a></li>1326 <li class="indline1">If-Match <a class="iref" href="#rfc.xref.header.if-match.1">2</a>, <a class="iref" href="#rfc.iref.h.2"><b>6.2</b></a>, <a class="iref" href="#rfc.xref.header.if-match.2">7.1</a></li> 1323 1327 <li class="indline1">If-Modified-Since <a class="iref" href="#rfc.iref.h.3"><b>6.3</b></a>, <a class="iref" href="#rfc.xref.header.if-modified-since.1">7.1</a></li> 1324 <li class="indline1">If-None-Match <a class="iref" href="#rfc.xref.header.if-none-match.1">2</a>, <a class="iref" href="#rfc. xref.header.if-none-match.2">6.1</a>, <a class="iref" href="#rfc.iref.h.4"><b>6.4</b></a>, <a class="iref" href="#rfc.xref.header.if-none-match.3">7.1</a>, <a class="iref" href="#rfc.xref.header.if-none-match.4">A.1</a></li>1328 <li class="indline1">If-None-Match <a class="iref" href="#rfc.xref.header.if-none-match.1">2</a>, <a class="iref" href="#rfc.iref.h.4"><b>6.4</b></a>, <a class="iref" href="#rfc.xref.header.if-none-match.2">7.1</a>, <a class="iref" href="#rfc.xref.header.if-none-match.3">A.1</a></li> 1325 1329 <li class="indline1">If-Unmodified-Since <a class="iref" href="#rfc.iref.h.5"><b>6.5</b></a>, <a class="iref" href="#rfc.xref.header.if-unmodified-since.1">7.1</a></li> 1326 1330 <li class="indline1">Last-Modified <a class="iref" href="#rfc.iref.h.6"><b>6.6</b></a>, <a class="iref" href="#rfc.xref.header.last-modified.1">7.1</a></li> … … 1330 1334 </li> 1331 1335 <li class="indline0"><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul class="ind"> 1332 <li class="indline1">If-Match header <a class="iref" href="#rfc.xref.header.if-match.1">2</a>, <a class="iref" href="#rfc. xref.header.if-match.2">6.1</a>, <a class="iref" href="#rfc.iref.i.1"><b>6.2</b></a>, <a class="iref" href="#rfc.xref.header.if-match.3">7.1</a></li>1336 <li class="indline1">If-Match header <a class="iref" href="#rfc.xref.header.if-match.1">2</a>, <a class="iref" href="#rfc.iref.i.1"><b>6.2</b></a>, <a class="iref" href="#rfc.xref.header.if-match.2">7.1</a></li> 1333 1337 <li class="indline1">If-Modified-Since header <a class="iref" href="#rfc.iref.i.2"><b>6.3</b></a>, <a class="iref" href="#rfc.xref.header.if-modified-since.1">7.1</a></li> 1334 <li class="indline1">If-None-Match header <a class="iref" href="#rfc.xref.header.if-none-match.1">2</a>, <a class="iref" href="#rfc. xref.header.if-none-match.2">6.1</a>, <a class="iref" href="#rfc.iref.i.3"><b>6.4</b></a>, <a class="iref" href="#rfc.xref.header.if-none-match.3">7.1</a>, <a class="iref" href="#rfc.xref.header.if-none-match.4">A.1</a></li>1338 <li class="indline1">If-None-Match header <a class="iref" href="#rfc.xref.header.if-none-match.1">2</a>, <a class="iref" href="#rfc.iref.i.3"><b>6.4</b></a>, <a class="iref" href="#rfc.xref.header.if-none-match.2">7.1</a>, <a class="iref" href="#rfc.xref.header.if-none-match.3">A.1</a></li> 1335 1339 <li class="indline1">If-Unmodified-Since header <a class="iref" href="#rfc.iref.i.4"><b>6.5</b></a>, <a class="iref" href="#rfc.xref.header.if-unmodified-since.1">7.1</a></li> 1336 1340 </ul> … … 1349 1353 </ul> 1350 1354 </li> 1351 <li class="indline1"><em>Part5</em> <a class="iref" href="#rfc.xref.Part5.1">2</a>, <a class="iref" href="#rfc.xref.Part5.2">4</a>, <a class="iref" href="#rfc.xref.Part5.3">4</a>, <a class="iref" href="#rfc.xref.Part5.4">6. 1</a>, <a class="iref" href="#rfc.xref.Part5.5">6.3</a>, <a class="iref" href="#Part5"><b>10.1</b></a><ul class="ind">1352 <li class="indline1"><em>Section 5.3</em> <a class="iref" href="#rfc.xref.Part5.1">2</a> , <a class="iref" href="#rfc.xref.Part5.4">6.1</a></li>1353 <li class="indline1"><em>Section 5.4</em> <a class="iref" href="#rfc.xref.Part5. 5">6.3</a></li>1355 <li class="indline1"><em>Part5</em> <a class="iref" href="#rfc.xref.Part5.1">2</a>, <a class="iref" href="#rfc.xref.Part5.2">4</a>, <a class="iref" href="#rfc.xref.Part5.3">4</a>, <a class="iref" href="#rfc.xref.Part5.4">6.3</a>, <a class="iref" href="#Part5"><b>10.1</b></a><ul class="ind"> 1356 <li class="indline1"><em>Section 5.3</em> <a class="iref" href="#rfc.xref.Part5.1">2</a></li> 1357 <li class="indline1"><em>Section 5.4</em> <a class="iref" href="#rfc.xref.Part5.4">6.3</a></li> 1354 1358 </ul> 1355 1359 </li> -
draft-ietf-httpbis/latest/p4-conditional.xml
r697 r698 689 689 <t> 690 690 The "ETag" response-header field provides the current value of the 691 entity tag (see <xref target="entity.tags"/>) for the requested variant. 692 The headers used with entity 693 tags are described in Sections <xref target="header.if-match" format="counter"/> 694 and <xref target="header.if-none-match" format="counter"/> of this document, 695 and in &header-if-range;. The entity tag 696 &MAY; be used for comparison with other entities from the same resource 691 entity tag (see <xref target="entity.tags"/>) for the requested variant, 692 which may be used for comparison with other entities from the same resource 697 693 (see <xref target="weak.and.strong.validators"/>). 698 694 </t> … … 734 730 <x:anchor-alias value="If-Match-v"/> 735 731 <t> 736 The "If-Match" request-header field is used with a method to make it732 The "If-Match" request-header field is used to make a request method 737 733 conditional. A client that has one or more entities previously 738 734 obtained from the resource can verify that one of those entities is 739 735 current by including a list of their associated entity tags in the 740 If-Match header field. Entity tags are defined in <xref target="entity.tags"/>. The 741 purpose of this feature is to allow efficient updates of cached 742 information with a minimum amount of transaction overhead. It is also 743 used, on updating requests, to prevent inadvertent modification of 744 the wrong version of a resource. As a special case, the value "*" 745 matches any current entity of the resource. 736 If-Match header field. 737 </t> 738 <t> 739 This allows efficient updates of cached information with a minimum amount of 740 transaction overhead. It is also used when updating resources, to prevent 741 inadvertent modification of the wrong version of a resource. As a special 742 case, the value "*" matches any current entity of the resource. 746 743 </t> 747 744 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Match"/><iref primary="true" item="Grammar" subitem="If-Match-v"/> … … 803 800 <x:anchor-alias value="If-Modified-Since-v"/> 804 801 <t> 805 The "If-Modified-Since" request-header field is used with a method to 806 make it conditional: if the requested variant has not been modified 807 since the time specified in this field, an entity will not be 808 returned from the server; instead, a 304 (Not Modified) response will 809 be returned without any message-body. 802 The "If-Modified-Since" request-header field is used to make a request 803 method conditional: if the requested variant has not been modified since the 804 time specified in this field, the server will not return an entity; instead, 805 a 304 (Not Modified) response will be returned. 810 806 </t> 811 807 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="If-Modified-Since"/><iref primary="true" item="Grammar" subitem="If-Modified-Since-v"/> … … 888 884 <x:anchor-alias value="If-None-Match-v"/> 889 885 <t> 890 The "If-None-Match" request-header field is used with a method to make891 itconditional. A client that has one or more entities previously886 The "If-None-Match" request-header field is used to make a request method 887 conditional. A client that has one or more entities previously 892 888 obtained from the resource can verify that none of those entities is 893 889 current by including a list of their associated entity tags in the 894 If-None-Match header field. The purpose of this feature is to allow 895 efficient updates of cached information with a minimum amount of 890 If-None-Match header field. 891 </t> 892 <t> 893 This allows efficient updates of cached information with a minimum amount of 896 894 transaction overhead. It is also used to prevent a method (e.g. PUT) 897 895 from inadvertently modifying an existing resource when the client … … 965 963 <x:anchor-alias value="If-Unmodified-Since-v"/> 966 964 <t> 967 The "If-Unmodified-Since" request-header field is used with a method to968 m ake itconditional. If the requested resource has not been modified965 The "If-Unmodified-Since" request-header field is used to make a request 966 method conditional. If the requested resource has not been modified 969 967 since the time specified in this field, the server &SHOULD; perform the 970 968 requested operation as if the If-Unmodified-Since header were not -
draft-ietf-httpbis/latest/p5-range.html
r697 r698 396 396 <meta name="DC.Creator" content="Reschke, J. F."> 397 397 <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest"> 398 <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-2 5">398 <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-26"> 399 399 <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2616"> 400 400 <meta name="DC.Description.Abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 5 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests."> … … 428 428 </tr> 429 429 <tr> 430 <td class="header left">Expires: March 29, 2010</td>430 <td class="header left">Expires: March 30, 2010</td> 431 431 <td class="header right">HP</td> 432 432 </tr> … … 481 481 <tr> 482 482 <td class="header left"></td> 483 <td class="header right">September 2 5, 2009</td>483 <td class="header right">September 26, 2009</td> 484 484 </tr> 485 485 </table> … … 505 505 <p>The list of Internet-Draft Shadow Directories can be accessed at <<a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>>. 506 506 </p> 507 <p>This Internet-Draft will expire in March 29, 2010.</p>507 <p>This Internet-Draft will expire in March 30, 2010.</p> 508 508 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 509 509 <p>Copyright © 2009 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 694 694 <div id="rfc.iref.h.1"></div> 695 695 <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a> <a id="header.accept-ranges" href="#header.accept-ranges">Accept-Ranges</a></h2> 696 <p id="rfc.section.5.1.p.1">The "Accept-Ranges" response-header field allows the server to indicate its acceptance of range requests for a resource:</p>696 <p id="rfc.section.5.1.p.1">The "Accept-Ranges" response-header field allows a resource to indicate its acceptance of range requests.</p> 697 697 <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span> <a href="#header.accept-ranges" class="smpl">Accept-Ranges</a> = "Accept-Ranges" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.accept-ranges" class="smpl">Accept-Ranges-v</a> 698 698 <a href="#header.accept-ranges" class="smpl">Accept-Ranges-v</a> = <a href="#header.accept-ranges" class="smpl">acceptable-ranges</a> … … 864 864 </ul> 865 865 <h3 id="rfc.section.5.4.2"><a href="#rfc.section.5.4.2">5.4.2</a> <a id="range.retrieval.requests" href="#range.retrieval.requests">Range Retrieval Requests</a></h3> 866 <p id="rfc.section.5.4.2.p.1"> HTTP retrieval requests using conditional or unconditional GET methods <em class="bcp14">MAY</em> request one or more sub-ranges of the entity, instead of the entire entity, using the Range request header, which applies867 to the entity returned as the result of the request:866 <p id="rfc.section.5.4.2.p.1">The "Range" request-header field defines the GET method (conditional or not) to request one or more sub-ranges of the response 867 entity-body, instead of the entire entity body. 868 868 </p> 869 869 <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.23"></span> <a href="#range.retrieval.requests" class="smpl">Range</a> = "Range" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#range.retrieval.requests" class="smpl">Range-v</a> -
draft-ietf-httpbis/latest/p5-range.xml
r697 r698 458 458 <x:anchor-alias value="acceptable-ranges"/> 459 459 <t> 460 The "Accept-Ranges" response-header field allows the server to461 i ndicate its acceptance of range requests for a resource:460 The "Accept-Ranges" response-header field allows a resource to indicate 461 its acceptance of range requests. 462 462 </t> 463 463 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Ranges"/><iref primary="true" item="Grammar" subitem="Accept-Ranges-v"/><iref primary="true" item="Grammar" subitem="acceptable-ranges"/> … … 807 807 <x:anchor-alias value="other-range-set"/> 808 808 <t> 809 HTTP retrieval requests using conditional or unconditional GET 810 methods &MAY; request one or more sub-ranges of the entity, instead of 811 the entire entity, using the Range request header, which applies to 812 the entity returned as the result of the request: 809 The "Range" request-header field defines the GET method (conditional or 810 not) to request one or more sub-ranges of the response entity-body, instead 811 of the entire entity body. 813 812 </t> 814 813 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Range"/> -
draft-ietf-httpbis/latest/p6-cache.html
r697 r698 398 398 <meta name="DC.Creator" content="Reschke, J. F."> 399 399 <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest"> 400 <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-2 5">400 <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-26"> 401 401 <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2616"> 402 402 <meta name="DC.Description.Abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document is Part 6 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages."> … … 430 430 </tr> 431 431 <tr> 432 <td class="header left">Expires: March 29, 2010</td>432 <td class="header left">Expires: March 30, 2010</td> 433 433 <td class="header right">HP</td> 434 434 </tr> … … 487 487 <tr> 488 488 <td class="header left"></td> 489 <td class="header right">September 2 5, 2009</td>489 <td class="header right">September 26, 2009</td> 490 490 </tr> 491 491 </table> … … 511 511 <p>The list of Internet-Draft Shadow Directories can be accessed at <<a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>>. 512 512 </p> 513 <p>This Internet-Draft will expire in March 29, 2010.</p>513 <p>This Internet-Draft will expire in March 30, 2010.</p> 514 514 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 515 515 <p>Copyright © 2009 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 974 974 <div id="rfc.iref.h.2"></div> 975 975 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="header.age" href="#header.age">Age</a></h2> 976 <p id="rfc.section.3.1.p.1">The "Age" response-header field conveys the sender's estimate of the amount of time since the response (or its validation)977 was generated at the origin server. Age values are calculated as specified in <a href="#age.calculations" title="Calculating Age">Section 2.3.2</a>.976 <p id="rfc.section.3.1.p.1">The "Age" response-header field conveys the sender's estimate of the amount of time since the response was generated or successfully 977 validated at the origin server. Age values are calculated as specified in <a href="#age.calculations" title="Calculating Age">Section 2.3.2</a>. 978 978 </p> 979 979 <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span> <a href="#header.age" class="smpl">Age</a> = "Age" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.age" class="smpl">Age-v</a> … … 992 992 <div id="rfc.iref.h.3"></div> 993 993 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="header.cache-control" href="#header.cache-control">Cache-Control</a></h2> 994 <p id="rfc.section.3.2.p.1">The "Cache-Control" general-header field is used to specify directives that <em class="bcp14">MUST</em> be obeyed by all caches along the request/response chain. The directives specify behavior intended to prevent caches from 995 adversely interfering with the request or response. Cache directives are unidirectional in that the presence of a directive 996 in a request does not imply that the same directive is to be given in the response. 994 <p id="rfc.section.3.2.p.1">The "Cache-Control" general-header field is used to specify directives that <em class="bcp14">MUST</em> be obeyed by all caches along the request/response chain. Such cache directives are unidirectional in that the presence of 995 a directive in a request does not imply that the same directive is to be given in the response. 997 996 </p> 998 997 <div class="note"> … … 1237 1236 <div id="rfc.iref.h.6"></div> 1238 1237 <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a> <a id="header.vary" href="#header.vary">Vary</a></h2> 1239 <p id="rfc.section.3.5.p.1">The "Vary" response-header field's value indicates the set of request-header fields that determines, while the response is 1240 fresh, whether a cache is permitted to use the response to reply to a subsequent request without validation; see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.6</a>. 1241 </p> 1242 <p id="rfc.section.3.5.p.2">In uncacheable or stale responses, the Vary field value advises the user agent about the criteria that were used to select 1238 <p id="rfc.section.3.5.p.1">The "Vary" response-header field conveys the set of request-header fields that were used to select the representation.</p> 1239 <p id="rfc.section.3.5.p.2">Caches use this information, in part, to determine whether a stored response can be used to satisdy a given request; see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.6</a>. determines, while the response is fresh, whether a cache is permitted to use the response to reply to a subsequent request 1240 without validation; see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.6</a>. 1241 </p> 1242 <p id="rfc.section.3.5.p.3">In uncacheable or stale responses, the Vary field value advises the user agent about the criteria that were used to select 1243 1243 the representation. 1244 1244 </p> 1245 1245 <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.15"></span><span id="rfc.iref.g.16"></span> <a href="#header.vary" class="smpl">Vary</a> = "Vary" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.vary" class="smpl">Vary-v</a> 1246 1246 <a href="#header.vary" class="smpl">Vary-v</a> = "*" / 1#<a href="#abnf.dependencies" class="smpl">field-name</a> 1247 </pre><p id="rfc.section.3.5.p. 4">The set of header fields named by the Vary field value is known as the selecting request-headers.</p>1248 <p id="rfc.section.3.5.p. 5">Servers <em class="bcp14">SHOULD</em> include a Vary header field with any cacheable response that is subject to server-driven negotiation. Doing so allows a cache1247 </pre><p id="rfc.section.3.5.p.5">The set of header fields named by the Vary field value is known as the selecting request-headers.</p> 1248 <p id="rfc.section.3.5.p.6">Servers <em class="bcp14">SHOULD</em> include a Vary header field with any cacheable response that is subject to server-driven negotiation. Doing so allows a cache 1249 1249 to properly interpret future requests on that resource and informs the user agent about the presence of negotiation on that 1250 1250 resource. A server <em class="bcp14">MAY</em> include a Vary header field with a non-cacheable response that is subject to server-driven negotiation, since this might provide 1251 1251 the user agent with useful information about the dimensions over which the response varies at the time of the response. 1252 1252 </p> 1253 <p id="rfc.section.3.5.p. 6">A Vary field value of "*" signals that unspecified parameters not limited to the request-headers (e.g., the network address1253 <p id="rfc.section.3.5.p.7">A Vary field value of "*" signals that unspecified parameters not limited to the request-headers (e.g., the network address 1254 1254 of the client), play a role in the selection of the response representation; therefore, a cache cannot determine whether this 1255 1255 response is appropriate. The "*" value <em class="bcp14">MUST NOT</em> be generated by a proxy server; it may only be generated by an origin server. 1256 1256 </p> 1257 <p id="rfc.section.3.5.p. 7">The field-names given are not limited to the set of standard request-header fields defined by this specification. Field names1257 <p id="rfc.section.3.5.p.8">The field-names given are not limited to the set of standard request-header fields defined by this specification. Field names 1258 1258 are case-insensitive. 1259 1259 </p> -
draft-ietf-httpbis/latest/p6-cache.xml
r697 r698 895 895 <x:anchor-alias value="age-value"/> 896 896 <t> 897 The "Age" response-header field conveys the sender's estimate of the amount of time since 898 the response (or its validation) was generated at the origin server. Age values are 899 calculated as specified in <xref target="age.calculations" />. 897 The "Age" response-header field conveys the sender's estimate of the amount 898 of time since the response was generated or successfully validated at the 899 origin server. Age values are calculated as specified in 900 <xref target="age.calculations" />. 900 901 </t> 901 902 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Age"/><iref primary="true" item="Grammar" subitem="Age-v"/> … … 933 934 <x:anchor-alias value="cache-response-directive"/> 934 935 <t> 935 The "Cache-Control" general-header field is used to specify directives that &MUST; be936 obeyed by all caches along the request/response chain. The directives specify behavior937 intended to prevent caches from adversely interfering with the request or response. Cache938 directives are unidirectional in that the presence of a directive in a request does not939 imply that the same directive is to be given in theresponse.936 The "Cache-Control" general-header field is used to specify directives that 937 &MUST; be obeyed by all caches along the request/response chain. Such cache 938 directives are unidirectional in that the presence of a directive in a 939 request does not imply that the same directive is to be given in the 940 response. 940 941 </t> 941 942 <x:note> … … 1332 1333 <x:anchor-alias value="Vary-v"/> 1333 1334 <t> 1334 The "Vary" response-header field's value indicates the set of request-header fields that 1335 The "Vary" response-header field conveys the set of request-header fields 1336 that were used to select the representation. 1337 </t> 1338 <t> 1339 Caches use this information, in part, to determine whether a stored response 1340 can be used to satisdy a given request; see 1341 <xref target="caching.negotiated.responses" />. 1335 1342 determines, while the response is fresh, whether a cache is permitted to use the 1336 1343 response to reply to a subsequent request without validation; see <xref -
draft-ietf-httpbis/latest/p7-auth.html
r697 r698 390 390 <meta name="DC.Creator" content="Reschke, J. F."> 391 391 <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest"> 392 <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-2 5">392 <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-26"> 393 393 <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2616"> 394 394 <meta name="DC.Description.Abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 7 defines HTTP Authentication."> … … 427 427 </tr> 428 428 <tr> 429 <td class="header left">Expires: March 29, 2010</td>429 <td class="header left">Expires: March 30, 2010</td> 430 430 <td class="header right">H. Frystyk</td> 431 431 </tr> … … 476 476 <tr> 477 477 <td class="header left"></td> 478 <td class="header right">September 2 5, 2009</td>478 <td class="header right">September 26, 2009</td> 479 479 </tr> 480 480 </table> … … 500 500 <p>The list of Internet-Draft Shadow Directories can be accessed at <<a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>>. 501 501 </p> 502 <p>This Internet-Draft will expire in March 29, 2010.</p>502 <p>This Internet-Draft will expire in March 30, 2010.</p> 503 503 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 504 504 <p>Copyright © 2009 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 627 627 <div id="rfc.iref.h.1"></div> 628 628 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="header.authorization" href="#header.authorization">Authorization</a></h2> 629 <p id="rfc.section.3.1.p.1"> A user agent that wishes to authenticate itself with a server-- usually, but not necessarily, after receiving a 401 response--does630 so by including an "Authorization" request-header field with the request. The field value consists of credentials containing631 the authentication information of the user agentfor the realm of the resource being requested.629 <p id="rfc.section.3.1.p.1">The "Authorization" request-header field allows a user agent to authenticate itself with a server -- usually, but not necessary, 630 after receiving a 401 (Unauthorized) response. Its value consists of credentials containing information of the user agent 631 for the realm of the resource being requested. 632 632 </p> 633 633 <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.3"></span><span id="rfc.iref.g.4"></span> <a href="#header.authorization" class="smpl">Authorization</a> = "Authorization" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.authorization" class="smpl">Authorization-v</a> … … 652 652 <div id="rfc.iref.h.2"></div> 653 653 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="header.proxy-authenticate" href="#header.proxy-authenticate">Proxy-Authenticate</a></h2> 654 <p id="rfc.section.3.2.p.1">The "Proxy-Authenticate" response-header field <em class="bcp14">MUST</em> be included as part of a 407 (Proxy Authentication Required) response. The field value consists of a challenge that indicates655 the authentication scheme and parameters applicable to the proxy for this request-target.654 <p id="rfc.section.3.2.p.1">The "Proxy-Authenticate" response-header field consists of a challenge that indicates the authentication scheme and parameters 655 applicable to the proxy for this request-target. It <em class="bcp14">MUST</em> be included as part of a 407 (Proxy Authentication Required) response. 656 656 </p> 657 657 <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span> <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> = "Proxy-Authenticate" ":" <a href="#core.rules" class="smpl">OWS</a> … … 666 666 <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> <a id="header.proxy-authorization" href="#header.proxy-authorization">Proxy-Authorization</a></h2> 667 667 <p id="rfc.section.3.3.p.1">The "Proxy-Authorization" request-header field allows the client to identify itself (or its user) to a proxy which requires 668 authentication. The Proxy-Authorization field value consists of credentials containing the authentication information of the669 user agent for the proxyand/or realm of the resource being requested.668 authentication. Its value consists of credentials containing the authentication information of the user agent for the proxy 669 and/or realm of the resource being requested. 670 670 </p> 671 671 <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.g.7"></span><span id="rfc.iref.g.8"></span> <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a> = "Proxy-Authorization" ":" <a href="#core.rules" class="smpl">OWS</a> … … 680 680 <div id="rfc.iref.h.4"></div> 681 681 <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a> <a id="header.www-authenticate" href="#header.www-authenticate">WWW-Authenticate</a></h2> 682 <p id="rfc.section.3.4.p.1">The "WWW-Authenticate" response-header field <em class="bcp14">MUST</em> be included in 401 (Unauthorized) response messages. The field value consists of at least one challenge that indicates the683 a uthentication scheme(s) and parameters applicable to the request-target.682 <p id="rfc.section.3.4.p.1">The "WWW-Authenticate" response-header field consists of at least one challenge that indicates the authentication scheme(s) 683 and parameters applicable to the request-target. It <em class="bcp14">MUST</em> be included in 401 (Unauthorized) response messages. 684 684 </p> 685 685 <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span> <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> = "WWW-Authenticate" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.www-authenticate" class="smpl">WWW-Authenticate-v</a> -
draft-ietf-httpbis/latest/p7-auth.xml
r697 r698 342 342 <x:anchor-alias value="Authorization-v"/> 343 343 <t> 344 A user agent that wishes to authenticate itself with a server-- 345 usually, but not necessarily, after receiving a 401 response--does 346 so by including an "Authorization" request-header field with the 347 request. The field value consists of credentials 348 containing the authentication information of the user agent for 349 the realm of the resource being requested. 344 The "Authorization" request-header field allows a user agent to authenticate 345 itself with a server -- usually, but not necessary, after receiving a 401 346 (Unauthorized) response. Its value consists of credentials containing 347 information of the user agent for the realm of the resource being 348 requested. 350 349 </t> 351 350 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Authorization"/><iref primary="true" item="Grammar" subitem="Authorization-v"/> … … 354 353 </artwork></figure> 355 354 <t> 356 357 358 359 360 361 362 355 HTTP access authentication is described in "HTTP Authentication: 356 Basic and Digest Access Authentication" <xref target="RFC2617"/>. If a request is 357 authenticated and a realm specified, the same credentials &SHOULD; 358 be valid for all other requests within this realm (assuming that 359 the authentication scheme itself does not require otherwise, such 360 as credentials that vary according to a challenge value or using 361 synchronized clocks). 363 362 </t> 364 363 <t> … … 399 398 <x:anchor-alias value="Proxy-Authenticate-v"/> 400 399 <t> 401 The "Proxy-Authenticate" response-header field &MUST; be included as part402 of a 407 (Proxy Authentication Required) response. The field value403 consists of a challenge that indicates the authentication scheme and404 parameters applicable to the proxy for this request-target.400 The "Proxy-Authenticate" response-header field consists of a challenge that 401 indicates the authentication scheme and parameters applicable to the proxy 402 for this request-target. It &MUST; be included as part 403 of a 407 (Proxy Authentication Required) response. 405 404 </t> 406 405 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Proxy-Authenticate"/><iref primary="true" item="Grammar" subitem="Proxy-Authenticate-v"/> … … 429 428 The "Proxy-Authorization" request-header field allows the client to 430 429 identify itself (or its user) to a proxy which requires 431 authentication. The Proxy-Authorization fieldvalue consists of430 authentication. Its value consists of 432 431 credentials containing the authentication information of the user 433 432 agent for the proxy and/or realm of the resource being requested. … … 458 457 <x:anchor-alias value="WWW-Authenticate-v"/> 459 458 <t> 460 The "WWW-Authenticate" response-header field &MUST; be included in 401461 (Unauthorized) response messages. The field value consists of at462 least one challenge that indicates the authentication scheme(s) and463 parameters applicable to the request-target.459 The "WWW-Authenticate" response-header field consists of at least one 460 challenge that indicates the authentication scheme(s) and parameters 461 applicable to the request-target. It &MUST; be included in 401 462 (Unauthorized) response messages. 464 463 </t> 465 464 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="WWW-Authenticate"/><iref primary="true" item="Grammar" subitem="WWW-Authenticate-v"/>
Note: See TracChangeset
for help on using the changeset viewer.