![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Changeset 92 for draft-ietf-httpbis/latest
- Timestamp:
- 22/12/07 00:30:59 (14 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 5 edited
-
p1-messaging.html (modified) (27 diffs)
-
p2-semantics.html (modified) (9 diffs)
-
p3-payload.html (modified) (9 diffs)
-
p5-range.html (modified) (3 diffs)
-
p6-cache.html (modified) (2 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> -
draft-ietf-httpbis/latest/p2-semantics.html
r62 r92 825 825 <div id="rfc.iref.m.4"></div> 826 826 <h2 id="rfc.section.8.5"><a href="#rfc.section.8.5">8.5</a> <a id="POST" href="#POST">POST</a></h2> 827 <p id="rfc.section.8.5.p.1">The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of828 the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the following829 f unctions:827 <p id="rfc.section.8.5.p.1">The POST method is used to request that the origin server accept the entity enclosed in the request as data to be processed 828 by the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the 829 following functions: 830 830 </p> 831 831 <ul> … … 835 835 <li>Extending a database through an append operation.</li> 836 836 </ul> 837 <p id="rfc.section.8.5.p.2">The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI. 838 The posted entity is subordinate to that URI in the same way that a file is subordinate to a directory containing it, a news 839 article is subordinate to a newsgroup to which it is posted, or a record is subordinate to a database. 840 </p> 837 <p id="rfc.section.8.5.p.2">The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI.</p> 841 838 <p id="rfc.section.8.5.p.3">The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 842 839 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity … … 1051 1048 <p id="rfc.section.9.3.2.p.2">The new permanent URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the entity of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s). 1052 1049 </p> 1053 <p id="rfc.section.9.3.2.p.3">If the 301 status code is received in response to a request other than GET or HEAD, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which1050 <p id="rfc.section.9.3.2.p.3">If the 301 status code is received in response to a request method that is known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section 8.1.1</a>, then the request MAY be automatically redirected by the user agent without confirmation. Otherwise, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which 1054 1051 the request was issued. 1055 1052 </p> … … 1068 1065 <p id="rfc.section.9.3.3.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the entity of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s). 1069 1066 </p> 1070 <p id="rfc.section.9.3.3.p.3">If the 302 status code is received in response to a request other than GET or HEAD, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which1067 <p id="rfc.section.9.3.3.p.3">If the 302 status code is received in response to a request method that is known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section 8.1.1</a>, then the request MAY be automatically redirected by the user agent without confirmation. Otherwise, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which 1071 1068 the request was issued. 1072 1069 </p> … … 1122 1119 the 307 status. Therefore, the note <em class="bcp14">SHOULD</em> contain the information necessary for a user to repeat the original request on the new URI. 1123 1120 </p> 1124 <p id="rfc.section.9.3.8.p.3">If the 307 status code is received in response to a request other than GET or HEAD, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which1121 <p id="rfc.section.9.3.8.p.3">If the 307 status code is received in response to a request method that is known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section 8.1.1</a>, then the request MAY be automatically redirected by the user agent without confirmation. Otherwise, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which 1125 1122 the request was issued. 1126 1123 </p> … … 1371 1368 <div id="rfc.figure.u.10"></div><pre class="inline"><span id="rfc.iref.g.16"></span> From = "From" ":" mailbox 1372 1369 </pre><p id="rfc.section.10.3.p.3">An example is:</p> 1373 <div id="rfc.figure.u.11"></div><pre class="text"> From: webmaster@ w3.org1370 <div id="rfc.figure.u.11"></div><pre class="text"> From: webmaster@example.org 1374 1371 </pre><p id="rfc.section.10.3.p.5">This header field <em class="bcp14">MAY</em> be used for logging purposes and as a means for identifying the source of invalid or unwanted requests. It <em class="bcp14">SHOULD NOT</em> be used as an insecure form of access protection. The interpretation of this field is that the request is being performed 1375 1372 on behalf of the person given, who accepts responsibility for the method performed. In particular, robot agents <em class="bcp14">SHOULD</em> include this header so that the person responsible for running the robot can be contacted if problems occur on the receiving … … 1391 1388 URI. 1392 1389 </p> 1393 <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.17"></span> Location = "Location" ":" absoluteURI 1390 <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.17"></span> Location = "Location" ":" absoluteURI [ "#" fragment ] 1394 1391 </pre><p id="rfc.section.10.4.p.3">An example is:</p> 1395 <div id="rfc.figure.u.13"></div><pre class="text"> Location: http://www. w3.org/pub/WWW/People.html1392 <div id="rfc.figure.u.13"></div><pre class="text"> Location: http://www.example.org/pub/WWW/People.html 1396 1393 </pre><p id="rfc.section.10.4.p.5"> </p> 1397 1394 <dl class="empty"> … … 1423 1420 <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.19"></span> Referer = "Referer" ":" ( absoluteURI | relativeURI ) 1424 1421 </pre><p id="rfc.section.10.6.p.3">Example:</p> 1425 <div id="rfc.figure.u.16"></div><pre class="text"> Referer: http://www. w3.org/hypertext/DataSources/Overview.html1422 <div id="rfc.figure.u.16"></div><pre class="text"> Referer: http://www.example.org/hypertext/Overview.html 1426 1423 </pre><p id="rfc.section.10.6.p.5">If the field value is a relative URI, it <em class="bcp14">SHOULD</em> be interpreted relative to the Request-URI. The URI <em class="bcp14">MUST NOT</em> include a fragment. See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URI's">Section 12.2</a> for security considerations. 1427 1424 </p> … … 1449 1446 </pre><p id="rfc.section.10.8.p.3">Example:</p> 1450 1447 <div id="rfc.figure.u.20"></div><pre class="text"> Server: CERN/3.0 libwww/2.17 1451 </pre><p id="rfc.section.10.8.p.5">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server response-header. Instead, it <em class="bcp14"> SHOULD</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 8.9</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).1448 </pre><p id="rfc.section.10.8.p.5">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server response-header. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 8.9</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 1452 1449 </p> 1453 1450 <dl class="empty"> -
draft-ietf-httpbis/latest/p3-payload.html
r62 r92 558 558 </dl> 559 559 <p id="rfc.section.2.1.p.4">HTTP character sets are identified by case-insensitive tokens. The complete set of tokens is defined by the IANA Character 560 Set registry <a href="#RFC1700" id="rfc.xref.RFC1700.1"><cite title="Assigned Numbers">[RFC1700]</cite></a>.560 Set registry (<<a href="http://www.iana.org/assignments/character-sets">http://www.iana.org/assignments/character-sets</a>>). 561 561 </p> 562 562 <div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span> charset = token 563 563 </pre><p id="rfc.section.2.1.p.6">Although HTTP allows an arbitrary token to be used as a charset value, any token that has a predefined value within the IANA 564 Character Set registry <a href="#RFC1700" id="rfc.xref.RFC1700.2"><cite title="Assigned Numbers">[RFC1700]</cite></a> <em class="bcp14">MUST</em> represent the character set defined by that registry. Applications <em class="bcp14">SHOULD</em> limit their use of character sets to those defined by the IANA registry. 565 </p> 566 <p id="rfc.section.2.1.p.7">Implementors should be aware of IETF character set requirements <a href="#RFC2279" id="rfc.xref.RFC2279.1"><cite title="UTF-8, a transformation format of ISO 10646">[RFC2279]</cite></a> <a href="#RFC2277" id="rfc.xref.RFC2277.1"><cite title="IETF Policy on Character Sets and Languages">[RFC2277]</cite></a>. 564 Character Set registry <em class="bcp14">MUST</em> represent the character set defined by that registry. Applications <em class="bcp14">SHOULD</em> limit their use of character sets to those defined by the IANA registry. 565 </p> 566 <p id="rfc.section.2.1.p.7">HTTP uses charset in two contexts: within an Accept-Charset request header (in which the charset value is an unquoted token) 567 and as the value of a parameter in a Content-type header (within a request or response), in which case the parameter value 568 of the charset parameter may be quoted. 569 </p> 570 <p id="rfc.section.2.1.p.8">Implementors should be aware of IETF character set requirements <a href="#RFC2279" id="rfc.xref.RFC2279.1"><cite title="UTF-8, a transformation format of ISO 10646">[RFC2279]</cite></a> <a href="#RFC2277" id="rfc.xref.RFC2277.1"><cite title="IETF Policy on Character Sets and Languages">[RFC2277]</cite></a>. 567 571 </p> 568 572 <h3 id="rfc.section.2.1.1"><a href="#rfc.section.2.1.1">2.1.1</a> <a id="missing.charset" href="#missing.charset">Missing Charset</a></h3> … … 621 625 </p> 622 626 <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a> <a id="media.types" href="#media.types">Media Types</a></h2> 623 <p id="rfc.section.2.3.p.1">HTTP uses Internet Media Types <a href="#RFC 1590" id="rfc.xref.RFC1590.1"><cite title="Media Type Registration Procedure">[RFC1590]</cite></a> in the Content-Type (<a href="#header.content-type" id="rfc.xref.header.content-type.1" title="Content-Type">Section 5.9</a>) and Accept (<a href="#header.accept" id="rfc.xref.header.accept.1" title="Accept">Section 5.1</a>) header fields in order to provide open and extensible data typing and type negotiation.627 <p id="rfc.section.2.3.p.1">HTTP uses Internet Media Types <a href="#RFC4288" id="rfc.xref.RFC4288.1"><cite title="Media Type Specifications and Registration Procedures">[RFC4288]</cite></a> in the Content-Type (<a href="#header.content-type" id="rfc.xref.header.content-type.1" title="Content-Type">Section 5.9</a>) and Accept (<a href="#header.accept" id="rfc.xref.header.accept.1" title="Accept">Section 5.1</a>) header fields in order to provide open and extensible data typing and type negotiation. 624 628 </p> 625 629 <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span> media-type = type "/" subtype *( ";" parameter ) … … 638 642 implementations <em class="bcp14">SHOULD</em> only use media type parameters when they are required by that type/subtype definition. 639 643 </p> 640 <p id="rfc.section.2.3.p.7">Media-type values are registered with the Internet Assigned Number Authority (IANA <a href="#RFC1700" id="rfc.xref.RFC1700.3"><cite title="Assigned Numbers">[RFC1700]</cite></a>). The media type registration process is outlined in RFC 1590 <a href="#RFC1590" id="rfc.xref.RFC1590.2"><cite title="Media Type Registration Procedure">[RFC1590]</cite></a>. Use of non-registered media types is discouraged. 644 <p id="rfc.section.2.3.p.7">Media-type values are registered with the Internet Assigned Number Authority (IANA). The media type registration process is 645 outlined in RFC 4288 <a href="#RFC4288" id="rfc.xref.RFC4288.2"><cite title="Media Type Specifications and Registration Procedures">[RFC4288]</cite></a>. Use of non-registered media types is discouraged. 641 646 </p> 642 647 <h3 id="rfc.section.2.3.1"><a href="#rfc.section.2.3.1">2.3.1</a> <a id="canonicalization.and.text.defaults" href="#canonicalization.and.text.defaults">Canonicalization and Text Defaults</a></h3> … … 1163 1168 <h1 id="rfc.references"><a href="#rfc.section.9" id="rfc.section.9">9.</a> References 1164 1169 </h1> 1165 <table summary="References"> 1170 <table summary="References"> 1166 1171 <tr> 1167 1172 <td class="reference"><b id="Part1">[Part1]</b></td> … … 1190 1195 </tr> 1191 1196 <tr> 1192 <td class="reference"><b id="RFC1590">[RFC1590]</b></td>1193 <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.1194 </td>1195 </tr>1196 <tr>1197 <td class="reference"><b id="RFC1700">[RFC1700]</b></td>1198 <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.1199 </td>1200 </tr>1201 <tr>1202 1197 <td class="reference"><b id="RFC1766">[RFC1766]</b></td> 1203 1198 <td class="top"><a title="UNINETT">Alvestrand, H.</a>, “<a href="http://tools.ietf.org/html/rfc1766">Tags for the Identification of Languages</a>”, RFC 1766, March 1995. … … 1282 1277 <td class="reference"><b id="RFC2616">[RFC2616]</b></td> 1283 1278 <td class="top"><a title="University of California, Irvine">Fielding, R.</a>, <a title="W3C">Gettys, J.</a>, <a title="Compaq Computer Corporation">Mogul, J.</a>, <a title="MIT Laboratory for Computer Science">Frystyk, H.</a>, <a title="Xerox Corporation">Masinter, L.</a>, <a title="Microsoft Corporation">Leach, P.</a>, and <a title="W3C">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC 2616, June 1999. 1279 </td> 1280 </tr> 1281 <tr> 1282 <td class="reference"><b id="RFC4288">[RFC4288]</b></td> 1283 <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. 1284 1284 </td> 1285 1285 </tr> … … 1339 1339 </p> 1340 1340 <h2 id="rfc.section.A.4"><a href="#rfc.section.A.4">A.4</a> <a id="no.content-transfer-encoding" href="#no.content-transfer-encoding">No Content-Transfer-Encoding</a></h2> 1341 <p id="rfc.section.A.4.p.1">HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC 2045. Proxies and gateways from MIME-compliant protocols 1342 to HTTP <em class="bcp14">MUST</em> remove any non-identity CTE ("quoted-printable" or "base64") encoding prior to delivering the response message to an HTTP 1343 client. 1341 <p id="rfc.section.A.4.p.1">HTTP does not use the Content-Transfer-Encoding field of RFC 2045. Proxies and gateways from MIME-compliant protocols to HTTP <em class="bcp14">MUST</em> remove any Content-Transfer-Encoding prior to delivering the response message to an HTTP client. 1344 1342 </p> 1345 1343 <p id="rfc.section.A.4.p.2">Proxies and gateways from HTTP to MIME-compliant protocols are responsible for ensuring that the message is in the correct … … 1564 1562 </li> 1565 1563 <li class="indline0"><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul class="ind"> 1566 <li class="indline1"><em>RFC1590</em> <a class="iref" href="#rfc.xref.RFC1590.1">2.3</a>, <a class="iref" href="#rfc.xref.RFC1590.2">2.3</a>, <a class="iref" href="#RFC1590"><b>9</b></a></li>1567 <li class="indline1"><em>RFC1700</em> <a class="iref" href="#rfc.xref.RFC1700.1">2.1</a>, <a class="iref" href="#rfc.xref.RFC1700.2">2.1</a>, <a class="iref" href="#rfc.xref.RFC1700.3">2.3</a>, <a class="iref" href="#RFC1700"><b>9</b></a></li>1568 1564 <li class="indline1"><em>RFC1766</em> <a class="iref" href="#rfc.xref.RFC1766.1">2.5</a>, <a class="iref" href="#RFC1766"><b>9</b></a></li> 1569 1565 <li class="indline1"><em>RFC1806</em> <a class="iref" href="#rfc.xref.RFC1806.1">7.2</a>, <a class="iref" href="#RFC1806"><b>9</b></a>, <a class="iref" href="#rfc.xref.RFC1806.2">B.1</a></li> … … 1589 1585 <li class="indline1"><em>RFC2279</em> <a class="iref" href="#rfc.xref.RFC2279.1">2.1</a>, <a class="iref" href="#RFC2279"><b>9</b></a></li> 1590 1586 <li class="indline1"><em>RFC2616</em> <a class="iref" href="#rfc.xref.RFC2616.1">§</a>, <a class="iref" href="#RFC2616"><b>9</b></a></li> 1587 <li class="indline1"><em>RFC4288</em> <a class="iref" href="#rfc.xref.RFC4288.1">2.3</a>, <a class="iref" href="#rfc.xref.RFC4288.2">2.3</a>, <a class="iref" href="#RFC4288"><b>9</b></a></li> 1591 1588 <li class="indline1"><em>RFC822</em> <a class="iref" href="#RFC822"><b>9</b></a>, <a class="iref" href="#rfc.xref.RFC822.1">A</a></li> 1592 1589 </ul> -
draft-ietf-httpbis/latest/p5-range.html
r62 r92 528 528 </li> 529 529 </ul> 530 <p id="rfc.section.3.1.p.3">If the 206 response is the result of an If-Range request that used a strong cache validator (see <a href="p4-conditional.html#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>), the response <em class="bcp14">SHOULD NOT</em> include other entity-headers. If the response is the result of an If-Range request that used a weak validator, the response <em class="bcp14">MUST NOT</em> include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers. Otherwise, the 531 response <em class="bcp14">MUST</em> include all of the entity-headers that would have been returned with a 200 (OK) response to the same request. 530 <p id="rfc.section.3.1.p.3">If the 206 response is the result of an If-Range request, the response <em class="bcp14">SHOULD NOT</em> include other entity-headers. Otherwise, the response <em class="bcp14">MUST</em> include all of the entity-headers that would have been returned with a 200 (OK) response to the same request. 532 531 </p> 533 532 <p id="rfc.section.3.1.p.4">A cache <em class="bcp14">MUST NOT</em> combine a 206 response with other previously cached content if the ETag or Last-Modified headers do not match exactly, see <a href="#combining.byte.ranges" title="Combining Byte Ranges">4</a>. … … 554 553 <ul> 555 554 <li>Both the incoming response and the cache entry have a cache validator.</li> 556 <li>The two cache validators match using the strong comparison function (see <a href="p4-conditional.html#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4. 2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>).555 <li>The two cache validators match using the strong comparison function (see <a href="p4-conditional.html#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). 557 556 </li> 558 557 </ul> … … 948 947 <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind"> 949 948 <li class="indline1"><em>Part1</em> <a class="iref" href="#rfc.xref.Part1.1">7</a>, <a class="iref" href="#Part1"><b>9</b></a></li> 950 <li class="indline1"><em>Part4</em> <a class="iref" href="#rfc.xref.Part4.1"> 3.1</a>, <a class="iref" href="#rfc.xref.Part4.2">4</a>, <a class="iref" href="#Part4"><b>9</b></a><ul class="ind">951 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.Part4.1"> 3.1</a>, <a class="iref" href="#rfc.xref.Part4.2">4</a></li>949 <li class="indline1"><em>Part4</em> <a class="iref" href="#rfc.xref.Part4.1">4</a>, <a class="iref" href="#Part4"><b>9</b></a><ul class="ind"> 950 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.Part4.1">4</a></li> 952 951 </ul> 953 952 </li> -
draft-ietf-httpbis/latest/p6-cache.html
r62 r92 993 993 <li>Proxy-Authorization</li> 994 994 <li>TE</li> 995 <li>Trailer s</li>995 <li>Trailer</li> 996 996 <li>Transfer-Encoding</li> 997 997 <li>Upgrade</li> 998 998 </ul> 999 999 <p id="rfc.section.2.5.1.p.3">All other headers defined by HTTP/1.1 are end-to-end headers.</p> 1000 <p id="rfc.section.2.5.1.p.4">Other hop-by-hop headers <em class="bcp14">MUST</em> be listed in a Connection header , (<a href="p1-messaging.html#header.connection" title="Connection">Section 8.1</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) to be introduced into HTTP/1.1 (or later).1000 <p id="rfc.section.2.5.1.p.4">Other hop-by-hop headers <em class="bcp14">MUST</em> be listed in a Connection header (<a href="p1-messaging.html#header.connection" title="Connection">Section 8.1</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 1001 1001 </p> 1002 1002 <h3 id="rfc.section.2.5.2"><a href="#rfc.section.2.5.2">2.5.2</a> <a id="non-modifiable.headers" href="#non-modifiable.headers">Non-modifiable Headers</a></h3> … … 1143 1143 <li>POST</li> 1144 1144 </ul> 1145 <p id="rfc.section.2.10.p.5">In order to prevent denial of service attacks, an invalidation based on the URI in a Location or Content-Location header <em class="bcp14">MUST</em> only be performed if the host part is the same as in the Request-URI. 1145 <p id="rfc.section.2.10.p.5">An invalidation based on the URI in a Location or Content-Location header <em class="bcp14">MUST NOT</em> be performed if the host part of that URI differs from the host part in the Request-URI. This helps prevent denial of service 1146 attacks. 1146 1147 </p> 1147 1148 <p id="rfc.section.2.10.p.6">A cache that passes through requests for methods it does not understand <em class="bcp14">SHOULD</em> invalidate any entities referred to by the Request-URI.
Note: See TracChangeset
for help on using the changeset viewer.
