Ignore:
Timestamp:
Dec 21, 2007, 4:30:59 PM (12 years ago)
Author:
fielding@…
Message:

Regenerate HTML after the following changes applied to XML drafts:

Resolve #1: HTTP Version should be case sensitive
Resolve #2: 'unsafe' characters
Resolve #3: Chunk Size Definition
Resolve #4: Message Length
Resolve #5: Via is a MUST
Resolve #6: Fragments allowed in Location
Resolve #8: Media type registrations, by updating to RFC 4288
Resolve #8: Media type registrations, by updating to RFC 4288
Resolve #9: Trailer
Resolve #11: URI includes query
Resolve #12: Invalidation after Update or Delete
Resolve #17: Revise description of the POST method
Resolve #18: Cache validators in 206 responses
Resolve #49: Connection header text
Resolve #14: Clarification regarding quoting of charset values
Resolve #47: inconsistency in date format explanation
Resolve #48: Date reference typo
Resolve #48: remove unnecessary reference to RFC1123

for consistency with draft-lafon

Resolve #16: Remove 'identity' token references
Resolve #15: No close on 1xx responses
(editorial) fix typo of varriant
Resolve #10: Safe Methods vs Redirection
Resolve #45: RFC977 reference
Resolve #42: RFC2606 compliance
Resolve #46: references to RFC1700

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r62 r92  
    612612      </p>
    613613      <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="#RFC977" 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.
    615615      </p>
    616616      <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="intro.requirements" href="#intro.requirements">Requirements</a></h2>
     
    675675      <dl class="empty">
    676676         <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 `varriant'. 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.
    678678         </dd>
    679679      </dl>
     
    809809         failing that, at least reliable indications of failure.
    810810      </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 (&lt;<a href="http://www.iana.org/assignments/port-numbers">http://www.iana.org/assignments/port-numbers</a>&gt;), but other ports can be used. This does not preclude HTTP from being implemented on top of any other protocol on the Internet,
    812812         or on other networks. HTTP only presumes a reliable transport; any protocol that provides such guarantees can be used; the
    813813         mapping of the HTTP/1.1 request and response structures onto the transport data units of the protocol in question is outside
     
    955955         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.
    956956      </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>
    958958      <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.24"></span>       HTTP-Version   = "HTTP" "/" 1*DIGIT "." 1*DIGIT
    959959</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.
     
    10131013         <li>An empty abs_path is equivalent to an abs_path of "/".</li>
    10141014      </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.
    10161016      </p>
    10171017      <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.html
    1019    http://ABC.com/%7Esmith/home.html
    1020    http://ABC.com:/%7esmith/home.html
     1018      <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
    10211021</pre><h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="date.time.formats" href="#date.time.formats">Date/Time Formats</a></h2>
    10221022      <h3 id="rfc.section.3.3.1"><a href="#rfc.section.3.3.1">3.3.1</a>&nbsp;<a id="full.date" href="#full.date">Full Date</a></h3>
    10231023      <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>
    10241024      <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 1036
     1025   Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
    10261026   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&nbsp;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&nbsp;B</a> for further information.
    10281029      </p>
    10291030      <dl class="empty">
     
    10801081      </p>
    10811082      <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&nbsp;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&nbsp;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>).
    10831084      </p>
    10841085      <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>).
     
    11061107    chunk-data     = chunk-size(OCTET)
    11071108    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 chunk
    1109          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.
    11101111      </p>
    11111112      <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
     
    12211222         </li>
    12221223         <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&nbsp;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&nbsp;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&nbsp;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&nbsp;3.4</a>), unless the message is terminated by closing the connection.
    12251225            </p>
    12261226         </li>
     
    12321232         </li>
    12331233         <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.
    12381237            </p>
    12391238            <dl class="empty">
     
    12541253      <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&nbsp;3.4</a>), thus allowing this mechanism to be used for messages when the message length cannot be determined in advance.
    12551254      </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.
    12581256      </p>
    12591257      <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.
     
    12971295      <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&nbsp;3.2</a>) and identifies the resource upon which to apply the request.
    12981296      </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
    13001301</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
    13011302         not apply to a particular resource, but to the server itself, and is only allowed when the method used does not necessarily
     
    13081309         Request-Line would be:
    13091310      </p>
    1310       <div id="rfc.figure.u.32"></div><pre class="text">    GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
     1311      <div id="rfc.figure.u.32"></div><pre class="text">    GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
    13111312</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.
    13121313      </p>
     
    13151316      <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
    13161317         path of the URI <em class="bcp14">MUST</em> be transmitted (see <a href="#general.syntax" title="General Syntax">Section&nbsp;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:
    13181319      </p>
    13191320      <div id="rfc.figure.u.33"></div><pre class="text">    GET /pub/WWW/TheProject.html HTTP/1.1
    1320     Host: www.w3.org
     1321    Host: www.example.org
    13211322</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
    13221323         URI, it <em class="bcp14">MUST</em> be given as "/" (the server root).
     
    15871588</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&nbsp;7.1</a>) after the current request/response is complete.
    15881589      </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
    15921595         in this field, remove and ignore any header field(s) from the message with the same name as the connection-token. This protects
    15931596         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&nbsp;D.2</a>.
     
    16141617      <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a>&nbsp;<a id="header.date" href="#header.date">Date</a></h2>
    16151618      <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&nbsp;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&nbsp;3.3.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format.
    16171620      </p>
    16181621      <div id="rfc.figure.u.41"></div><pre class="inline"><span id="rfc.iref.g.73"></span>    Date  = "Date" ":" HTTP-date
     
    16561659      <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&nbsp;3.2.2</a>
    16571660</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 &lt;http://www.w3.org/pub/WWW/&gt; would properly include:
     1661         URL). For example, a request on the origin server for &lt;http://www.example.org/pub/WWW/&gt; would properly include:
    16591662      </p>
    16601663      <div id="rfc.figure.u.44"></div><pre class="text">    GET /pub/WWW/ HTTP/1.1
    1661     Host: www.w3.org
     1664    Host: www.example.org
    16621665</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
    16631666         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
     
    18001803      </p>
    18011804      <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 origin
    1803          server at www.ics.uci.edu. The request received by www.ics.uci.edu would 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)
    18061809</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.
    18071810      </p>
     
    19351938      <h1 id="rfc.references"><a href="#rfc.section.12" id="rfc.section.12">12.</a> References
    19361939      </h1>
    1937       <table summary="References">                                                                   
     1940      <table summary="References">                                                               
    19381941         <tr>
    19391942            <td class="reference"><b id="ISO-8859">[ISO-8859]</b></td>
     
    19701973         </tr>
    19711974         <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&nbsp;1036, December&nbsp;1987.
    1974             </td>
    1975          </tr>
    1976          <tr>
    19771975            <td class="reference"><b id="RFC1123">[RFC1123]</b></td>
    19781976            <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&nbsp;3, RFC&nbsp;1123, October&nbsp;1989.
     
    19871985            <td class="reference"><b id="RFC1436">[RFC1436]</b></td>
    19881986            <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&nbsp;1436, March&nbsp;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&nbsp;1590, November&nbsp;1996.
    19941987            </td>
    19951988         </tr>
     
    20011994         </tr>
    20021995         <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&nbsp;2, RFC&nbsp;1700, October&nbsp;1994.
    2005             </td>
    2006          </tr>
    2007          <tr>
    20081996            <td class="reference"><b id="RFC1737">[RFC1737]</b></td>
    20091997            <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&nbsp;1737, December&nbsp;1994.
     
    20712059         </tr>
    20722060         <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&nbsp;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&nbsp;13, RFC&nbsp;4288, December&nbsp;2005.
     2068            </td>
     2069         </tr>
     2070         <tr>
    20732071            <td class="reference"><b id="RFC821">[RFC821]</b></td>
    20742072            <td class="top">Postel, J.B., “<a href="http://tools.ietf.org/html/rfc821">Simple Mail Transfer Protocol</a>”, STD&nbsp;10, RFC&nbsp;821, August&nbsp;1982.
     
    20832081            <td class="reference"><b id="RFC959">[RFC959]</b></td>
    20842082            <td class="top">Postel, J. and J. Reynolds, “<a href="http://tools.ietf.org/html/rfc959">File Transfer Protocol</a>”, STD&nbsp;9, RFC&nbsp;959, October&nbsp;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&nbsp;977, February&nbsp;1986.
    20902083            </td>
    20912084         </tr>
     
    21282121         it obeys the MIME restrictions for all "message" types regarding line length and encodings. The application/http type can
    21292122         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="#RFC1590" 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>.
    21312124      </p>
    21322125      <p id="rfc.section.A.p.2"> </p>
     
    25142507                  <li class="indline1">resource&nbsp;&nbsp;<a class="iref" href="#rfc.iref.r.3">1.3</a></li>
    25152508                  <li class="indline1">response&nbsp;&nbsp;<a class="iref" href="#rfc.iref.r.2">1.3</a></li>
    2516                   <li class="indline1"><em>RFC1036</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1123.1">3.3.1</a>, <a class="iref" href="#RFC1123"><b>12</b></a></li>
    25182510                  <li class="indline1"><em>RFC1305</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1305.1">8.3</a>, <a class="iref" href="#RFC1305"><b>12</b></a></li>
    25192511                  <li class="indline1"><em>RFC1436</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a class="iref" href="#RFC1590"><b>12</b></a>, <a class="iref" href="#rfc.xref.RFC1590.1">A</a></li>
    25212512                  <li class="indline1"><em>RFC1630</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1700.1">1.4</a>, <a class="iref" href="#RFC1700"><b>12</b></a></li>
    25232513                  <li class="indline1"><em>RFC1737</em>&nbsp;&nbsp;<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>
    25242514                  <li class="indline1"><em>RFC1738</em>&nbsp;&nbsp;<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>
     
    25372527                  <li class="indline1"><em>RFC2396</em>&nbsp;&nbsp;<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>
    25382528                  <li class="indline1"><em>RFC2616</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a class="iref" href="#RFC4288"><b>12</b></a>, <a class="iref" href="#rfc.xref.RFC4288.1">A</a></li>
    25392531                  <li class="indline1"><em>RFC821</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC821.1">1.1</a>, <a class="iref" href="#RFC821"><b>12</b></a></li>
    25402532                  <li class="indline1"><em>RFC822</em>&nbsp;&nbsp;<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">
     
    25432535                  </li>
    25442536                  <li class="indline1"><em>RFC959</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC977.1">1.1</a>, <a class="iref" href="#RFC977"><b>12</b></a></li>
    25462537               </ul>
    25472538            </li>
Note: See TracChangeset for help on using the changeset viewer.