Changeset 354
- Timestamp:
- 12/11/08 23:36:52 (14 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r353 r354 1564 1564 <div id="rfc.iref.h.3"></div> 1565 1565 <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a> <a id="header.connection" href="#header.connection">Connection</a></h2> 1566 <p id="rfc.section.8.1.p.1">The Connection general-header field allows the sender to specify options that are desired for that particular connection and <em class="bcp14">MUST NOT</em> be communicated by proxies over further connections. 1567 </p> 1568 <p id="rfc.section.8.1.p.2">The Connection header has the following grammar:</p> 1569 <div id="rfc.figure.u.43"></div><pre class="inline"><span id="rfc.iref.g.72"></span><span id="rfc.iref.g.73"></span> <a href="#header.connection" class="smpl">Connection</a> = "Connection" ":" 1#(<a href="#header.connection" class="smpl">connection-token</a>) 1570 <a href="#header.connection" class="smpl">connection-token</a> = <a href="#rule.token.separators" class="smpl">token</a> 1566 <p id="rfc.section.8.1.p.1">The general-header field "Connection" allows the sender to specify options that are desired for that particular connection 1567 and <em class="bcp14">MUST NOT</em> be communicated by proxies over further connections. 1568 </p> 1569 <p id="rfc.section.8.1.p.2">The Connection header's value has the following grammar:</p> 1570 <div id="rfc.figure.u.43"></div><pre class="inline"><span id="rfc.iref.g.72"></span><span id="rfc.iref.g.73"></span><span id="rfc.iref.g.74"></span> <a href="#header.connection" class="smpl">Connection</a> = "Connection" <a href="#rule.whitespace" class="smpl">BWS</a> ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.connection" class="smpl">Connection-v</a> 1571 <a href="#header.connection" class="smpl">Connection-v</a> = 1#<a href="#header.connection" class="smpl">connection-token</a> 1572 <a href="#header.connection" class="smpl">connection-token</a> = <a href="#rule.token.separators" class="smpl">token</a> 1571 1573 </pre><p id="rfc.section.8.1.p.4">HTTP/1.1 proxies <em class="bcp14">MUST</em> parse the Connection header field before a message is forwarded and, for each connection-token in this field, remove any header 1572 1574 field(s) from the message with the same name as the connection-token. Connection options are signaled by the presence of a … … 1579 1581 of the response. For example, 1580 1582 </p> 1581 <div id="rfc.figure.u.44"></div><pre class="text"> 1583 <div id="rfc.figure.u.44"></div><pre class="text"> Connection: close 1582 1584 </pre><p id="rfc.section.8.1.p.8">in either the request or the response header fields indicates that the connection <em class="bcp14">SHOULD NOT</em> be considered `persistent' (<a href="#persistent.connections" title="Persistent Connections">Section 7.1</a>) after the current request/response is complete. 1583 1585 </p> … … 1592 1594 <div id="rfc.iref.h.4"></div> 1593 1595 <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a> <a id="header.content-length" href="#header.content-length">Content-Length</a></h2> 1594 <p id="rfc.section.8.2.p.1">The Content-Length entity-header fieldindicates the size of the entity-body, in decimal number of OCTETs, sent to the recipient1596 <p id="rfc.section.8.2.p.1">The entity-header field "Content-Length" indicates the size of the entity-body, in decimal number of OCTETs, sent to the recipient 1595 1597 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. 1596 1598 </p> 1597 <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.74"></span> <a href="#header.content-length" class="smpl">Content-Length</a> = "Content-Length" ":" 1*<a href="#core.rules" class="smpl">DIGIT</a> 1599 <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.75"></span><span id="rfc.iref.g.76"></span> <a href="#header.content-length" class="smpl">Content-Length</a> = "Content-Length" <a href="#rule.whitespace" class="smpl">BWS</a> ":" <a href="#rule.whitespace" class="smpl">OWS</a> 1*<a href="#header.content-length" class="smpl">Content-Length-v</a> 1600 <a href="#header.content-length" class="smpl">Content-Length-v</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a> 1598 1601 </pre><p id="rfc.section.8.2.p.3">An example is</p> 1599 <div id="rfc.figure.u.46"></div><pre class="text"> 1602 <div id="rfc.figure.u.46"></div><pre class="text"> Content-Length: 3495 1600 1603 </pre><p id="rfc.section.8.2.p.5">Applications <em class="bcp14">SHOULD</em> use this field to indicate the transfer-length of the message-body, unless this is prohibited by the rules in <a href="#message.length" title="Message Length">Section 4.4</a>. 1601 1604 </p> … … 1609 1612 <div id="rfc.iref.h.5"></div> 1610 1613 <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a> <a id="header.date" href="#header.date">Date</a></h2> 1611 <p id="rfc.section.8.3.p.1">The Date general-header fieldrepresents the date and time at which the message was originated, having the same semantics1614 <p id="rfc.section.8.3.p.1">The general-header field "Date" represents the date and time at which the message was originated, having the same semantics 1612 1615 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="#full.date" title="Full Date">Section 3.3.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format. 1613 1616 </p> 1614 <div id="rfc.figure.u.47"></div><pre class="inline"><span id="rfc.iref.g.75"></span> <a href="#header.date" class="smpl">Date</a> = "Date" ":" <a href="#full.date" class="smpl">HTTP-date</a> 1617 <div id="rfc.figure.u.47"></div><pre class="inline"><span id="rfc.iref.g.77"></span><span id="rfc.iref.g.78"></span> <a href="#header.date" class="smpl">Date</a> = "Date" <a href="#rule.whitespace" class="smpl">BWS</a> ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.date" class="smpl">Date-v</a> 1618 <a href="#header.date" class="smpl">Date-v</a> = <a href="#full.date" class="smpl">HTTP-date</a> 1615 1619 </pre><p id="rfc.section.8.3.p.3">An example is</p> 1616 <div id="rfc.figure.u.48"></div><pre class="text"> 1620 <div id="rfc.figure.u.48"></div><pre class="text"> Date: Tue, 15 Nov 1994 08:12:31 GMT 1617 1621 </pre><p id="rfc.section.8.3.p.5">Origin servers <em class="bcp14">MUST</em> include a Date header field in all responses, except in these cases: 1618 1622 </p> … … 1645 1649 <div id="rfc.iref.h.7"></div> 1646 1650 <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a> <a id="header.host" href="#header.host">Host</a></h2> 1647 <p id="rfc.section.8.4.p.1">The Host request-header fieldspecifies the Internet host and port number of the resource being requested, as obtained from1651 <p id="rfc.section.8.4.p.1">The request-header field "Host" specifies the Internet host and port number of the resource being requested, as obtained from 1648 1652 the original URI given by the user or referring resource (generally an HTTP URL, as described in <a href="#http.url" title="http URL">Section 3.2.2</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 1649 1653 gateway to differentiate between internally-ambiguous URLs, such as the root "/" URL of a server for multiple host names on 1650 1654 a single IP address. 1651 1655 </p> 1652 <div id="rfc.figure.u.49"></div><pre class="inline"><span id="rfc.iref.g.76"></span> <a href="#header.host" class="smpl">Host</a> = "Host" ":" <a href="#general.syntax" class="smpl">uri-host</a> [ ":" <a href="#general.syntax" class="smpl">port</a> ] ; <a href="#http.url" title="http URL">Section 3.2.2</a> 1656 <div id="rfc.figure.u.49"></div><pre class="inline"><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span> <a href="#header.host" class="smpl">Host</a> = "Host" <a href="#rule.whitespace" class="smpl">BWS</a> ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.host" class="smpl">Host-v</a> 1657 <a href="#header.host" class="smpl">Host-v</a> = <a href="#general.syntax" class="smpl">uri-host</a> [ ":" <a href="#general.syntax" class="smpl">port</a> ] ; <a href="#http.url" title="http URL">Section 3.2.2</a> 1653 1658 </pre><p id="rfc.section.8.4.p.3">A "host" without any trailing port information implies the default port for the service requested (e.g., "80" for an HTTP 1654 1659 URL). For example, a request on the origin server for <http://www.example.org/pub/WWW/> would properly include: 1655 1660 </p> 1656 <div id="rfc.figure.u.50"></div><pre class="text"> 1657 1661 <div id="rfc.figure.u.50"></div><pre class="text"> GET /pub/WWW/ HTTP/1.1 1662 Host: www.example.org 1658 1663 </pre><p id="rfc.section.8.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 name 1659 1664 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 … … 1665 1670 <div id="rfc.iref.h.8"></div> 1666 1671 <h2 id="rfc.section.8.5"><a href="#rfc.section.8.5">8.5</a> <a id="header.te" href="#header.te">TE</a></h2> 1667 <p id="rfc.section.8.5.p.1">The TE request-header fieldindicates what extension transfer-codings it is willing to accept in the response and whether1672 <p id="rfc.section.8.5.p.1">The request-header field "TE" indicates what extension transfer-codings it is willing to accept in the response and whether 1668 1673 or not it is willing to accept trailer fields in a chunked transfer-coding. Its value may consist of the keyword "trailers" 1669 1674 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 3.4</a>). 1670 1675 </p> 1671 <div id="rfc.figure.u.51"></div><pre class="inline"><span id="rfc.iref.g.77"></span><span id="rfc.iref.g.78"></span> <a href="#header.te" class="smpl">TE</a> = "TE" ":" #( <a href="#header.te" class="smpl">t-codings</a> ) 1676 <div id="rfc.figure.u.51"></div><pre class="inline"><span id="rfc.iref.g.81"></span><span id="rfc.iref.g.82"></span><span id="rfc.iref.g.83"></span> <a href="#header.te" class="smpl">TE</a> = "TE" <a href="#rule.whitespace" class="smpl">BWS</a> ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.te" class="smpl">TE-v</a> 1677 <a href="#header.te" class="smpl">TE-v</a> = #<a href="#header.te" class="smpl">t-codings</a> 1672 1678 <a href="#header.te" class="smpl">t-codings</a> = "trailers" / ( <a href="#transfer.codings" class="smpl">transfer-extension</a> [ <a href="#abnf.dependencies" class="smpl">accept-params</a> ] ) 1673 1679 </pre><p id="rfc.section.8.5.p.3">The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer-coding, … … 1675 1681 </p> 1676 1682 <p id="rfc.section.8.5.p.4">Examples of its use are:</p> 1677 <div id="rfc.figure.u.52"></div><pre class="text"> 1678 1679 1683 <div id="rfc.figure.u.52"></div><pre class="text"> TE: deflate 1684 TE: 1685 TE: trailers, deflate;q=0.5 1680 1686 </pre><p id="rfc.section.8.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 8.1</a>) whenever TE is present in an HTTP/1.1 message. 1681 1687 </p> … … 1709 1715 <div id="rfc.iref.h.9"></div> 1710 1716 <h2 id="rfc.section.8.6"><a href="#rfc.section.8.6">8.6</a> <a id="header.trailer" href="#header.trailer">Trailer</a></h2> 1711 <p id="rfc.section.8.6.p.1">The Trailer general field value indicates that the given set of header fields is present in the trailer of a message encoded 1712 with chunked transfer-coding. 1713 </p> 1714 <div id="rfc.figure.u.53"></div><pre class="inline"><span id="rfc.iref.g.79"></span> <a href="#header.trailer" class="smpl">Trailer</a> = "Trailer" ":" 1#<a href="#message.headers" class="smpl">field-name</a> 1717 <p id="rfc.section.8.6.p.1">The general field "Trailer" indicates that the given set of header fields is present in the trailer of a message encoded with 1718 chunked transfer-coding. 1719 </p> 1720 <div id="rfc.figure.u.53"></div><pre class="inline"><span id="rfc.iref.g.84"></span><span id="rfc.iref.g.85"></span> <a href="#header.trailer" class="smpl">Trailer</a> = "Trailer" <a href="#rule.whitespace" class="smpl">BWS</a> ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.trailer" class="smpl">Trailer-v</a> 1721 <a href="#header.trailer" class="smpl">Trailer-v</a> = 1#<a href="#message.headers" class="smpl">field-name</a> 1715 1722 </pre><p id="rfc.section.8.6.p.3">An HTTP/1.1 message <em class="bcp14">SHOULD</em> include a Trailer header field in a message using chunked transfer-coding with a non-empty trailer. Doing so allows the recipient 1716 1723 to know which header fields to expect in the trailer. … … 1728 1735 <div id="rfc.iref.h.10"></div> 1729 1736 <h2 id="rfc.section.8.7"><a href="#rfc.section.8.7">8.7</a> <a id="header.transfer-encoding" href="#header.transfer-encoding">Transfer-Encoding</a></h2> 1730 <p id="rfc.section.8.7.p.1">The Transfer-Encoding general-headerfield indicates what (if any) type of transformation has been applied to the message1737 <p id="rfc.section.8.7.p.1">The general-header "Transfer-Encoding" field indicates what (if any) type of transformation has been applied to the message 1731 1738 body in order to safely transfer it between the sender and the recipient. This differs from the content-coding in that the 1732 1739 transfer-coding is a property of the message, not of the entity. 1733 1740 </p> 1734 <div id="rfc.figure.u.54"></div><pre class="inline"><span id="rfc.iref.g.80"></span> <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = "Transfer-Encoding" ":" 1#<a href="#transfer.codings" class="smpl">transfer-coding</a> 1741 <div id="rfc.figure.u.54"></div><pre class="inline"><span id="rfc.iref.g.86"></span><span id="rfc.iref.g.87"></span> <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = "Transfer-Encoding" <a href="#rule.whitespace" class="smpl">BWS</a> ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding-v</a> 1742 <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding-v</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a> 1735 1743 </pre><p id="rfc.section.8.7.p.3">Transfer-codings are defined in <a href="#transfer.codings" title="Transfer Codings">Section 3.4</a>. An example is: 1736 1744 </p> … … 1742 1750 <div id="rfc.iref.h.11"></div> 1743 1751 <h2 id="rfc.section.8.8"><a href="#rfc.section.8.8">8.8</a> <a id="header.upgrade" href="#header.upgrade">Upgrade</a></h2> 1744 <p id="rfc.section.8.8.p.1">The Upgrade general-headerallows the client to specify what additional communication protocols it supports and would like1752 <p id="rfc.section.8.8.p.1">The general-header "Upgrade" allows the client to specify what additional communication protocols it supports and would like 1745 1753 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. 1746 1754 </p> 1747 <div id="rfc.figure.u.56"></div><pre class="inline"><span id="rfc.iref.g.81"></span> <a href="#header.upgrade" class="smpl">Upgrade</a> = "Upgrade" ":" 1#<a href="#product.tokens" class="smpl">product</a> 1755 <div id="rfc.figure.u.56"></div><pre class="inline"><span id="rfc.iref.g.88"></span><span id="rfc.iref.g.89"></span> <a href="#header.upgrade" class="smpl">Upgrade</a> = "Upgrade" <a href="#rule.whitespace" class="smpl">BWS</a> ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.upgrade" class="smpl">Upgrade-v</a> 1756 <a href="#header.upgrade" class="smpl">Upgrade-v</a> = 1#<a href="#product.tokens" class="smpl">product</a> 1748 1757 </pre><p id="rfc.section.8.8.p.3">For example,</p> 1749 <div id="rfc.figure.u.57"></div><pre class="text"> 1758 <div id="rfc.figure.u.57"></div><pre class="text"> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 1750 1759 </pre><p id="rfc.section.8.8.p.5">The Upgrade header field is intended to provide a simple mechanism for transition from HTTP/1.1 to some other, incompatible 1751 1760 protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP … … 1772 1781 <div id="rfc.iref.h.12"></div> 1773 1782 <h2 id="rfc.section.8.9"><a href="#rfc.section.8.9">8.9</a> <a id="header.via" href="#header.via">Via</a></h2> 1774 <p id="rfc.section.8.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 server1783 <p id="rfc.section.8.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 server 1775 1784 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 1776 1785 of all senders along the request/response chain. 1777 1786 </p> 1778 <div id="rfc.figure.u.58"></div><pre class="inline"><span id="rfc.iref.g.82"></span><span id="rfc.iref.g.83"></span><span id="rfc.iref.g.84"></span><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span><span id="rfc.iref.g.87"></span> <a href="#header.via" class="smpl">Via</a> = "Via" ":" 1#( <a href="#header.via" class="smpl">received-protocol</a> <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#header.via" class="smpl">received-by</a> [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] ) 1787 <div id="rfc.figure.u.58"></div><pre class="inline"><span id="rfc.iref.g.90"></span><span id="rfc.iref.g.91"></span><span id="rfc.iref.g.92"></span><span id="rfc.iref.g.93"></span><span id="rfc.iref.g.94"></span><span id="rfc.iref.g.95"></span><span id="rfc.iref.g.96"></span> <a href="#header.via" class="smpl">Via</a> = "Via" <a href="#rule.whitespace" class="smpl">BWS</a> ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.via" class="smpl">Via-v</a> 1788 <a href="#header.via" class="smpl">Via-v</a> = 1#( <a href="#header.via" class="smpl">received-protocol</a> <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#header.via" class="smpl">received-by</a> [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] ) 1779 1789 <a href="#header.via" class="smpl">received-protocol</a> = [ <a href="#header.via" class="smpl">protocol-name</a> "/" ] <a href="#header.via" class="smpl">protocol-version</a> 1780 1790 <a href="#header.via" class="smpl">protocol-name</a> = <a href="#rule.token.separators" class="smpl">token</a> … … 1799 1809 server at www.example.com. The request received by www.example.com would then have the following Via header field: 1800 1810 </p> 1801 <div id="rfc.figure.u.59"></div><pre class="text"> 1811 <div id="rfc.figure.u.59"></div><pre class="text"> Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) 1802 1812 </pre><p id="rfc.section.8.9.p.9">Proxies and gateways used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em>, by default, forward the names and ports of hosts within the firewall region. This information <em class="bcp14">SHOULD</em> only be propagated if explicitly enabled. If not enabled, the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host. 1803 1813 </p> … … 1805 1815 For example, 1806 1816 </p> 1807 <div id="rfc.figure.u.60"></div><pre class="text"> 1817 <div id="rfc.figure.u.60"></div><pre class="text"> Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy 1808 1818 </pre><p id="rfc.section.8.9.p.12">could be collapsed to</p> 1809 <div id="rfc.figure.u.61"></div><pre class="text"> 1819 <div id="rfc.figure.u.61"></div><pre class="text"> Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 1810 1820 </pre><p id="rfc.section.8.9.p.14">Applications <em class="bcp14">SHOULD NOT</em> combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced 1811 1821 by pseudonyms. Applications <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values. … … 2554 2564 </dd> 2555 2565 </dl> 2556 <p id="rfc.section.D.p.16"> <span id="rfc.iref.g. 88"></span> <dfn>gateway</dfn>2566 <p id="rfc.section.D.p.16"> <span id="rfc.iref.g.97"></span> <dfn>gateway</dfn> 2557 2567 </p> 2558 2568 <dl class="empty"> … … 2734 2744 not use them yet. 2735 2745 </li> 2746 <li>Rewrite header ABNFs to spell out whitespace rules, factor out value format definitions.</li> 2736 2747 </ul> 2737 2748 <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1> … … 2788 2799 </li> 2789 2800 <li class="indline0"><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul class="ind"> 2790 <li class="indline1">gateway <a class="iref" href="#rfc.iref.g. 88">D</a></li>2801 <li class="indline1">gateway <a class="iref" href="#rfc.iref.g.97">D</a></li> 2791 2802 <li class="indline1"><tt>Grammar</tt> 2792 2803 <ul class="ind"> … … 2805 2816 <li class="indline1"><tt>comment</tt> <a class="iref" href="#rfc.iref.g.9"><b>2.2</b></a></li> 2806 2817 <li class="indline1"><tt>Connection</tt> <a class="iref" href="#rfc.iref.g.72"><b>8.1</b></a></li> 2807 <li class="indline1"><tt>connection-token</tt> <a class="iref" href="#rfc.iref.g.73"><b>8.1</b></a></li> 2808 <li class="indline1"><tt>Content-Length</tt> <a class="iref" href="#rfc.iref.g.74"><b>8.2</b></a></li> 2818 <li class="indline1"><tt>connection-token</tt> <a class="iref" href="#rfc.iref.g.74"><b>8.1</b></a></li> 2819 <li class="indline1"><tt>Connection-v</tt> <a class="iref" href="#rfc.iref.g.73"><b>8.1</b></a></li> 2820 <li class="indline1"><tt>Content-Length</tt> <a class="iref" href="#rfc.iref.g.75"><b>8.2</b></a></li> 2821 <li class="indline1"><tt>Content-Length-v</tt> <a class="iref" href="#rfc.iref.g.76"><b>8.2</b></a></li> 2809 2822 <li class="indline1"><tt>ctext</tt> <a class="iref" href="#rfc.iref.g.10"><b>2.2</b></a></li> 2810 <li class="indline1"><tt>Date</tt> <a class="iref" href="#rfc.iref.g.75"><b>8.3</b></a></li> 2823 <li class="indline1"><tt>Date</tt> <a class="iref" href="#rfc.iref.g.77"><b>8.3</b></a></li> 2824 <li class="indline1"><tt>Date-v</tt> <a class="iref" href="#rfc.iref.g.78"><b>8.3</b></a></li> 2811 2825 <li class="indline1"><tt>date1</tt> <a class="iref" href="#rfc.iref.g.30"><b>3.3.1</b></a></li> 2812 2826 <li class="indline1"><tt>date2</tt> <a class="iref" href="#rfc.iref.g.31"><b>3.3.1</b></a></li> … … 2819 2833 <li class="indline1"><tt>general-header</tt> <a class="iref" href="#rfc.iref.g.61"><b>4.5</b></a></li> 2820 2834 <li class="indline1"><tt>generic-message</tt> <a class="iref" href="#rfc.iref.g.54"><b>4.1</b></a></li> 2821 <li class="indline1"><tt>Host</tt> <a class="iref" href="#rfc.iref.g.76"><b>8.4</b></a></li> 2835 <li class="indline1"><tt>Host</tt> <a class="iref" href="#rfc.iref.g.79"><b>8.4</b></a></li> 2836 <li class="indline1"><tt>Host-v</tt> <a class="iref" href="#rfc.iref.g.80"><b>8.4</b></a></li> 2822 2837 <li class="indline1"><tt>HTTP-date</tt> <a class="iref" href="#rfc.iref.g.25"><b>3.3.1</b></a></li> 2823 2838 <li class="indline1"><tt>HTTP-message</tt> <a class="iref" href="#rfc.iref.g.53"><b>4.1</b></a></li> … … 2838 2853 <li class="indline1"><tt>product</tt> <a class="iref" href="#rfc.iref.g.51"><b>3.5</b></a></li> 2839 2854 <li class="indline1"><tt>product-version</tt> <a class="iref" href="#rfc.iref.g.52"><b>3.5</b></a></li> 2840 <li class="indline1"><tt>protocol-name</tt> <a class="iref" href="#rfc.iref.g. 84"><b>8.9</b></a></li>2841 <li class="indline1"><tt>protocol-version</tt> <a class="iref" href="#rfc.iref.g. 85"><b>8.9</b></a></li>2842 <li class="indline1"><tt>pseudonym</tt> <a class="iref" href="#rfc.iref.g. 87"><b>8.9</b></a></li>2855 <li class="indline1"><tt>protocol-name</tt> <a class="iref" href="#rfc.iref.g.93"><b>8.9</b></a></li> 2856 <li class="indline1"><tt>protocol-version</tt> <a class="iref" href="#rfc.iref.g.94"><b>8.9</b></a></li> 2857 <li class="indline1"><tt>pseudonym</tt> <a class="iref" href="#rfc.iref.g.96"><b>8.9</b></a></li> 2843 2858 <li class="indline1"><tt>qdtext</tt> <a class="iref" href="#rfc.iref.g.12"><b>2.2</b></a></li> 2844 2859 <li class="indline1"><tt>query</tt> <a class="iref" href="#rfc.iref.g.21"><b>3.2.1</b></a></li> … … 2847 2862 <li class="indline1"><tt>quoted-text</tt> <a class="iref" href="#rfc.iref.g.13"><b>2.2</b></a></li> 2848 2863 <li class="indline1"><tt>Reason-Phrase</tt> <a class="iref" href="#rfc.iref.g.71"><b>6.1.1</b></a></li> 2849 <li class="indline1"><tt>received-by</tt> <a class="iref" href="#rfc.iref.g. 86"><b>8.9</b></a></li>2850 <li class="indline1"><tt>received-protocol</tt> <a class="iref" href="#rfc.iref.g. 83"><b>8.9</b></a></li>2864 <li class="indline1"><tt>received-by</tt> <a class="iref" href="#rfc.iref.g.95"><b>8.9</b></a></li> 2865 <li class="indline1"><tt>received-protocol</tt> <a class="iref" href="#rfc.iref.g.92"><b>8.9</b></a></li> 2851 2866 <li class="indline1"><tt>relativeURI</tt> <a class="iref" href="#rfc.iref.g.22"><b>3.2.1</b></a></li> 2852 2867 <li class="indline1"><tt>Request</tt> <a class="iref" href="#rfc.iref.g.62"><b>5</b></a></li> … … 2861 2876 <li class="indline1"><tt>Status-Code</tt> <a class="iref" href="#rfc.iref.g.69"><b>6.1.1</b></a></li> 2862 2877 <li class="indline1"><tt>Status-Line</tt> <a class="iref" href="#rfc.iref.g.68"><b>6.1</b></a></li> 2863 <li class="indline1"><tt>t-codings</tt> <a class="iref" href="#rfc.iref.g. 78"><b>8.5</b></a></li>2878 <li class="indline1"><tt>t-codings</tt> <a class="iref" href="#rfc.iref.g.83"><b>8.5</b></a></li> 2864 2879 <li class="indline1"><tt>tchar</tt> <a class="iref" href="#rfc.iref.g.7"><b>2.2</b></a></li> 2865 <li class="indline1"><tt>TE</tt> <a class="iref" href="#rfc.iref.g.77"><b>8.5</b></a></li> 2880 <li class="indline1"><tt>TE</tt> <a class="iref" href="#rfc.iref.g.81"><b>8.5</b></a></li> 2881 <li class="indline1"><tt>TE-v</tt> <a class="iref" href="#rfc.iref.g.82"><b>8.5</b></a></li> 2866 2882 <li class="indline1"><tt>TEXT</tt> <a class="iref" href="#rfc.iref.g.5"><b>2.2</b></a></li> 2867 2883 <li class="indline1"><tt>time</tt> <a class="iref" href="#rfc.iref.g.33"><b>3.3.1</b></a></li> 2868 2884 <li class="indline1"><tt>token</tt> <a class="iref" href="#rfc.iref.g.6"><b>2.2</b></a></li> 2869 <li class="indline1"><tt>Trailer</tt> <a class="iref" href="#rfc.iref.g. 79"><b>8.6</b></a></li>2885 <li class="indline1"><tt>Trailer</tt> <a class="iref" href="#rfc.iref.g.84"><b>8.6</b></a></li> 2870 2886 <li class="indline1"><tt>trailer-part</tt> <a class="iref" href="#rfc.iref.g.50"><b>3.4.1</b></a></li> 2887 <li class="indline1"><tt>Trailer-v</tt> <a class="iref" href="#rfc.iref.g.85"><b>8.6</b></a></li> 2871 2888 <li class="indline1"><tt>transfer-coding</tt> <a class="iref" href="#rfc.iref.g.37"><b>3.4</b></a></li> 2872 <li class="indline1"><tt>Transfer-Encoding</tt> <a class="iref" href="#rfc.iref.g.80"><b>8.7</b></a></li> 2889 <li class="indline1"><tt>Transfer-Encoding</tt> <a class="iref" href="#rfc.iref.g.86"><b>8.7</b></a></li> 2890 <li class="indline1"><tt>Transfer-Encoding-v</tt> <a class="iref" href="#rfc.iref.g.87"><b>8.7</b></a></li> 2873 2891 <li class="indline1"><tt>transfer-extension</tt> <a class="iref" href="#rfc.iref.g.38"><b>3.4</b></a></li> 2874 <li class="indline1"><tt>Upgrade</tt> <a class="iref" href="#rfc.iref.g.81"><b>8.8</b></a></li> 2892 <li class="indline1"><tt>Upgrade</tt> <a class="iref" href="#rfc.iref.g.88"><b>8.8</b></a></li> 2893 <li class="indline1"><tt>Upgrade-v</tt> <a class="iref" href="#rfc.iref.g.89"><b>8.8</b></a></li> 2875 2894 <li class="indline1"><tt>uri-host</tt> <a class="iref" href="#rfc.iref.g.23"><b>3.2.1</b></a></li> 2876 2895 <li class="indline1"><tt>value</tt> <a class="iref" href="#rfc.iref.g.41"><b>3.4</b></a></li> 2877 <li class="indline1"><tt>Via</tt> <a class="iref" href="#rfc.iref.g.82"><b>8.9</b></a></li> 2896 <li class="indline1"><tt>Via</tt> <a class="iref" href="#rfc.iref.g.90"><b>8.9</b></a></li> 2897 <li class="indline1"><tt>Via-v</tt> <a class="iref" href="#rfc.iref.g.91"><b>8.9</b></a></li> 2878 2898 <li class="indline1"><tt>weekday</tt> <a class="iref" href="#rfc.iref.g.35"><b>3.3.1</b></a></li> 2879 2899 <li class="indline1"><tt>wkday</tt> <a class="iref" href="#rfc.iref.g.34"><b>3.3.1</b></a></li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r353 r354 2074 2074 <x:anchor-alias value="Connection"/> 2075 2075 <x:anchor-alias value="connection-token"/> 2076 <t> 2077 The Connection general-header field allows the sender to specify 2076 <x:anchor-alias value="Connection-v"/> 2077 <t> 2078 The general-header field "Connection" allows the sender to specify 2078 2079 options that are desired for that particular connection and &MUST-NOT; 2079 2080 be communicated by proxies over further connections. 2080 2081 </t> 2081 2082 <t> 2082 The Connection header has the following grammar: 2083 </t> 2084 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Connection"/><iref primary="true" item="Grammar" subitem="connection-token"/> 2085 <x:ref>Connection</x:ref> = "Connection" ":" 1#(<x:ref>connection-token</x:ref>) 2086 <x:ref>connection-token</x:ref> = <x:ref>token</x:ref> 2083 The Connection header's value has the following grammar: 2084 </t> 2085 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Connection"/><iref primary="true" item="Grammar" subitem="Connection-v"/><iref primary="true" item="Grammar" subitem="connection-token"/> 2086 <x:ref>Connection</x:ref> = "Connection" <x:ref>BWS</x:ref> ":" <x:ref>OWS</x:ref> <x:ref>Connection-v</x:ref> 2087 <x:ref>Connection-v</x:ref> = 1#<x:ref>connection-token</x:ref> 2088 <x:ref>connection-token</x:ref> = <x:ref>token</x:ref> 2087 2089 </artwork></figure> 2088 2090 <t> … … 2106 2108 </t> 2107 2109 <figure><artwork type="example"> 2108 2110 Connection: close 2109 2111 </artwork></figure> 2110 2112 <t> … … 2135 2137 <iref primary="true" item="Headers" subitem="Content-Length" x:for-anchor=""/> 2136 2138 <x:anchor-alias value="Content-Length"/> 2137 <t> 2138 The Content-Length entity-header field indicates the size of the 2139 <x:anchor-alias value="Content-Length-v"/> 2140 <t> 2141 The entity-header field "Content-Length" indicates the size of the 2139 2142 entity-body, in decimal number of OCTETs, sent to the recipient or, 2140 2143 in the case of the HEAD method, the size of the entity-body that 2141 2144 would have been sent had the request been a GET. 2142 2145 </t> 2143 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Length"/> 2144 <x:ref>Content-Length</x:ref> = "Content-Length" ":" 1*<x:ref>DIGIT</x:ref> 2146 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Length"/><iref primary="true" item="Grammar" subitem="Content-Length-v"/> 2147 <x:ref>Content-Length</x:ref> = "Content-Length" <x:ref>BWS</x:ref> ":" <x:ref>OWS</x:ref> 1*<x:ref>Content-Length-v</x:ref> 2148 <x:ref>Content-Length-v</x:ref> = 1*<x:ref>DIGIT</x:ref> 2145 2149 </artwork></figure> 2146 2150 <t> … … 2148 2152 </t> 2149 2153 <figure><artwork type="example"> 2150 2154 Content-Length: 3495 2151 2155 </artwork></figure> 2152 2156 <t> … … 2173 2177 <iref primary="true" item="Headers" subitem="Date" x:for-anchor=""/> 2174 2178 <x:anchor-alias value="Date"/> 2175 <t> 2176 The Date general-header field represents the date and time at which 2179 <x:anchor-alias value="Date-v"/> 2180 <t> 2181 The general-header field "Date" represents the date and time at which 2177 2182 the message was originated, having the same semantics as orig-date in 2178 2183 <xref target="RFC5322" x:fmt="of" x:sec="3.6.1"/>. The field value is an … … 2180 2185 it &MUST; be sent in rfc1123-date format. 2181 2186 </t> 2182 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Date"/> 2183 <x:ref>Date</x:ref> = "Date" ":" <x:ref>HTTP-date</x:ref> 2187 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Date"/><iref primary="true" item="Grammar" subitem="Date-v"/> 2188 <x:ref>Date</x:ref> = "Date" <x:ref>BWS</x:ref> ":" <x:ref>OWS</x:ref> <x:ref>Date-v</x:ref> 2189 <x:ref>Date-v</x:ref> = <x:ref>HTTP-date</x:ref> 2184 2190 </artwork></figure> 2185 2191 <t> … … 2187 2193 </t> 2188 2194 <figure><artwork type="example"> 2189 2195 Date: Tue, 15 Nov 1994 08:12:31 GMT 2190 2196 </artwork></figure> 2191 2197 <t> … … 2251 2257 <iref primary="true" item="Headers" subitem="Host" x:for-anchor=""/> 2252 2258 <x:anchor-alias value="Host"/> 2253 <t> 2254 The Host request-header field specifies the Internet host and port 2259 <x:anchor-alias value="Host-v"/> 2260 <t> 2261 The request-header field "Host" specifies the Internet host and port 2255 2262 number of the resource being requested, as obtained from the original 2256 2263 URI given by the user or referring resource (generally an HTTP URL, … … 2261 2268 URL of a server for multiple host names on a single IP address. 2262 2269 </t> 2263 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Host"/> 2264 <x:ref>Host</x:ref> = "Host" ":" <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ] ; <xref target="http.url"/> 2270 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Host"/><iref primary="true" item="Grammar" subitem="Host-v"/> 2271 <x:ref>Host</x:ref> = "Host" <x:ref>BWS</x:ref> ":" <x:ref>OWS</x:ref> <x:ref>Host-v</x:ref> 2272 <x:ref>Host-v</x:ref> = <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ] ; <xref target="http.url"/> 2265 2273 </artwork></figure> 2266 2274 <t> … … 2271 2279 </t> 2272 2280 <figure><artwork type="example"> 2273 2274 2281 GET /pub/WWW/ HTTP/1.1 2282 Host: www.example.org 2275 2283 </artwork></figure> 2276 2284 <t> … … 2296 2304 <iref primary="true" item="Headers" subitem="TE" x:for-anchor=""/> 2297 2305 <x:anchor-alias value="TE"/> 2306 <x:anchor-alias value="TE-v"/> 2298 2307 <x:anchor-alias value="t-codings"/> 2299 2308 <t> 2300 The TE request-header fieldindicates what extension transfer-codings2309 The request-header field "TE" indicates what extension transfer-codings 2301 2310 it is willing to accept in the response and whether or not it is 2302 2311 willing to accept trailer fields in a chunked transfer-coding. Its … … 2305 2314 parameters (as described in <xref target="transfer.codings"/>). 2306 2315 </t> 2307 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="TE"/><iref primary="true" item="Grammar" subitem="t-codings"/> 2308 <x:ref>TE</x:ref> = "TE" ":" #( <x:ref>t-codings</x:ref> ) 2316 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="TE"/><iref primary="true" item="Grammar" subitem="TE-v"/><iref primary="true" item="Grammar" subitem="t-codings"/> 2317 <x:ref>TE</x:ref> = "TE" <x:ref>BWS</x:ref> ":" <x:ref>OWS</x:ref> <x:ref>TE-v</x:ref> 2318 <x:ref>TE-v</x:ref> = #<x:ref>t-codings</x:ref> 2309 2319 <x:ref>t-codings</x:ref> = "trailers" / ( <x:ref>transfer-extension</x:ref> [ <x:ref>accept-params</x:ref> ] ) 2310 2320 </artwork></figure> … … 2320 2330 </t> 2321 2331 <figure><artwork type="example"> 2322 2323 2324 2332 TE: deflate 2333 TE: 2334 TE: trailers, deflate;q=0.5 2325 2335 </artwork></figure> 2326 2336 <t> … … 2372 2382 <iref primary="true" item="Headers" subitem="Trailer" x:for-anchor=""/> 2373 2383 <x:anchor-alias value="Trailer"/> 2374 <t> 2375 The Trailer general field value indicates that the given set of 2384 <x:anchor-alias value="Trailer-v"/> 2385 <t> 2386 The general field "Trailer" indicates that the given set of 2376 2387 header fields is present in the trailer of a message encoded with 2377 2388 chunked transfer-coding. 2378 2389 </t> 2379 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Trailer"/> 2380 <x:ref>Trailer</x:ref> = "Trailer" ":" 1#<x:ref>field-name</x:ref> 2390 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Trailer"/><iref primary="true" item="Grammar" subitem="Trailer-v"/> 2391 <x:ref>Trailer</x:ref> = "Trailer" <x:ref>BWS</x:ref> ":" <x:ref>OWS</x:ref> <x:ref>Trailer-v</x:ref> 2392 <x:ref>Trailer-v</x:ref> = 1#<x:ref>field-name</x:ref> 2381 2393 </artwork></figure> 2382 2394 <t> … … 2406 2418 <iref primary="true" item="Headers" subitem="Transfer-Encoding" x:for-anchor=""/> 2407 2419 <x:anchor-alias value="Transfer-Encoding"/> 2408 <t> 2409 The Transfer-Encoding general-header field indicates what (if any) 2420 <x:anchor-alias value="Transfer-Encoding-v"/> 2421 <t> 2422 The general-header "Transfer-Encoding" field indicates what (if any) 2410 2423 type of transformation has been applied to the message body in order 2411 2424 to safely transfer it between the sender and the recipient. This … … 2413 2426 property of the message, not of the entity. 2414 2427 </t> 2415 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Transfer-Encoding"/> 2416 <x:ref>Transfer-Encoding</x:ref> = "Transfer-Encoding" ":" 1#<x:ref>transfer-coding</x:ref> 2428 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Transfer-Encoding"/><iref primary="true" item="Grammar" subitem="Transfer-Encoding-v"/> 2429 <x:ref>Transfer-Encoding</x:ref> = "Transfer-Encoding" <x:ref>BWS</x:ref> ":" <x:ref>OWS</x:ref> <x:ref>Transfer-Encoding-v</x:ref> 2430 <x:ref>Transfer-Encoding-v</x:ref> = 1#<x:ref>transfer-coding</x:ref> 2417 2431 </artwork></figure> 2418 2432 <t> … … 2438 2452 <iref primary="true" item="Headers" subitem="Upgrade" x:for-anchor=""/> 2439 2453 <x:anchor-alias value="Upgrade"/> 2440 <t> 2441 The Upgrade general-header allows the client to specify what 2454 <x:anchor-alias value="Upgrade-v"/> 2455 <t> 2456 The general-header "Upgrade" allows the client to specify what 2442 2457 additional communication protocols it supports and would like to use 2443 2458 if the server finds it appropriate to switch protocols. The server … … 2445 2460 response to indicate which protocol(s) are being switched. 2446 2461 </t> 2447 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Upgrade"/> 2448 <x:ref>Upgrade</x:ref> = "Upgrade" ":" 1#<x:ref>product</x:ref> 2462 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Upgrade"/><iref primary="true" item="Grammar" subitem="Upgrade-v"/> 2463 <x:ref>Upgrade</x:ref> = "Upgrade" <x:ref>BWS</x:ref> ":" <x:ref>OWS</x:ref> <x:ref>Upgrade-v</x:ref> 2464 <x:ref>Upgrade-v</x:ref> = 1#<x:ref>product</x:ref> 2449 2465 </artwork></figure> 2450 2466 <t> … … 2452 2468 </t> 2453 2469 <figure><artwork type="example"> 2454 2470 Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 2455 2471 </artwork></figure> 2456 2472 <t> … … 2507 2523 <x:anchor-alias value="received-protocol"/> 2508 2524 <x:anchor-alias value="Via"/> 2509 <t> 2510 The Via general-header field &MUST; be used by gateways and proxies to 2525 <x:anchor-alias value="Via-v"/> 2526 <t> 2527 The general-header field "Via" &MUST; be used by gateways and proxies to 2511 2528 indicate the intermediate protocols and recipients between the user 2512 2529 agent and the server on requests, and between the origin server and … … 2516 2533 all senders along the request/response chain. 2517 2534 </t> 2518 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Via"/><iref primary="true" item="Grammar" subitem="received-protocol"/><iref primary="true" item="Grammar" subitem="protocol-name"/><iref primary="true" item="Grammar" subitem="protocol-version"/><iref primary="true" item="Grammar" subitem="received-by"/><iref primary="true" item="Grammar" subitem="pseudonym"/> 2519 <x:ref>Via</x:ref> = "Via" ":" 1#( <x:ref>received-protocol</x:ref> <x:ref>RWS</x:ref> <x:ref>received-by</x:ref> [ <x:ref>RWS</x:ref> <x:ref>comment</x:ref> ] ) 2535 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Via"/><iref primary="true" item="Grammar" subitem="Via-v"/><iref primary="true" item="Grammar" subitem="received-protocol"/><iref primary="true" item="Grammar" subitem="protocol-name"/><iref primary="true" item="Grammar" subitem="protocol-version"/><iref primary="true" item="Grammar" subitem="received-by"/><iref primary="true" item="Grammar" subitem="pseudonym"/> 2536 <x:ref>Via</x:ref> = "Via" <x:ref>BWS</x:ref> ":" <x:ref>OWS</x:ref> <x:ref>Via-v</x:ref> 2537 <x:ref>Via-v</x:ref> = 1#( <x:ref>received-protocol</x:ref> <x:ref>RWS</x:ref> <x:ref>received-by</x:ref> [ <x:ref>RWS</x:ref> <x:ref>comment</x:ref> ] ) 2520 2538 <x:ref>received-protocol</x:ref> = [ <x:ref>protocol-name</x:ref> "/" ] <x:ref>protocol-version</x:ref> 2521 2539 <x:ref>protocol-name</x:ref> = <x:ref>token</x:ref> … … 2562 2580 </t> 2563 2581 <figure><artwork type="example"> 2564 2582 Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) 2565 2583 </artwork></figure> 2566 2584 <t> … … 2579 2597 </t> 2580 2598 <figure><artwork type="example"> 2581 2599 Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy 2582 2600 </artwork></figure> 2583 2601 <t> … … 2585 2603 </t> 2586 2604 <figure><artwork type="example"> 2587 2605 Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 2588 2606 </artwork></figure> 2589 2607 <t> … … 4648 4666 them yet. 4649 4667 </t> 4668 <t> 4669 Rewrite header ABNFs to spell out whitespace rules, factor out 4670 value format definitions. 4671 </t> 4650 4672 </list> 4651 4673 </t>
Note: See TracChangeset
for help on using the changeset viewer.