![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Changeset 92 for draft-ietf-httpbis/latest/p1-messaging.html
- Timestamp:
- Dec 21, 2007, 4:30:59 PM (12 years ago)
- File:
-
- 1 edited
-
draft-ietf-httpbis/latest/p1-messaging.html (modified) (27 diffs)
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r62 r92 612 612 </p> 613 613 <p id="rfc.section.1.1.p.4">HTTP is also used as a generic protocol for communication between user agents and proxies/gateways to other Internet systems, 614 including those supported by the SMTP <a href="#RFC821" id="rfc.xref.RFC821.1"><cite title="Simple Mail Transfer Protocol">[RFC821]</cite></a>, NNTP <a href="#RFC 977" id="rfc.xref.RFC977.1"><cite title="Network News Transfer Protocol">[RFC977]</cite></a>, FTP <a href="#RFC959" id="rfc.xref.RFC959.1"><cite title="File Transfer Protocol">[RFC959]</cite></a>, Gopher <a href="#RFC1436" id="rfc.xref.RFC1436.1"><cite title="The Internet Gopher Protocol (a distributed document search and retrieval protocol)">[RFC1436]</cite></a>, and WAIS <a href="#WAIS" id="rfc.xref.WAIS.1"><cite title="WAIS Interface Protocol Prototype Functional Specification (v1.5)">[WAIS]</cite></a> protocols. In this way, HTTP allows basic hypermedia access to resources available from diverse applications.614 including those supported by the SMTP <a href="#RFC821" id="rfc.xref.RFC821.1"><cite title="Simple Mail Transfer Protocol">[RFC821]</cite></a>, NNTP <a href="#RFC3977" id="rfc.xref.RFC3977.1"><cite title="Network News Transfer Protocol (NNTP)">[RFC3977]</cite></a>, FTP <a href="#RFC959" id="rfc.xref.RFC959.1"><cite title="File Transfer Protocol">[RFC959]</cite></a>, Gopher <a href="#RFC1436" id="rfc.xref.RFC1436.1"><cite title="The Internet Gopher Protocol (a distributed document search and retrieval protocol)">[RFC1436]</cite></a>, and WAIS <a href="#WAIS" id="rfc.xref.WAIS.1"><cite title="WAIS Interface Protocol Prototype Functional Specification (v1.5)">[WAIS]</cite></a> protocols. In this way, HTTP allows basic hypermedia access to resources available from diverse applications. 615 615 </p> 616 616 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="intro.requirements" href="#intro.requirements">Requirements</a></h2> … … 675 675 <dl class="empty"> 676 676 <dd>A resource may have one, or more than one, representation(s) associated with it at any given instant. Each of these representations 677 is termed a `var riant'. Use of the term `variant' does not necessarily imply that the resource is subject to content negotiation.677 is termed a `variant'. Use of the term `variant' does not necessarily imply that the resource is subject to content negotiation. 678 678 </dd> 679 679 </dl> … … 809 809 failing that, at least reliable indications of failure. 810 810 </p> 811 <p id="rfc.section.1.4.p.11">HTTP communication usually takes place over TCP/IP connections. The default port is TCP 80 <a href="#RFC1700" id="rfc.xref.RFC1700.1"><cite title="Assigned Numbers">[RFC1700]</cite></a>, but other ports can be used. This does not preclude HTTP from being implemented on top of any other protocol on the Internet,811 <p id="rfc.section.1.4.p.11">HTTP communication usually takes place over TCP/IP connections. The default port is TCP 80 (<<a href="http://www.iana.org/assignments/port-numbers">http://www.iana.org/assignments/port-numbers</a>>), but other ports can be used. This does not preclude HTTP from being implemented on top of any other protocol on the Internet, 812 812 or on other networks. HTTP only presumes a reliable transport; any protocol that provides such guarantees can be used; the 813 813 mapping of the HTTP/1.1 request and response structures onto the transport data units of the protocol in question is outside … … 955 955 of a message within the protocol is changed. See RFC 2145 <a href="#RFC2145" id="rfc.xref.RFC2145.1"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a> for a fuller explanation. 956 956 </p> 957 <p id="rfc.section.3.1.p.2">The version of an HTTP message is indicated by an HTTP-Version field in the first line of the message. </p>957 <p id="rfc.section.3.1.p.2">The version of an HTTP message is indicated by an HTTP-Version field in the first line of the message. HTTP-Version is case-sensitive.</p> 958 958 <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.24"></span> HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT 959 959 </pre><p id="rfc.section.3.1.p.4">Note that the major and minor numbers <em class="bcp14">MUST</em> be treated as separate integers and that each <em class="bcp14">MAY</em> be incremented higher than a single digit. Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is lower than HTTP/12.3. … … 1013 1013 <li>An empty abs_path is equivalent to an abs_path of "/".</li> 1014 1014 </ul> 1015 <p id="rfc.section.3.2.3.p.2">Characters other than those in the "reserved" and "unsafe" sets(see RFC 2396 <a href="#RFC2396" id="rfc.xref.RFC2396.2"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>) are equivalent to their ""%" HEX HEX" encoding.1015 <p id="rfc.section.3.2.3.p.2">Characters other than those in the "reserved" set (see RFC 2396 <a href="#RFC2396" id="rfc.xref.RFC2396.2"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>) are equivalent to their ""%" HEX HEX" encoding. 1016 1016 </p> 1017 1017 <p id="rfc.section.3.2.3.p.3">For example, the following three URIs are equivalent:</p> 1018 <div id="rfc.figure.u.15"></div><pre class="text"> http:// abc.com:80/~smith/home.html1019 http:// ABC.com/%7Esmith/home.html1020 http:// ABC.com:/%7esmith/home.html1018 <div id="rfc.figure.u.15"></div><pre class="text"> http://example.com:80/~smith/home.html 1019 http://EXAMPLE.com/%7Esmith/home.html 1020 http://EXAMPLE.com:/%7esmith/home.html 1021 1021 </pre><h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> <a id="date.time.formats" href="#date.time.formats">Date/Time Formats</a></h2> 1022 1022 <h3 id="rfc.section.3.3.1"><a href="#rfc.section.3.3.1">3.3.1</a> <a id="full.date" href="#full.date">Full Date</a></h3> 1023 1023 <p id="rfc.section.3.3.1.p.1">HTTP applications have historically allowed three different formats for the representation of date/time stamps:</p> 1024 1024 <div id="rfc.figure.u.16"></div><pre class="text"> Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123 1025 Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 10361025 Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format 1026 1026 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format 1027 </pre><p id="rfc.section.3.3.1.p.3">The first format is preferred as an Internet standard and represents a fixed-length subset of that defined by RFC 1123 <a href="#RFC1123" id="rfc.xref.RFC1123.1"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a> (an update to RFC 822 <a href="#RFC822" id="rfc.xref.RFC822.3"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a>). The second format is in common use, but is based on the obsolete RFC 850 <a href="#RFC1036" id="rfc.xref.RFC1036.1"><cite title="Standard for interchange of USENET messages">[RFC1036]</cite></a> date format and lacks a four-digit year. HTTP/1.1 clients and servers that parse the date value <em class="bcp14">MUST</em> accept all three formats (for compatibility with HTTP/1.0), though they <em class="bcp14">MUST</em> only generate the RFC 1123 format for representing HTTP-date values in header fields. See <a href="#tolerant.applications" title="Tolerant Applications">Appendix B</a> for further information. 1027 </pre><p id="rfc.section.3.3.1.p.3">The first format is preferred as an Internet standard and represents a fixed-length subset of that defined by RFC 1123 <a href="#RFC1123" id="rfc.xref.RFC1123.1"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a> (an update to RFC 822 <a href="#RFC822" id="rfc.xref.RFC822.3"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a>). The other formats are described here only for compatibility with obsolete implementations. HTTP/1.1 clients and servers 1028 that parse the date value <em class="bcp14">MUST</em> accept all three formats (for compatibility with HTTP/1.0), though they <em class="bcp14">MUST</em> only generate the RFC 1123 format for representing HTTP-date values in header fields. See <a href="#tolerant.applications" title="Tolerant Applications">Appendix B</a> for further information. 1028 1029 </p> 1029 1030 <dl class="empty"> … … 1080 1081 </p> 1081 1082 <p id="rfc.section.3.4.p.8">The Internet Assigned Numbers Authority (IANA) acts as a registry for transfer-coding value tokens. Initially, the registry 1082 contains the following tokens: "chunked" (<a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">Section 3.4.1</a>), " identity" (section 3.6.2), "gzip" (<a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), "compress" (<a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), and "deflate" (<a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>).1083 contains the following tokens: "chunked" (<a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">Section 3.4.1</a>), "gzip" (<a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), "compress" (<a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), and "deflate" (<a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). 1083 1084 </p> 1084 1085 <p id="rfc.section.3.4.p.9">New transfer-coding value tokens <em class="bcp14">SHOULD</em> be registered in the same way as new content-coding value tokens (<a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). … … 1106 1107 chunk-data = chunk-size(OCTET) 1107 1108 trailer = *(entity-header CRLF) 1108 </pre><p id="rfc.section.3.4.1.p.3">The chunk-size field is a string of hex digits indicating the size of the chunk . The chunked encoding is ended by any chunk1109 whose size is zero, followed by the trailer, which is terminated by an empty line.1109 </pre><p id="rfc.section.3.4.1.p.3">The chunk-size field is a string of hex digits indicating the size of the chunk-data in octets. The chunked encoding is ended 1110 by any chunk whose size is zero, followed by the trailer, which is terminated by an empty line. 1110 1111 </p> 1111 1112 <p id="rfc.section.3.4.1.p.4">The trailer allows the sender to include additional HTTP header fields at the end of the message. The Trailer header field … … 1221 1222 </li> 1222 1223 <li> 1223 <p>If a Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.3" title="Transfer-Encoding">Section 8.7</a>) is present and has any value other than "identity", then the transfer-length is defined by use of the "chunked" transfer-coding 1224 (<a href="#transfer.codings" title="Transfer Codings">Section 3.4</a>), unless the message is terminated by closing the connection. 1224 <p>If a Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.3" title="Transfer-Encoding">Section 8.7</a>) is present, then the transfer-length is defined by use of the "chunked" transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section 3.4</a>), unless the message is terminated by closing the connection. 1225 1225 </p> 1226 1226 </li> … … 1232 1232 </li> 1233 1233 <li> 1234 <p>If the message uses the media type "multipart/byteranges", and the ransfer-length is not otherwise specified, then this self-elimiting 1235 media type defines the transfer-length. This media type UST NOT be used unless the sender knows that the recipient can arse 1236 it; the presence in a request of a Range header with ultiple byte-range specifiers from a 1.1 client implies that the lient 1237 can parse multipart/byteranges responses. 1234 <p>If the message uses the media type "multipart/byteranges", and the transfer-length is not otherwise specified, then this self-delimiting 1235 media type defines the transfer-length. This media type <em class="bcp14">MUST NOT</em> be used unless the sender knows that the recipient can parse it; the presence in a request of a Range header with multiple 1236 byte-range specifiers from a 1.1 client implies that the client can parse multipart/byteranges responses. 1238 1237 </p> 1239 1238 <dl class="empty"> … … 1254 1253 <p id="rfc.section.4.4.p.4">All HTTP/1.1 applications that receive entities <em class="bcp14">MUST</em> accept the "chunked" transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section 3.4</a>), thus allowing this mechanism to be used for messages when the message length cannot be determined in advance. 1255 1254 </p> 1256 <p id="rfc.section.4.4.p.5">Messages <em class="bcp14">MUST NOT</em> include both a Content-Length header field and a non-identity transfer-coding. If the message does include a non-identity 1257 transfer-coding, the Content-Length <em class="bcp14">MUST</em> be ignored. 1255 <p id="rfc.section.4.4.p.5">Messages <em class="bcp14">MUST NOT</em> include both a Content-Length header field and a transfer-coding. If the message does include a transfer-coding, the Content-Length <em class="bcp14">MUST</em> be ignored. 1258 1256 </p> 1259 1257 <p id="rfc.section.4.4.p.6">When a Content-Length is given in a message where a message-body is allowed, its field value <em class="bcp14">MUST</em> exactly match the number of OCTETs in the message-body. HTTP/1.1 user agents <em class="bcp14">MUST</em> notify the user when an invalid length is received and detected. … … 1297 1295 <p id="rfc.section.5.1.2.p.1">The Request-URI is a Uniform Resource Identifier (<a href="#uri" title="Uniform Resource Identifiers">Section 3.2</a>) and identifies the resource upon which to apply the request. 1298 1296 </p> 1299 <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.64"></span> Request-URI = "*" | absoluteURI | abs_path | authority 1297 <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.64"></span> Request-URI = "*" 1298 | absoluteURI 1299 | ( abs_path [ "?" query ] ) 1300 | authority 1300 1301 </pre><p id="rfc.section.5.1.2.p.3">The four options for Request-URI are dependent on the nature of the request. The asterisk "*" means that the request does 1301 1302 not apply to a particular resource, but to the server itself, and is only allowed when the method used does not necessarily … … 1308 1309 Request-Line would be: 1309 1310 </p> 1310 <div id="rfc.figure.u.32"></div><pre class="text"> GET http://www. w3.org/pub/WWW/TheProject.html HTTP/1.11311 <div id="rfc.figure.u.32"></div><pre class="text"> GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 1311 1312 </pre><p id="rfc.section.5.1.2.p.7">To allow for transition to absoluteURIs in all requests in future versions of HTTP, all HTTP/1.1 servers <em class="bcp14">MUST</em> accept the absoluteURI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies. 1312 1313 </p> … … 1315 1316 <p id="rfc.section.5.1.2.p.9">The most common form of Request-URI is that used to identify a resource on an origin server or gateway. In this case the absolute 1316 1317 path of the URI <em class="bcp14">MUST</em> be transmitted (see <a href="#general.syntax" title="General Syntax">Section 3.2.1</a>, abs_path) as the Request-URI, and the network location of the URI (authority) <em class="bcp14">MUST</em> be transmitted in a Host header field. For example, a client wishing to retrieve the resource above directly from the origin 1317 server would create a TCP connection to port 80 of the host "www. w3.org" and send the lines:1318 server would create a TCP connection to port 80 of the host "www.example.org" and send the lines: 1318 1319 </p> 1319 1320 <div id="rfc.figure.u.33"></div><pre class="text"> GET /pub/WWW/TheProject.html HTTP/1.1 1320 Host: www. w3.org1321 Host: www.example.org 1321 1322 </pre><p id="rfc.section.5.1.2.p.11">followed by the remainder of the Request. Note that the absolute path cannot be empty; if none is present in the original 1322 1323 URI, it <em class="bcp14">MUST</em> be given as "/" (the server root). … … 1587 1588 </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. 1588 1589 </p> 1589 <p id="rfc.section.8.1.p.9">HTTP/1.1 applications that do not support persistent connections <em class="bcp14">MUST</em> include the "close" connection option in every message. 1590 </p> 1591 <p id="rfc.section.8.1.p.10">A system receiving an HTTP/1.0 (or lower-version) message that includes a Connection header MUST, for each connection-token 1590 <p id="rfc.section.8.1.p.9">An HTTP/1.1 client that does not support persistent connections <em class="bcp14">MUST</em> include the "close" connection option in every request message. 1591 </p> 1592 <p id="rfc.section.8.1.p.10">An HTTP/1.1 server that does not support persistent connections <em class="bcp14">MUST</em> include the "close" connection option in every response message that does not have a 1xx (informational) status code. 1593 </p> 1594 <p id="rfc.section.8.1.p.11">A system receiving an HTTP/1.0 (or lower-version) message that includes a Connection header MUST, for each connection-token 1592 1595 in this field, remove and ignore any header field(s) from the message with the same name as the connection-token. This protects 1593 1596 against mistaken forwarding of such header fields by pre-HTTP/1.1 proxies. See <a href="#compatibility.with.http.1.0.persistent.connections" title="Compatibility with HTTP/1.0 Persistent Connections">Appendix D.2</a>. … … 1614 1617 <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> 1615 1618 <p id="rfc.section.8.3.p.1">The Date general-header field represents the date and time at which the message was originated, having the same semantics 1616 as orig-date in RFC 822. 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 RFC 1123 <a href="#RFC1123" id="rfc.xref.RFC1123.2"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a>-date format.1619 as orig-date in RFC 822. 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. 1617 1620 </p> 1618 1621 <div id="rfc.figure.u.41"></div><pre class="inline"><span id="rfc.iref.g.73"></span> Date = "Date" ":" HTTP-date … … 1656 1659 <div id="rfc.figure.u.43"></div><pre class="inline"><span id="rfc.iref.g.74"></span> Host = "Host" ":" host [ ":" port ] ; <a href="#http.url" title="http URL">Section 3.2.2</a> 1657 1660 </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 1658 URL). For example, a request on the origin server for <http://www. w3.org/pub/WWW/> would properly include:1661 URL). For example, a request on the origin server for <http://www.example.org/pub/WWW/> would properly include: 1659 1662 </p> 1660 1663 <div id="rfc.figure.u.44"></div><pre class="text"> GET /pub/WWW/ HTTP/1.1 1661 Host: www. w3.org1664 Host: www.example.org 1662 1665 </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 1663 1666 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 … … 1800 1803 </p> 1801 1804 <p id="rfc.section.8.9.p.7">For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses 1802 HTTP/1.1 to forward the request to a public proxy at nowhere.com, which completes the request by forwarding it to the origin1803 server at www. ics.uci.edu. The request received by www.ics.uci.eduwould then have the following Via header field:1804 </p> 1805 <div id="rfc.figure.u.53"></div><pre class="text"> Via: 1.0 fred, 1.1 nowhere.com(Apache/1.1)1805 HTTP/1.1 to forward the request to a public proxy at p.example.net, which completes the request by forwarding it to the origin 1806 server at www.example.com. The request received by www.example.com would then have the following Via header field: 1807 </p> 1808 <div id="rfc.figure.u.53"></div><pre class="text"> Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) 1806 1809 </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. 1807 1810 </p> … … 1935 1938 <h1 id="rfc.references"><a href="#rfc.section.12" id="rfc.section.12">12.</a> References 1936 1939 </h1> 1937 <table summary="References"> 1940 <table summary="References"> 1938 1941 <tr> 1939 1942 <td class="reference"><b id="ISO-8859">[ISO-8859]</b></td> … … 1970 1973 </tr> 1971 1974 <tr> 1972 <td class="reference"><b id="RFC1036">[RFC1036]</b></td>1973 <td class="top">Horton, M. and R. Adams, “<a href="http://tools.ietf.org/html/rfc1036">Standard for interchange of USENET messages</a>”, RFC 1036, December 1987.1974 </td>1975 </tr>1976 <tr>1977 1975 <td class="reference"><b id="RFC1123">[RFC1123]</b></td> 1978 1976 <td class="top"><a title="University of Southern California (USC), Information Sciences Institute">Braden, R.</a>, “<a href="http://tools.ietf.org/html/rfc1123">Requirements for Internet Hosts - Application and Support</a>”, STD 3, RFC 1123, October 1989. … … 1987 1985 <td class="reference"><b id="RFC1436">[RFC1436]</b></td> 1988 1986 <td class="top"><a title="University of Minnesota, Computer and Information Services">Anklesaria, F.</a>, <a title="University of Minnesota, Computer and Information Services">McCahill, M.</a>, <a title="University of Minnesota, Computer and Information Services">Lindner, P.</a>, <a title="University of Minnesota, Computer and Information Services">Johnson, D.</a>, <a title="University of Minnesota, Computer and Information Services">Torrey, D.</a>, and <a title="University of Minnesota, Computer and Information Services">B. Alberti</a>, “<a href="http://tools.ietf.org/html/rfc1436">The Internet Gopher Protocol (a distributed document search and retrieval protocol)</a>”, RFC 1436, March 1993. 1989 </td>1990 </tr>1991 <tr>1992 <td class="reference"><b id="RFC1590">[RFC1590]</b></td>1993 <td class="top"><a title="USC/Information Sciences Institute">Postel, J.</a>, “<a href="http://tools.ietf.org/html/rfc1590">Media Type Registration Procedure</a>”, RFC 1590, November 1996.1994 1987 </td> 1995 1988 </tr> … … 2001 1994 </tr> 2002 1995 <tr> 2003 <td class="reference"><b id="RFC1700">[RFC1700]</b></td>2004 <td class="top"><a title="USC/Information Sciences Institute">Reynolds, J.</a> and <a title="USC/Information Sciences Institute">J. Postel</a>, “<a href="http://tools.ietf.org/html/rfc1700">Assigned Numbers</a>”, STD 2, RFC 1700, October 1994.2005 </td>2006 </tr>2007 <tr>2008 1996 <td class="reference"><b id="RFC1737">[RFC1737]</b></td> 2009 1997 <td class="top"><a title="Xerox Palo Alto Research Center">Masinter, L.</a> and <a title="MIT Laboratory for Computer Science">K. Sollins</a>, “<a href="http://tools.ietf.org/html/rfc1737">Functional Requirements for Uniform Resource Names</a>”, RFC 1737, December 1994. … … 2071 2059 </tr> 2072 2060 <tr> 2061 <td class="reference"><b id="RFC3977">[RFC3977]</b></td> 2062 <td class="top"><a title="THUS plc">Feather, C.</a>, “Network News Transfer Protocol (NNTP)”, October 2006. 2063 </td> 2064 </tr> 2065 <tr> 2066 <td class="reference"><b id="RFC4288">[RFC4288]</b></td> 2067 <td class="top"><a title="Sun Microsystems">Freed, N.</a> and <a>J. Klensin</a>, “<a href="http://tools.ietf.org/html/rfc4288">Media Type Specifications and Registration Procedures</a>”, BCP 13, RFC 4288, December 2005. 2068 </td> 2069 </tr> 2070 <tr> 2073 2071 <td class="reference"><b id="RFC821">[RFC821]</b></td> 2074 2072 <td class="top">Postel, J.B., “<a href="http://tools.ietf.org/html/rfc821">Simple Mail Transfer Protocol</a>”, STD 10, RFC 821, August 1982. … … 2083 2081 <td class="reference"><b id="RFC959">[RFC959]</b></td> 2084 2082 <td class="top">Postel, J. and J. Reynolds, “<a href="http://tools.ietf.org/html/rfc959">File Transfer Protocol</a>”, STD 9, RFC 959, October 1985. 2085 </td>2086 </tr>2087 <tr>2088 <td class="reference"><b id="RFC977">[RFC977]</b></td>2089 <td class="top">Kantor, B. and P. Lapsley, “<a href="http://tools.ietf.org/html/rfc977">Network News Transfer Protocol</a>”, RFC 977, February 1986.2090 2083 </td> 2091 2084 </tr> … … 2128 2121 it obeys the MIME restrictions for all "message" types regarding line length and encodings. The application/http type can 2129 2122 be used to enclose a pipeline of one or more HTTP request or response messages (not intermixed). The following is to be registered 2130 with IANA <a href="#RFC 1590" id="rfc.xref.RFC1590.1"><cite title="Media Type Registration Procedure">[RFC1590]</cite></a>.2123 with IANA <a href="#RFC4288" id="rfc.xref.RFC4288.1"><cite title="Media Type Specifications and Registration Procedures">[RFC4288]</cite></a>. 2131 2124 </p> 2132 2125 <p id="rfc.section.A.p.2"> </p> … … 2514 2507 <li class="indline1">resource <a class="iref" href="#rfc.iref.r.3">1.3</a></li> 2515 2508 <li class="indline1">response <a class="iref" href="#rfc.iref.r.2">1.3</a></li> 2516 <li class="indline1"><em>RFC1036</em> <a class="iref" href="#rfc.xref.RFC1036.1">3.3.1</a>, <a class="iref" href="#RFC1036"><b>12</b></a></li> 2517 <li class="indline1"><em>RFC1123</em> <a class="iref" href="#rfc.xref.RFC1123.1">3.3.1</a>, <a class="iref" href="#rfc.xref.RFC1123.2">8.3</a>, <a class="iref" href="#RFC1123"><b>12</b></a></li> 2509 <li class="indline1"><em>RFC1123</em> <a class="iref" href="#rfc.xref.RFC1123.1">3.3.1</a>, <a class="iref" href="#RFC1123"><b>12</b></a></li> 2518 2510 <li class="indline1"><em>RFC1305</em> <a class="iref" href="#rfc.xref.RFC1305.1">8.3</a>, <a class="iref" href="#RFC1305"><b>12</b></a></li> 2519 2511 <li class="indline1"><em>RFC1436</em> <a class="iref" href="#rfc.xref.RFC1436.1">1.1</a>, <a class="iref" href="#RFC1436"><b>12</b></a></li> 2520 <li class="indline1"><em>RFC1590</em> <a class="iref" href="#RFC1590"><b>12</b></a>, <a class="iref" href="#rfc.xref.RFC1590.1">A</a></li>2521 2512 <li class="indline1"><em>RFC1630</em> <a class="iref" href="#rfc.xref.RFC1630.1">1.1</a>, <a class="iref" href="#rfc.xref.RFC1630.2">3.2</a>, <a class="iref" href="#RFC1630"><b>12</b></a></li> 2522 <li class="indline1"><em>RFC1700</em> <a class="iref" href="#rfc.xref.RFC1700.1">1.4</a>, <a class="iref" href="#RFC1700"><b>12</b></a></li>2523 2513 <li class="indline1"><em>RFC1737</em> <a class="iref" href="#rfc.xref.RFC1737.1">1.1</a>, <a class="iref" href="#rfc.xref.RFC1737.2">3.2</a>, <a class="iref" href="#RFC1737"><b>12</b></a></li> 2524 2514 <li class="indline1"><em>RFC1738</em> <a class="iref" href="#rfc.xref.RFC1738.1">1.1</a>, <a class="iref" href="#rfc.xref.RFC1738.2">3.2</a>, <a class="iref" href="#rfc.xref.RFC1738.3">3.2.1</a>, <a class="iref" href="#RFC1738"><b>12</b></a></li> … … 2537 2527 <li class="indline1"><em>RFC2396</em> <a class="iref" href="#rfc.xref.RFC2396.1">3.2.1</a>, <a class="iref" href="#rfc.xref.RFC2396.2">3.2.3</a>, <a class="iref" href="#rfc.xref.RFC2396.3">5.1.2</a>, <a class="iref" href="#RFC2396"><b>12</b></a></li> 2538 2528 <li class="indline1"><em>RFC2616</em> <a class="iref" href="#rfc.xref.RFC2616.1">§</a>, <a class="iref" href="#rfc.xref.RFC2616.2">1</a>, <a class="iref" href="#RFC2616"><b>12</b></a></li> 2529 <li class="indline1"><em>RFC3977</em> <a class="iref" href="#rfc.xref.RFC3977.1">1.1</a>, <a class="iref" href="#RFC3977"><b>12</b></a></li> 2530 <li class="indline1"><em>RFC4288</em> <a class="iref" href="#RFC4288"><b>12</b></a>, <a class="iref" href="#rfc.xref.RFC4288.1">A</a></li> 2539 2531 <li class="indline1"><em>RFC821</em> <a class="iref" href="#rfc.xref.RFC821.1">1.1</a>, <a class="iref" href="#RFC821"><b>12</b></a></li> 2540 2532 <li class="indline1"><em>RFC822</em> <a class="iref" href="#rfc.xref.RFC822.1">1.1</a>, <a class="iref" href="#rfc.xref.RFC822.2">2.1</a>, <a class="iref" href="#rfc.xref.RFC822.3">3.3.1</a>, <a class="iref" href="#rfc.xref.RFC822.4">4.1</a>, <a class="iref" href="#rfc.xref.RFC822.5">4.2</a>, <a class="iref" href="#rfc.xref.RFC822.6">4.2</a>, <a class="iref" href="#rfc.xref.RFC822.7">8.9</a>, <a class="iref" href="#rfc.xref.RFC822.8">11</a>, <a class="iref" href="#RFC822"><b>12</b></a><ul class="ind"> … … 2543 2535 </li> 2544 2536 <li class="indline1"><em>RFC959</em> <a class="iref" href="#rfc.xref.RFC959.1">1.1</a>, <a class="iref" href="#RFC959"><b>12</b></a></li> 2545 <li class="indline1"><em>RFC977</em> <a class="iref" href="#rfc.xref.RFC977.1">1.1</a>, <a class="iref" href="#RFC977"><b>12</b></a></li>2546 2537 </ul> 2547 2538 </li>
Note: See TracChangeset
for help on using the changeset viewer.
