Changeset 697
- Timestamp:
- 25/09/09 14:43:16 (13 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 14 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r696 r697 1813 1813 <div id="rfc.iref.h.6"></div> 1814 1814 <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a> <a id="header.connection" href="#header.connection">Connection</a></h2> 1815 <p id="rfc.section.9.1.p.1">The general-header field "Connection"allows the sender to specify options that are desired for that particular connection1815 <p id="rfc.section.9.1.p.1">The "Connection" general-header field allows the sender to specify options that are desired for that particular connection 1816 1816 and <em class="bcp14">MUST NOT</em> be communicated by proxies over further connections. 1817 1817 </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 entity-header field "Content-Length"indicates the size of the entity-body, in number of OCTETs, sent to the recipient1845 <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 recipient 1846 1846 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. 1847 1847 </p> … … 1861 1861 <div id="rfc.iref.h.8"></div> 1862 1862 <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a> <a id="header.date" href="#header.date">Date</a></h2> 1863 <p id="rfc.section.9.3.p.1">The general-header field "Date"represents the date and time at which the message was originated, having the same semantics1863 <p id="rfc.section.9.3.p.1">The "Date" general-header field represents the date and time at which the message was originated, having the same semantics 1864 1864 as orig-date in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.1">Section 3.6.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.4"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as described in <a href="#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format. 1865 1865 </p> … … 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 request-header field "Host"specifies the Internet host and port number of the resource being requested, as obtained from1900 <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 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 1902 gateway to differentiate between internally-ambiguous URLs, such as the root "/" URL of a server for multiple host names on … … 1919 1919 <div id="rfc.iref.h.11"></div> 1920 1920 <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 request-header field "TE"indicates what extension transfer-codings it is willing to accept in the response and whether1921 <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 1922 or not it is willing to accept trailer fields in a chunked transfer-coding. Its value may consist of the keyword "trailers" 1923 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>). … … 1966 1966 <div id="rfc.iref.h.12"></div> 1967 1967 <h2 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a> <a id="header.trailer" href="#header.trailer">Trailer</a></h2> 1968 <p id="rfc.section.9.6.p.1">The general field "Trailer" indicates that the given set of header fields is present in the trailer of a message encoded with1969 chunked transfer-coding.1968 <p id="rfc.section.9.6.p.1">The "Trailer" general-header field indicates that the given set of header fields is present in the trailer of a message encoded 1969 with chunked transfer-coding. 1970 1970 </p> 1971 1971 <div id="rfc.figure.u.62"></div><pre class="inline"><span id="rfc.iref.g.103"></span><span id="rfc.iref.g.104"></span> <a href="#header.trailer" class="smpl">Trailer</a> = "Trailer" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.trailer" class="smpl">Trailer-v</a> … … 1986 1986 <div id="rfc.iref.h.13"></div> 1987 1987 <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 general-header "Transfer-Encoding"field indicates what (if any) type of transformation has been applied to the message1988 <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 message 1989 1989 body in order to safely transfer it between the sender and the recipient. This differs from the content-coding in that the 1990 1990 transfer-coding is a property of the message, not of the entity. … … 2002 2002 <div id="rfc.iref.h.14"></div> 2003 2003 <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 general-header "Upgrade" allows the client to specify what additional communication protocols it supports and would like2005 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.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. 2006 2006 </p> 2007 2007 <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> … … 2057 2057 <div id="rfc.iref.h.15"></div> 2058 2058 <h2 id="rfc.section.9.9"><a href="#rfc.section.9.9">9.9</a> <a id="header.via" href="#header.via">Via</a></h2> 2059 <p id="rfc.section.9.9.p.1">The general-header field "Via"<em class="bcp14">MUST</em> be used by gateways and proxies to indicate the intermediate protocols and recipients between the user agent and the server2059 <p id="rfc.section.9.9.p.1">The "Via" general-header field <em class="bcp14">MUST</em> be used by gateways and proxies to indicate the intermediate protocols and recipients between the user agent and the server 2060 2060 on requests, and between the origin server and the client on responses. It is analogous to the "Received" field defined in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.7">Section 3.6.7</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.5"><cite title="Internet Message Format">[RFC5322]</cite></a> and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities 2061 2061 of all senders along the request/response chain. -
draft-ietf-httpbis/latest/p1-messaging.xml
r696 r697 2490 2490 <x:anchor-alias value="Connection-v"/> 2491 2491 <t> 2492 The general-header field "Connection"allows the sender to specify2492 The "Connection" general-header field allows the sender to specify 2493 2493 options that are desired for that particular connection and &MUST-NOT; 2494 2494 be communicated by proxies over further connections. … … 2553 2553 <x:anchor-alias value="Content-Length-v"/> 2554 2554 <t> 2555 The entity-header field "Content-Length"indicates the size of the2555 The "Content-Length" entity-header field indicates the size of the 2556 2556 entity-body, in number of OCTETs, sent to the recipient or, 2557 2557 in the case of the HEAD method, the size of the entity-body that … … 2593 2593 <x:anchor-alias value="Date-v"/> 2594 2594 <t> 2595 The general-header field "Date"represents the date and time at which2595 The "Date" general-header field represents the date and time at which 2596 2596 the message was originated, having the same semantics as orig-date in 2597 2597 <xref target="RFC5322" x:fmt="of" x:sec="3.6.1"/>. The field value is an … … 2673 2673 <x:anchor-alias value="Host-v"/> 2674 2674 <t> 2675 The request-header field "Host"specifies the Internet host and port2675 The "Host" request-header field specifies the Internet host and port 2676 2676 number of the resource being requested, as obtained from the original 2677 2677 URI given by the user or referring resource (generally an http URI, … … 2723 2723 <x:anchor-alias value="te-ext"/> 2724 2724 <t> 2725 The request-header field "TE"indicates what extension transfer-codings2725 The "TE" request-header field indicates what extension transfer-codings 2726 2726 it is willing to accept in the response and whether or not it is 2727 2727 willing to accept trailer fields in a chunked transfer-coding. Its … … 2802 2802 <x:anchor-alias value="Trailer-v"/> 2803 2803 <t> 2804 The general field "Trailer"indicates that the given set of2804 The "Trailer" general-header field indicates that the given set of 2805 2805 header fields is present in the trailer of a message encoded with 2806 2806 chunked transfer-coding. … … 2838 2838 <x:anchor-alias value="Transfer-Encoding-v"/> 2839 2839 <t> 2840 The general-header "Transfer-Encoding"field indicates what (if any)2840 The "Transfer-Encoding" general-header field indicates what (if any) 2841 2841 type of transformation has been applied to the message body in order 2842 2842 to safely transfer it between the sender and the recipient. This … … 2873 2873 <x:anchor-alias value="Upgrade-v"/> 2874 2874 <t> 2875 The general-header "Upgrade"allows the client to specify what2875 The "Upgrade" general-header field allows the client to specify what 2876 2876 additional communication protocols it supports and would like to use 2877 2877 if the server finds it appropriate to switch protocols. The server … … 2982 2982 <x:anchor-alias value="Via-v"/> 2983 2983 <t> 2984 The general-header field "Via"&MUST; be used by gateways and proxies to2984 The "Via" general-header field &MUST; be used by gateways and proxies to 2985 2985 indicate the intermediate protocols and recipients between the user 2986 2986 agent and the server on requests, and between the origin server and -
draft-ietf-httpbis/latest/p2-semantics.html
r695 r697 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- 16">401 <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-25"> 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 2 0, 2010</td>438 <td class="header left">Expires: March 29, 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 16, 2009</td>487 <td class="header right">September 25, 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 2 0, 2010.</p>511 <p>This Internet-Draft will expire in March 29, 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> … … 1503 1503 <div id="rfc.iref.h.2"></div> 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 <p id="rfc.section.9.1.p.1">The response-header field "Allow"lists the set of methods advertised as supported by the resource identified by the request-target.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 1506 The purpose of this field is strictly to inform the recipient of valid methods associated with the resource. An Allow header 1507 1507 field <em class="bcp14">MUST</em> be present in a 405 (Method Not Allowed) response. … … 1518 1518 <div id="rfc.iref.h.3"></div> 1519 1519 <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a> <a id="header.expect" href="#header.expect">Expect</a></h2> 1520 <p id="rfc.section.9.2.p.1">The request-header field "Expect"is used to indicate that particular server behaviors are required by the client.</p>1520 <p id="rfc.section.9.2.p.1">The "Expect" request-header field is used to indicate that particular server behaviors are required by the client.</p> 1521 1521 <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span> <a href="#header.expect" class="smpl">Expect</a> = "Expect" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.expect" class="smpl">Expect-v</a> 1522 1522 <a href="#header.expect" class="smpl">Expect-v</a> = 1#<a href="#header.expect" class="smpl">expectation</a> … … 1544 1544 <div id="rfc.iref.h.4"></div> 1545 1545 <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a> <a id="header.from" href="#header.from">From</a></h2> 1546 <p id="rfc.section.9.3.p.1">The request-header field "From", if given, <em class="bcp14">SHOULD</em> contain an Internet e-mail address for the human user who controls the requesting user agent. The address <em class="bcp14">SHOULD</em> be machine-usable, as defined by "mailbox" in <a href="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a>:1546 <p id="rfc.section.9.3.p.1">The "From" request-header field, if given, <em class="bcp14">SHOULD</em> contain an Internet e-mail address for the human user who controls the requesting user agent. The address <em class="bcp14">SHOULD</em> be machine-usable, as defined by "mailbox" in <a href="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a>: 1547 1547 </p> 1548 1548 <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span> <a href="#header.from" class="smpl">From</a> = "From" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.from" class="smpl">From-v</a> … … 1566 1566 <div id="rfc.iref.h.5"></div> 1567 1567 <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 response-header field "Location"is used for the identification of a new resource or to redirect the recipient to a location1568 <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 1569 other than the request-target for completion of the request. For 201 (Created) responses, the Location is that of the new 1570 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. … … 1587 1587 <div id="rfc.iref.h.6"></div> 1588 1588 <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 request-header "Max-Forwards"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 be1589 <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 be 1590 1590 useful when the client is attempting to trace a request chain which appears to be failing or looping in mid-chain. 1591 1591 </p> … … 1601 1601 <div id="rfc.iref.h.7"></div> 1602 1602 <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 request-header field "Referer" [sic]allows the client to specify, for the server's benefit, the address (URI) of the1603 <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 the 1604 1604 resource from which the request-target was obtained (the "referrer", although the header field is misspelled.). 1605 1605 </p> … … 1640 1640 <div id="rfc.iref.h.9"></div> 1641 1641 <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 response-header field "Server"contains information about the software used by the origin server to handle the request.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 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 significance 1644 1644 for identifying the application. … … 1660 1660 <div id="rfc.iref.h.10"></div> 1661 1661 <h2 id="rfc.section.9.9"><a href="#rfc.section.9.9">9.9</a> <a id="header.user-agent" href="#header.user-agent">User-Agent</a></h2> 1662 <p id="rfc.section.9.9.p.1">The request-header field "User-Agent"contains information about the user agent originating the request. This is for statistical1662 <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 1663 purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses 1664 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 -
draft-ietf-httpbis/latest/p2-semantics.xml
r695 r697 1868 1868 <x:anchor-alias value="Allow-v"/> 1869 1869 <t> 1870 The response-header field "Allow"lists the set of methods advertised as1871 1872 1873 1874 1870 The "Allow" response-header field lists the set of methods advertised as 1871 supported by the resource identified by the request-target. The purpose of 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. 1875 1875 </t> 1876 1876 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Allow"/><iref primary="true" item="Grammar" subitem="Allow-v"/> … … 1904 1904 <x:anchor-alias value="expect-params"/> 1905 1905 <t> 1906 The request-header field "Expect"is used to indicate that particular1906 The "Expect" request-header field is used to indicate that particular 1907 1907 server behaviors are required by the client. 1908 1908 </t> … … 1958 1958 <x:anchor-alias value="mailbox"/> 1959 1959 <t> 1960 The request-header field "From", if given, &SHOULD; contain an Internet1960 The "From" request-header field, if given, &SHOULD; contain an Internet 1961 1961 e-mail address for the human user who controls the requesting user 1962 1962 agent. The address &SHOULD; be machine-usable, as defined by "mailbox" … … 2006 2006 <x:anchor-alias value="Location-v"/> 2007 2007 <t> 2008 The response-header field "Location"is used for the identification of a2008 The "Location" response-header field is used for the identification of a 2009 2009 new resource or to redirect the recipient to a location other than the 2010 2010 request-target for completion of the request. For 201 (Created) … … 2048 2048 <x:anchor-alias value="Max-Forwards-v"/> 2049 2049 <t> 2050 The request-header "Max-Forwards"field provides a mechanism with the2050 The "Max-Forwards" request-header field provides a mechanism with the 2051 2051 TRACE (<xref target="TRACE"/>) and OPTIONS (<xref target="OPTIONS"/>) methods to limit the 2052 2052 number of proxies or gateways that can forward the request to the … … 2085 2085 <x:anchor-alias value="Referer-v"/> 2086 2086 <t> 2087 The request-header field "Referer" [sic]allows the client to specify, for2087 The "Referer" [sic] request-header field allows the client to specify, for 2088 2088 the server's benefit, the address (URI) of the resource from which the 2089 2089 request-target was obtained (the "referrer", although the header field is … … 2165 2165 <x:anchor-alias value="Server-v"/> 2166 2166 <t> 2167 The response-header field "Server"contains information about the2167 The "Server" response-header field contains information about the 2168 2168 software used by the origin server to handle the request. The field 2169 2169 can contain multiple product tokens (&product-tokens;) and comments … … 2205 2205 <x:anchor-alias value="User-Agent-v"/> 2206 2206 <t> 2207 The request-header field "User-Agent"contains information about the2207 The "User-Agent" request-header field contains information about the 2208 2208 user agent originating the request. This is for statistical purposes, 2209 2209 the tracing of protocol violations, and automated recognition of user -
draft-ietf-httpbis/latest/p3-payload.html
r690 r697 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- 05">409 <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-25"> 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 9, 2010</td>441 <td class="header left">Expires: March 29, 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 5, 2009</td>494 <td class="header right">September 25, 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 9, 2010.</p>518 <p>This Internet-Draft will expire in March 29, 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 request-header field "Accept"can be used to specify certain media types which are acceptable for the response. Accept1012 <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. Accept 1013 1013 headers can be used to indicate that the request is specifically limited to a small set of desired types, as in the case of 1014 1014 a request for an in-line image. … … 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 request-header field "Accept-Charset"can be used to indicate what character sets are acceptable for the response. This1114 <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. This 1115 1115 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. … … 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 request-header field "Accept-Encoding"is similar to Accept, but restricts the content-codings (<a href="#content.codings" title="Content Codings">Section 2.2</a>) that are acceptable in the response.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>) that 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 request-header field "Accept-Language"is similar to Accept, but restricts the set of natural languages that are preferred1188 <p id="rfc.section.5.4.p.1">The "Accept-Language" request-header field is similar to Accept, but restricts the set of natural languages that are preferred 1189 1189 as a response to the request. Language tags are defined in <a href="#language.tags" title="Language Tags">Section 2.4</a>. 1190 1190 </p> … … 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 entity-header field "Content-Encoding"is used as a modifier to the media-type. When present, its value indicates what1239 <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 1240 additional content codings have been applied to the entity-body, and thus what decoding mechanisms must be applied in order 1241 1241 to obtain the media-type referenced by the Content-Type header field. Content-Encoding is primarily used to allow a document … … 1260 1260 <div id="rfc.iref.h.6"></div> 1261 1261 <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 entity-header field "Content-Language"describes the natural language(s) of the intended audience for the enclosed entity.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 enclosed entity. 1263 1263 Note that this might not be equivalent to all the languages used within the entity-body. 1264 1264 </p> … … 1286 1286 <div id="rfc.iref.h.7"></div> 1287 1287 <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 entity-header field "Content-Location"<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 location1288 <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 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 1290 1290 multiple entities associated with it, and those entities actually have separate locations by which they might be individually … … 1308 1308 <div id="rfc.iref.h.8"></div> 1309 1309 <h2 id="rfc.section.5.8"><a href="#rfc.section.5.8">5.8</a> <a id="header.content-md5" href="#header.content-md5">Content-MD5</a></h2> 1310 <p id="rfc.section.5.8.p.1">The entity-header field "Content-MD5", as defined in <a href="#RFC1864" id="rfc.xref.RFC1864.1"><cite title="The Content-MD5 Header Field">[RFC1864]</cite></a>, is an MD5 digest of the entity-body for the purpose of providing an end-to-end message integrity check (MIC) of the entity-body.1310 <p id="rfc.section.5.8.p.1">The "Content-MD5" entity-header field, as defined in <a href="#RFC1864" id="rfc.xref.RFC1864.1"><cite title="The Content-MD5 Header Field">[RFC1864]</cite></a>, is an MD5 digest of the entity-body for the purpose of providing an end-to-end message integrity check (MIC) of the entity-body. 1311 1311 (Note: a MIC is good for detecting accidental modification of the entity-body in transit, but is not proof against malicious 1312 1312 attacks.) … … 1346 1346 <div id="rfc.iref.h.9"></div> 1347 1347 <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 entity-header field "Content-Type"indicates the media type of the entity-body sent to the recipient or, in the case of1348 <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 of 1349 1349 the HEAD method, the media type that would have been sent had the request been a GET. 1350 1350 </p> … … 1776 1776 <div id="rfc.iref.c.12"></div> 1777 1777 <h2 id="rfc.section.B.1"><a href="#rfc.section.B.1">B.1</a> <a id="content-disposition" href="#content-disposition">Content-Disposition</a></h2> 1778 <p id="rfc.section.B.1.p.1">The Content-Dispositionresponse-header field has been proposed as a means for the origin server to suggest a default filename1778 <p id="rfc.section.B.1.p.1">The "Content-Disposition" response-header field has been proposed as a means for the origin server to suggest a default filename 1779 1779 if the user requests that the content is saved to a file. This usage is derived from the definition of Content-Disposition 1780 1780 in <a href="#RFC2183" id="rfc.xref.RFC2183.3"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a>. -
draft-ietf-httpbis/latest/p3-payload.xml
r690 r697 983 983 <x:anchor-alias value="media-range"/> 984 984 <t> 985 The request-header field "Accept"can be used to specify certain media985 The "Accept" request-header field can be used to specify certain media 986 986 types which are acceptable for the response. Accept headers can be 987 987 used to indicate that the request is specifically limited to a small … … 1110 1110 <x:anchor-alias value="Accept-Charset-v"/> 1111 1111 <t> 1112 The request-header field "Accept-Charset"can be used to indicate what1112 The "Accept-Charset" request-header field can be used to indicate what 1113 1113 character sets are acceptable for the response. This field allows 1114 1114 clients capable of understanding more comprehensive or special-purpose … … 1155 1155 <x:anchor-alias value="codings"/> 1156 1156 <t> 1157 The request-header field "Accept-Encoding"is similar to Accept, but1157 The "Accept-Encoding" request-header field is similar to Accept, but 1158 1158 restricts the content-codings (<xref target="content.codings"/>) that are acceptable in 1159 1159 the response. … … 1245 1245 <x:anchor-alias value="language-range"/> 1246 1246 <t> 1247 The request-header field "Accept-Language"is similar to Accept, but1247 The "Accept-Language" request-header field is similar to Accept, but 1248 1248 restricts the set of natural languages that are preferred as a 1249 1249 response to the request. Language tags are defined in <xref target="language.tags"/>. … … 1341 1341 <x:anchor-alias value="Content-Encoding-v"/> 1342 1342 <t> 1343 The entity-header field "Content-Encoding"is used as a modifier to the1343 The "Content-Encoding" entity-header field is used as a modifier to the 1344 1344 media-type. When present, its value indicates what additional content 1345 1345 codings have been applied to the entity-body, and thus what decoding … … 1391 1391 <x:anchor-alias value="Content-Language-v"/> 1392 1392 <t> 1393 The entity-header field "Content-Language"describes the natural1393 The "Content-Language" entity-header field describes the natural 1394 1394 language(s) of the intended audience for the enclosed entity. Note 1395 1395 that this might not be equivalent to all the languages used within … … 1445 1445 <x:anchor-alias value="Content-Location-v"/> 1446 1446 <t> 1447 The entity-header field "Content-Location"&MAY; be used to supply the1447 The "Content-Location" entity-header field &MAY; be used to supply the 1448 1448 resource location for the entity enclosed in the message when that 1449 1449 entity is accessible from a location separate from the requested … … 1496 1496 <x:anchor-alias value="Content-MD5-v"/> 1497 1497 <t> 1498 The entity-header field "Content-MD5", as defined in <xref target="RFC1864"/>, is1498 The "Content-MD5" entity-header field, as defined in <xref target="RFC1864"/>, is 1499 1499 an MD5 digest of the entity-body for the purpose of providing an 1500 1500 end-to-end message integrity check (MIC) of the entity-body. (Note: a … … 1573 1573 <x:anchor-alias value="Content-Type-v"/> 1574 1574 <t> 1575 The entity-header field "Content-Type"indicates the media type of the1575 The "Content-Type" entity-header field indicates the media type of the 1576 1576 entity-body sent to the recipient or, in the case of the HEAD method, 1577 1577 the media type that would have been sent had the request been a GET. … … 2675 2675 <x:anchor-alias value="filename-parm"/> 2676 2676 <t> 2677 The Content-Dispositionresponse-header field has been proposed as a2677 The "Content-Disposition" response-header field has been proposed as a 2678 2678 means for the origin server to suggest a default filename if the user 2679 2679 requests that the content is saved to a file. This usage is derived -
draft-ietf-httpbis/latest/p4-conditional.html
r689 r697 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- 01">398 <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-25"> 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 5, 2010</td>430 <td class="header left">Expires: March 29, 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 1, 2009</td>483 <td class="header right">September 25, 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 5, 2010.</p>507 <p>This Internet-Draft will expire in March 29, 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 response-header field "ETag"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. 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>). 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 request-header field "If-Match"is used with a method to make it conditional. 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 with a method to make it 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 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. … … 912 912 <div id="rfc.iref.h.3"></div> 913 913 <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 request-header field "If-Modified-Since"is used with a method to make it conditional: if the requested variant has not914 <p id="rfc.section.6.3.p.1">The "If-Modified-Since" request-header field is used with a method to make it conditional: if the requested variant has not 915 915 been modified since the time specified in this field, an entity will not be returned from the server; instead, a 304 (Not 916 916 Modified) response will be returned without any message-body. … … 959 959 <div id="rfc.iref.h.4"></div> 960 960 <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 request-header field "If-None-Match"is used with a method to make it conditional. A client that has one or more entities961 <p id="rfc.section.6.4.p.1">The "If-None-Match" request-header field is used with a method to make it conditional. A client that has one or more entities 962 962 previously obtained from the resource can verify that none of those entities is current by including a list of their associated 963 963 entity tags in the If-None-Match header field. The purpose of this feature is to allow efficient updates of cached information … … 993 993 <div id="rfc.iref.h.5"></div> 994 994 <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 request-header field "If-Unmodified-Since"is used with a method to make it conditional. If the requested resource has995 <p id="rfc.section.6.5.p.1">The "If-Unmodified-Since" request-header field is used with a method to make it conditional. If the requested resource has 996 996 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 997 </p> … … 1013 1013 <div id="rfc.iref.h.6"></div> 1014 1014 <h2 id="rfc.section.6.6"><a href="#rfc.section.6.6">6.6</a> <a id="header.last-modified" href="#header.last-modified">Last-Modified</a></h2> 1015 <p id="rfc.section.6.6.p.1">The entity-header field "Last-Modified"indicates the date and time at which the origin server believes the variant was last1015 <p id="rfc.section.6.6.p.1">The "Last-Modified" entity-header field indicates the date and time at which the origin server believes the variant was last 1016 1016 modified. 1017 1017 </p> -
draft-ietf-httpbis/latest/p4-conditional.xml
r689 r697 688 688 <x:anchor-alias value="ETag-v"/> 689 689 <t> 690 The response-header field "ETag"provides the current value of the690 The "ETag" response-header field provides the current value of the 691 691 entity tag (see <xref target="entity.tags"/>) for the requested variant. 692 692 The headers used with entity … … 734 734 <x:anchor-alias value="If-Match-v"/> 735 735 <t> 736 The request-header field "If-Match"is used with a method to make it736 The "If-Match" request-header field is used with a method to make it 737 737 conditional. A client that has one or more entities previously 738 738 obtained from the resource can verify that one of those entities is … … 803 803 <x:anchor-alias value="If-Modified-Since-v"/> 804 804 <t> 805 The request-header field "If-Modified-Since"is used with a method to805 The "If-Modified-Since" request-header field is used with a method to 806 806 make it conditional: if the requested variant has not been modified 807 807 since the time specified in this field, an entity will not be … … 888 888 <x:anchor-alias value="If-None-Match-v"/> 889 889 <t> 890 The request-header field "If-None-Match"is used with a method to make890 The "If-None-Match" request-header field is used with a method to make 891 891 it conditional. A client that has one or more entities previously 892 892 obtained from the resource can verify that none of those entities is … … 965 965 <x:anchor-alias value="If-Unmodified-Since-v"/> 966 966 <t> 967 The request-header field "If-Unmodified-Since"is used with a method to967 The "If-Unmodified-Since" request-header field is used with a method to 968 968 make it conditional. If the requested resource has not been modified 969 969 since the time specified in this field, the server &SHOULD; perform the … … 1008 1008 <x:anchor-alias value="Last-Modified-v"/> 1009 1009 <t> 1010 The entity-header field "Last-Modified"indicates the date and time at1010 The "Last-Modified" entity-header field indicates the date and time at 1011 1011 which the origin server believes the variant was last modified. 1012 1012 </t> -
draft-ietf-httpbis/latest/p5-range.html
r689 r697 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- 01">398 <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-25"> 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 5, 2010</td>430 <td class="header left">Expires: March 29, 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 1, 2009</td>483 <td class="header right">September 25, 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 5, 2010.</p>507 <p>This Internet-Draft will expire in March 29, 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 response-header "Accept-Ranges"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 the server to indicate its acceptance of range requests for a resource:</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> … … 710 710 <div id="rfc.iref.h.2"></div> 711 711 <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a> <a id="header.content-range" href="#header.content-range">Content-Range</a></h2> 712 <p id="rfc.section.5.2.p.1">The entity-header "Content-Range"is sent with a partial entity-body to specify where in the full entity-body the partial712 <p id="rfc.section.5.2.p.1">The "Content-Range" entity-header field is sent with a partial entity-body to specify where in the full entity-body the partial 713 713 body should be applied. Range units are defined in <a href="#range.units" title="Range Units">Section 2</a>. 714 714 </p> … … 794 794 to obtain the entire current entity-body. 795 795 </p> 796 <p id="rfc.section.5.3.p.2">The request header "If-Range" allows a client to "short-circuit" the second request. Informally, its meaning is `if the entity797 is unchanged, send me the part(s) that I am missing; otherwise, send me the entire new entity'.796 <p id="rfc.section.5.3.p.2">The "If-Range" request-header field allows a client to "short-circuit" the second request. Informally, its meaning is `if 797 the entity is unchanged, send me the part(s) that I am missing; otherwise, send me the entire new entity'. 798 798 </p> 799 799 <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span> <a href="#header.if-range" class="smpl">If-Range</a> = "If-Range" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.if-range" class="smpl">If-Range-v</a> -
draft-ietf-httpbis/latest/p5-range.xml
r689 r697 458 458 <x:anchor-alias value="acceptable-ranges"/> 459 459 <t> 460 The response-header "Accept-Ranges"field allows the server to461 460 The "Accept-Ranges" response-header field allows the server to 461 indicate its acceptance of range requests for a resource: 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"/> … … 501 501 <x:anchor-alias value="other-range-resp-spec"/> 502 502 <t> 503 The entity-header "Content-Range"is sent with a partial entity-body to503 The "Content-Range" entity-header field is sent with a partial entity-body to 504 504 specify where in the full entity-body the partial body should be 505 505 applied. Range units are defined in <xref target="range.units"/>. … … 655 655 </t> 656 656 <t> 657 The request header "If-Range"allows a client to "short-circuit" the second657 The "If-Range" request-header field allows a client to "short-circuit" the second 658 658 request. Informally, its meaning is `if the entity is unchanged, send 659 659 me the part(s) that I am missing; otherwise, send me the entire new -
draft-ietf-httpbis/latest/p6-cache.html
r694 r697 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- 16">400 <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-25"> 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 2 0, 2010</td>432 <td class="header left">Expires: March 29, 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 16, 2009</td>489 <td class="header right">September 25, 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 2 0, 2010.</p>513 <p>This Internet-Draft will expire in March 29, 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 response-header field "Age"conveys the sender's estimate of the amount of time since the response (or its validation)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 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>. 978 978 </p> … … 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 general-header field "Cache-Control"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 from994 <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 995 adversely interfering with the request or response. Cache directives are unidirectional in that the presence of a directive 996 996 in a request does not imply that the same directive is to be given in the response. … … 1195 1195 <div id="rfc.iref.h.4"></div> 1196 1196 <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> <a id="header.expires" href="#header.expires">Expires</a></h2> 1197 <p id="rfc.section.3.3.p.1">The entity-header field "Expires"gives the date/time after which the response is considered stale. See <a href="#expiration.model" title="Freshness Model">Section 2.3</a> for further discussion of the freshness model.1197 <p id="rfc.section.3.3.p.1">The "Expires" entity-header field gives the date/time after which the response is considered stale. See <a href="#expiration.model" title="Freshness Model">Section 2.3</a> for further discussion of the freshness model. 1198 1198 </p> 1199 1199 <p id="rfc.section.3.3.p.2">The presence of an Expires field does not imply that the original resource will change or cease to exist at, before, or after … … 1217 1217 <div id="rfc.iref.h.5"></div> 1218 1218 <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a> <a id="header.pragma" href="#header.pragma">Pragma</a></h2> 1219 <p id="rfc.section.3.4.p.1">The general-header field "Pragma"is used to include implementation-specific directives that might apply to any recipient1219 <p id="rfc.section.3.4.p.1">The "Pragma" general-header field is used to include implementation-specific directives that might apply to any recipient 1220 1220 along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, 1221 1221 some systems <em class="bcp14">MAY</em> require that behavior be consistent with the directives. … … 1261 1261 <div id="rfc.iref.h.7"></div> 1262 1262 <h2 id="rfc.section.3.6"><a href="#rfc.section.3.6">3.6</a> <a id="header.warning" href="#header.warning">Warning</a></h2> 1263 <p id="rfc.section.3.6.p.1">The general-header field "Warning"is used to carry additional information about the status or transformation of a message1263 <p id="rfc.section.3.6.p.1">The "Warning" general-header field is used to carry additional information about the status or transformation of a message 1264 1264 that might not be reflected in the message. This information is typically used to warn about possible incorrectness introduced 1265 1265 by caching operations or transformations applied to the entity body of the message. -
draft-ietf-httpbis/latest/p6-cache.xml
r694 r697 29 29 <!ENTITY header-via "<xref target='Part1' x:rel='#header.via' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 30 30 <!ENTITY header-last-modified "<xref target='Part4' x:rel='#header.last-modified' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 31 <!ENTITY header-fields "<xref target='Part1' x:rel='#header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">31 <!ENTITY header-fields "<xref target='Part1' x:rel='#header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 32 32 <!ENTITY message-length "<xref target='Part1' x:rel='#message.length' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 33 33 <!ENTITY safe-methods "<xref target='Part2' x:rel='#safe.methods' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 895 895 <x:anchor-alias value="age-value"/> 896 896 <t> 897 The response-header field "Age"conveys the sender's estimate of the amount of time since897 The "Age" response-header field conveys the sender's estimate of the amount of time since 898 898 the response (or its validation) was generated at the origin server. Age values are 899 899 calculated as specified in <xref target="age.calculations" />. … … 933 933 <x:anchor-alias value="cache-response-directive"/> 934 934 <t> 935 The general-header field "Cache-Control"is used to specify directives that &MUST; be935 The "Cache-Control" general-header field is used to specify directives that &MUST; be 936 936 obeyed by all caches along the request/response chain. The directives specify behavior 937 937 intended to prevent caches from adversely interfering with the request or response. Cache … … 1249 1249 <x:anchor-alias value="Expires-v"/> 1250 1250 <t> 1251 The entity-header field "Expires"gives the date/time after which the response is1251 The "Expires" entity-header field gives the date/time after which the response is 1252 1252 considered stale. See <xref target="expiration.model" /> for further discussion of the 1253 1253 freshness model. … … 1294 1294 <x:anchor-alias value="pragma-directive"/> 1295 1295 <t> 1296 The general-header field "Pragma"is used to include implementation-specific directives1296 The "Pragma" general-header field is used to include implementation-specific directives 1297 1297 that might apply to any recipient along the request/response chain. All pragma directives 1298 1298 specify optional behavior from the viewpoint of the protocol; however, some systems … … 1382 1382 <x:anchor-alias value="warn-text"/> 1383 1383 <t> 1384 The general-header field "Warning"is used to carry additional information about the status1384 The "Warning" general-header field is used to carry additional information about the status 1385 1385 or transformation of a message that might not be reflected in the message. This 1386 1386 information is typically used to warn about possible incorrectness introduced by caching -
draft-ietf-httpbis/latest/p7-auth.html
r689 r697 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- 01">392 <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-25"> 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 5, 2010</td>429 <td class="header left">Expires: March 29, 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 1, 2009</td>478 <td class="header right">September 25, 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 5, 2010.</p>502 <p>This Internet-Draft will expire in March 29, 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> … … 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 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--does 630 so by including an Authorization request-header field with the request. The field "Authorization" consists of credentials631 containingthe authentication information of the user agent for the realm of the resource being requested.630 so by including an "Authorization" request-header field with the request. The field value consists of credentials containing 631 the authentication information of the user agent 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 response-header field "Proxy-Authenticate"<em class="bcp14">MUST</em> be included as part of a 407 (Proxy Authentication Required) response. The field value consists of a challenge that indicates654 <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 indicates 655 655 the authentication scheme and parameters applicable to the proxy for this request-target. 656 656 </p> … … 665 665 <div id="rfc.iref.h.3"></div> 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 <p id="rfc.section.3.3.p.1">The request-header field "Proxy-Authorization"allows the client to identify itself (or its user) to a proxy which requires667 <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 668 authentication. The Proxy-Authorization field value consists of credentials containing the authentication information of the 669 669 user agent for the proxy and/or realm of the resource being requested. … … 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-Authenticateresponse-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 the682 <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 the 683 683 authentication scheme(s) and parameters applicable to the request-target. 684 684 </p> -
draft-ietf-httpbis/latest/p7-auth.xml
r689 r697 342 342 <x:anchor-alias value="Authorization-v"/> 343 343 <t> 344 345 346 so by including an Authorizationrequest-header field with the347 request. The field "Authorization"consists of credentials348 349 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. 350 350 </t> 351 351 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Authorization"/><iref primary="true" item="Grammar" subitem="Authorization-v"/> … … 399 399 <x:anchor-alias value="Proxy-Authenticate-v"/> 400 400 <t> 401 The response-header field "Proxy-Authenticate"&MUST; be included as part401 The "Proxy-Authenticate" response-header field &MUST; be included as part 402 402 of a 407 (Proxy Authentication Required) response. The field value 403 403 consists of a challenge that indicates the authentication scheme and … … 427 427 <x:anchor-alias value="Proxy-Authorization-v"/> 428 428 <t> 429 The request-header field "Proxy-Authorization"allows the client to429 The "Proxy-Authorization" request-header field allows the client to 430 430 identify itself (or its user) to a proxy which requires 431 431 authentication. The Proxy-Authorization field value consists of … … 458 458 <x:anchor-alias value="WWW-Authenticate-v"/> 459 459 <t> 460 The WWW-Authenticateresponse-header field &MUST; be included in 401460 The "WWW-Authenticate" response-header field &MUST; be included in 401 461 461 (Unauthorized) response messages. The field value consists of at 462 462 least one challenge that indicates the authentication scheme(s) and
Note: See TracChangeset
for help on using the changeset viewer.