Changeset 697 for draft-ietf-httpbis/latest/p1-messaging.html
- Timestamp:
- 25/09/09 14:43:16 (13 years ago)
- File:
-
- 1 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.
Note: See TracChangeset
for help on using the changeset viewer.