Changeset 97
- Timestamp:
- 23/12/07 13:22:38 (13 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 14 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r96 r97 616 616 <p id="rfc.section.1.1.p.1">The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information 617 617 systems. HTTP has been in use by the World-Wide Web global information initiative since 1990. The first version of HTTP, referred 618 to as HTTP/0.9, was a simple protocol for raw data transfer across the Internet. HTTP/1.0, as defined by RFC 1945<a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a>, improved the protocol by allowing messages to be in the format of MIME-like messages, containing metainformation about the618 to as HTTP/0.9, was a simple protocol for raw data transfer across the Internet. HTTP/1.0, as defined by <a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a>, improved the protocol by allowing messages to be in the format of MIME-like messages, containing metainformation about the 619 619 data transferred and modifiers on the request/response semantics. However, HTTP/1.0 does not sufficiently take into consideration 620 620 the effects of hierarchical proxies, caching, the need for persistent connections, or virtual hosts. In addition, the proliferation … … 838 838 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> <a id="notation.abnf" href="#notation.abnf">Augmented BNF</a></h2> 839 839 <p id="rfc.section.2.1.p.1">All of the mechanisms specified in this document are described in both prose and an augmented Backus-Naur Form (BNF) similar 840 to that used by RFC 822<a href="#RFC822" id="rfc.xref.RFC822.2"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a>. Implementors will need to be familiar with the notation in order to understand this specification. The augmented BNF includes840 to that used by <a href="#RFC822" id="rfc.xref.RFC822.2"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a>. Implementors will need to be familiar with the notation in order to understand this specification. The augmented BNF includes 841 841 the following constructs: 842 842 </p> … … 934 934 <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.14"></span> LWS = [CRLF] 1*( SP | HT ) 935 935 </pre><p id="rfc.section.2.2.p.7">The TEXT rule is only used for descriptive field contents and values that are not intended to be interpreted by the message 936 parser. Words of *TEXT <em class="bcp14">MAY</em> contain characters from character sets other than ISO-8859-1 <a href="#ISO-8859" id="rfc.xref.ISO-8859.1"><cite title="Information technology - 8-bit single byte coded graphic - character sets">[ISO-8859]</cite></a> only when encoded according to the rules of RFC 2047<a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a>.936 parser. Words of *TEXT <em class="bcp14">MAY</em> contain characters from character sets other than ISO-8859-1 <a href="#ISO-8859" id="rfc.xref.ISO-8859.1"><cite title="Information technology - 8-bit single byte coded graphic - character sets">[ISO-8859]</cite></a> only when encoded according to the rules of <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a>. 937 937 </p> 938 938 <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.15"></span> TEXT = <any OCTET except CTLs, … … 971 971 when the changes made to the protocol add features which do not change the general message parsing algorithm, but which may 972 972 add to the message semantics and imply additional capabilities of the sender. The <major> number is incremented when the format 973 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.973 of a message within the protocol is changed. See <a href="#RFC2145" id="rfc.xref.RFC2145.1"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a> for a fuller explanation. 974 974 </p> 975 975 <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> … … 980 980 <p id="rfc.section.3.1.p.5">An application that sends a request or response message that includes HTTP-Version of "HTTP/1.1" <em class="bcp14">MUST</em> be at least conditionally compliant with this specification. Applications that are at least conditionally compliant with this 981 981 specification <em class="bcp14">SHOULD</em> use an HTTP-Version of "HTTP/1.1" in their messages, and <em class="bcp14">MUST</em> do so for any message that is not compatible with HTTP/1.0. For more details on when to send specific HTTP-Version values, 982 see RFC 2145<a href="#RFC2145" id="rfc.xref.RFC2145.2"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a>.982 see <a href="#RFC2145" id="rfc.xref.RFC2145.2"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a>. 983 983 </p> 984 984 <p id="rfc.section.3.1.p.6">The HTTP version of an application is the highest HTTP version for which the application is at least conditionally compliant.</p> … … 987 987 the proxy/gateway <em class="bcp14">MUST</em> either downgrade the request version, or respond with an error, or switch to tunnel behavior. 988 988 </p> 989 <p id="rfc.section.3.1.p.8">Due to interoperability problems with HTTP/1.0 proxies discovered since the publication of RFC 2068<a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, caching proxies <em class="bcp14">MUST</em>, gateways <em class="bcp14">MAY</em>, and tunnels <em class="bcp14">MUST NOT</em> upgrade the request to the highest version they support. The proxy/gateway's response to that request <em class="bcp14">MUST</em> be in the same major version as the request.989 <p id="rfc.section.3.1.p.8">Due to interoperability problems with HTTP/1.0 proxies discovered since the publication of <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, caching proxies <em class="bcp14">MUST</em>, gateways <em class="bcp14">MAY</em>, and tunnels <em class="bcp14">MUST NOT</em> upgrade the request to the highest version they support. The proxy/gateway's response to that request <em class="bcp14">MUST</em> be in the same major version as the request. 990 990 </p> 991 991 <p id="rfc.section.3.1.p.9"> </p> … … 1001 1001 <p id="rfc.section.3.2.1.p.1">URIs in HTTP can be represented in absolute form or relative to some known base URI <a href="#RFC1808" id="rfc.xref.RFC1808.1"><cite title="Relative Uniform Resource Locators">[RFC1808]</cite></a>, depending upon the context of their use. The two forms are differentiated by the fact that absolute URIs always begin with 1002 1002 a scheme name followed by a colon. For definitive information on URL syntax and semantics, see "Uniform Resource Identifiers 1003 (URI): Generic Syntax and Semantics," RFC 2396 <a href="#RFC2396" id="rfc.xref.RFC2396.1"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a> (which replaces RFCs 1738 <a href="#RFC1738" id="rfc.xref.RFC1738.3"><cite title="Uniform Resource Locators (URL)">[RFC1738]</cite></a> and RFC 1808<a href="#RFC1808" id="rfc.xref.RFC1808.2"><cite title="Relative Uniform Resource Locators">[RFC1808]</cite></a>). This specification adopts the definitions of "URI-reference", "absoluteURI", "relativeURI", "port", "host","abs_path",1003 (URI): Generic Syntax and Semantics," <a href="#RFC2396" id="rfc.xref.RFC2396.1"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a> (which replaces <a href="#RFC1738" id="rfc.xref.RFC1738.3"><cite title="Uniform Resource Locators (URL)">[RFC1738]</cite></a> and <a href="#RFC1808" id="rfc.xref.RFC1808.2"><cite title="Relative Uniform Resource Locators">[RFC1808]</cite></a>). This specification adopts the definitions of "URI-reference", "absoluteURI", "relativeURI", "port", "host","abs_path", 1004 1004 "rel_path", and "authority" from that specification. 1005 1005 </p> … … 1018 1018 <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.25"></span>http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]] 1019 1019 </pre><p id="rfc.section.3.2.2.p.3">If the port is empty or not given, port 80 is assumed. The semantics are that the identified resource is located at the server 1020 listening for TCP connections on that port of that host, and the Request-URI for the resource is abs_path (<a href="#request-uri" title="Request-URI">Section 5.1.2</a>). The use of IP addresses in URLs <em class="bcp14">SHOULD</em> be avoided whenever possible (see RFC 1900<a href="#RFC1900" id="rfc.xref.RFC1900.1"><cite title="Renumbering Needs Work">[RFC1900]</cite></a>). If the abs_path is not present in the URL, it <em class="bcp14">MUST</em> be given as "/" when used as a Request-URI for a resource (<a href="#request-uri" title="Request-URI">Section 5.1.2</a>). If a proxy receives a host name which is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy <em class="bcp14">MUST NOT</em> change the host name.1020 listening for TCP connections on that port of that host, and the Request-URI for the resource is abs_path (<a href="#request-uri" title="Request-URI">Section 5.1.2</a>). The use of IP addresses in URLs <em class="bcp14">SHOULD</em> be avoided whenever possible (see <a href="#RFC1900" id="rfc.xref.RFC1900.1"><cite title="Renumbering Needs Work">[RFC1900]</cite></a>). If the abs_path is not present in the URL, it <em class="bcp14">MUST</em> be given as "/" when used as a Request-URI for a resource (<a href="#request-uri" title="Request-URI">Section 5.1.2</a>). If a proxy receives a host name which is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy <em class="bcp14">MUST NOT</em> change the host name. 1021 1021 </p> 1022 1022 <h3 id="rfc.section.3.2.3"><a href="#rfc.section.3.2.3">3.2.3</a> <a id="uri.comparison" href="#uri.comparison">URI Comparison</a></h3> … … 1031 1031 <li>An empty abs_path is equivalent to an abs_path of "/".</li> 1032 1032 </ul> 1033 <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.1033 <p id="rfc.section.3.2.3.p.2">Characters other than those in the "reserved" set (see <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. 1034 1034 </p> 1035 1035 <p id="rfc.section.3.2.3.p.3">For example, the following three URIs are equivalent:</p> … … 1043 1043 Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format 1044 1044 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format 1045 </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 servers1045 </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 <a href="#RFC1123" id="rfc.xref.RFC1123.1"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a> (an update to <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 1046 1046 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. 1047 1047 </p> … … 1168 1168 <p id="rfc.section.4.1.p.1">HTTP messages consist of requests from client to server and responses from server to client.</p> 1169 1169 <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.51"></span> HTTP-message = Request | Response ; HTTP/1.1 messages 1170 </pre><p id="rfc.section.4.1.p.3">Request (<a href="#request" title="Request">Section 5</a>) and Response (<a href="#response" title="Response">Section 6</a>) messages use the generic message format of RFC 822<a href="#RFC822" id="rfc.xref.RFC822.4"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a> for transferring entities (the payload of the message). Both types of message consist of a start-line, zero or more header1170 </pre><p id="rfc.section.4.1.p.3">Request (<a href="#request" title="Request">Section 5</a>) and Response (<a href="#response" title="Response">Section 6</a>) messages use the generic message format of <a href="#RFC822" id="rfc.xref.RFC822.4"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a> for transferring entities (the payload of the message). Both types of message consist of a start-line, zero or more header 1171 1171 fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header 1172 1172 fields, and possibly a message-body. … … 1184 1184 </p> 1185 1185 <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="message.headers" href="#message.headers">Message Headers</a></h2> 1186 <p id="rfc.section.4.2.p.1">HTTP header fields, which include general-header (<a href="#general.header.fields" title="General Header Fields">Section 4.5</a>), request-header (<a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), response-header (<a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 6</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), and entity-header (<a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 3.1</a> of <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) fields, follow the same generic format as that given in <a href="http://tools.ietf.org/html/rfc822#section-3.1" id="rfc.xref.RFC822.5">Section 3.1</a> of RFC 822 <a href="#RFC822" id="rfc.xref.RFC822.6"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a>. Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive. The1186 <p id="rfc.section.4.2.p.1">HTTP header fields, which include general-header (<a href="#general.header.fields" title="General Header Fields">Section 4.5</a>), request-header (<a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), response-header (<a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 6</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), and entity-header (<a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 3.1</a> of <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) fields, follow the same generic format as that given in <a href="http://tools.ietf.org/html/rfc822#section-3.1">Section 3.1</a> of <a href="#RFC822" id="rfc.xref.RFC822.5"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a>. Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive. The 1187 1187 field value <em class="bcp14">MAY</em> be preceded by any amount of LWS, though a single SP is preferred. Header fields can be extended over multiple lines by preceding 1188 1188 each extra line with at least one SP or HT. Applications ought to follow "common form", where one is known or indicated, when … … 1409 1409 servers and causing congestion on the Internet. The use of inline images and other associated data often require a client 1410 1410 to make multiple requests of the same server in a short amount of time. Analysis of these performance problems and results 1411 from a prototype implementation are available <a href="#Pad1995" id="rfc.xref.Pad1995.1"><cite title="Improving HTTP Latency">[Pad1995]</cite></a> <a href="#Spe" id="rfc.xref.Spe.1"><cite title="Analysis of HTTP Performance Problems">[Spe]</cite></a>. Implementation experience and measurements of actual HTTP/1.1 ( RFC 2068) implementations show good results <a href="#Nie1997" id="rfc.xref.Nie1997.1"><cite title="Network Performance Effects of HTTP/1.1, CSS1, and PNG">[Nie1997]</cite></a>. Alternatives have also been explored, for example, T/TCP <a href="#Tou1998" id="rfc.xref.Tou1998.1"><cite title="Analysis of HTTP Performance">[Tou1998]</cite></a>.1411 from a prototype implementation are available <a href="#Pad1995" id="rfc.xref.Pad1995.1"><cite title="Improving HTTP Latency">[Pad1995]</cite></a> <a href="#Spe" id="rfc.xref.Spe.1"><cite title="Analysis of HTTP Performance Problems">[Spe]</cite></a>. Implementation experience and measurements of actual HTTP/1.1 (<cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2068.2">RFC 2068</cite>) implementations show good results <a href="#Nie1997" id="rfc.xref.Nie1997.1"><cite title="Network Performance Effects of HTTP/1.1, CSS1, and PNG">[Nie1997]</cite></a>. Alternatives have also been explored, for example, T/TCP <a href="#Tou1998" id="rfc.xref.Tou1998.1"><cite title="Analysis of HTTP Performance">[Tou1998]</cite></a>. 1412 1412 </p> 1413 1413 <p id="rfc.section.7.1.1.p.2">Persistent HTTP connections have a number of advantages: </p> … … 1466 1466 to. Each persistent connection applies to only one transport link. 1467 1467 </p> 1468 <p id="rfc.section.7.1.3.p.3">A proxy server <em class="bcp14">MUST NOT</em> establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see RFC 2068 <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header implemented by many HTTP/1.0 clients).1468 <p id="rfc.section.7.1.3.p.3">A proxy server <em class="bcp14">MUST NOT</em> establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see <a href="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header implemented by many HTTP/1.0 clients). 1469 1469 </p> 1470 1470 <h3 id="rfc.section.7.1.4"><a href="#rfc.section.7.1.4">7.1.4</a> <a id="persistent.practical" href="#persistent.practical">Practical Considerations</a></h3> … … 1524 1524 <li>An origin server <em class="bcp14">SHOULD NOT</em> send a 100 (Continue) response if the request message does not include an Expect request-header field with the "100-continue" 1525 1525 expectation, and <em class="bcp14">MUST NOT</em> send a 100 (Continue) response if such a request comes from an HTTP/1.0 (or earlier) client. There is an exception to this 1526 rule: for compatibility with RFC 2068, a server <em class="bcp14">MAY</em> send a 100 (Continue) status in response to an HTTP/1.1 PUT or POST request that does not include an Expect request-header1526 rule: for compatibility with <a href="#RFC2068" id="rfc.xref.RFC2068.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, a server <em class="bcp14">MAY</em> send a 100 (Continue) status in response to an HTTP/1.1 PUT or POST request that does not include an Expect request-header 1527 1527 field with the "100-continue" expectation. This exception, the purpose of which is to minimize any client processing delays 1528 1528 associated with an undeclared wait for 100 (Continue) status, applies only to HTTP/1.1 requests, and not to requests with … … 1634 1634 <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> 1635 1635 <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 1636 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.1636 as orig-date in <a href="#RFC822" id="rfc.xref.RFC822.6"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a>. The field value is an HTTP-date, as described in <a href="#full.date" title="Full Date">Section 3.3.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format. 1637 1637 </p> 1638 1638 <div id="rfc.figure.u.41"></div><pre class="inline"><span id="rfc.iref.g.73"></span> Date = "Date" ":" HTTP-date … … 1684 1684 requested by the proxy. All Internet-based HTTP/1.1 servers <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status code to any HTTP/1.1 request message which lacks a Host header field. 1685 1685 </p> 1686 <p id="rfc.section.8.4.p.6">See sections <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">5.2</a> and <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses">D.1.1</a> for other requirements relating to Host.1686 <p id="rfc.section.8.4.p.6">See Sections <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">5.2</a> and <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses">D.1.1</a> for other requirements relating to Host. 1687 1687 </p> 1688 1688 <div id="rfc.iref.t.2"></div> … … 1797 1797 <h2 id="rfc.section.8.9"><a href="#rfc.section.8.9">8.9</a> <a id="header.via" href="#header.via">Via</a></h2> 1798 1798 <p id="rfc.section.8.9.p.1">The Via general-header field <em class="bcp14">MUST</em> be used by gateways and proxies to indicate the intermediate protocols and recipients between the user agent and the server 1799 on requests, and between the origin server and the client on responses. It is analogous to the "Received" field of RFC 822<a href="#RFC822" id="rfc.xref.RFC822.7"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a> and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities1799 on requests, and between the origin server and the client on responses. It is analogous to the "Received" field of <a href="#RFC822" id="rfc.xref.RFC822.7"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a> and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities 1800 1800 of all senders along the request/response chain. 1801 1801 </p> … … 1905 1905 <p id="rfc.section.10.6.p.1">They exist. They are hard to defend against. Research continues. Beware.</p> 1906 1906 <h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a> <a id="ack" href="#ack">Acknowledgments</a></h1> 1907 <p id="rfc.section.11.p.1">This specification makes heavy use of the augmented BNF and generic constructs defined by David H. Crocker for RFC 822<a href="#RFC822" id="rfc.xref.RFC822.8"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a>. Similarly, it reuses many of the definitions provided by Nathaniel Borenstein and Ned Freed for MIME <a href="#RFC2045" id="rfc.xref.RFC2045.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>. We hope that their inclusion in this specification will help reduce past confusion over the relationship between HTTP and1907 <p id="rfc.section.11.p.1">This specification makes heavy use of the augmented BNF and generic constructs defined by David H. Crocker for <a href="#RFC822" id="rfc.xref.RFC822.8"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a>. Similarly, it reuses many of the definitions provided by Nathaniel Borenstein and Ned Freed for MIME <a href="#RFC2045" id="rfc.xref.RFC2045.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>. We hope that their inclusion in this specification will help reduce past confusion over the relationship between HTTP and 1908 1908 Internet mail message formats. 1909 1909 </p> … … 2241 2241 <p id="rfc.section.D.p.3">For most implementations of HTTP/1.0, each connection is established by the client prior to the request and closed by the 2242 2242 server after sending the response. Some implementations implement the Keep-Alive version of persistent connections described 2243 in <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1" id="rfc.xref.RFC2068.3">Section 19.7.1</a> of RFC 2068 <a href="#RFC2068" id="rfc.xref.RFC2068.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.2243 in <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>. 2244 2244 </p> 2245 2245 <h2 id="rfc.section.D.1"><a href="#rfc.section.D.1">D.1</a> <a id="changes.from.1.0" href="#changes.from.1.0">Changes from HTTP/1.0</a></h2> … … 2281 2281 a new keyword (Connection: close) for declaring non-persistence. See <a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section 8.1</a>. 2282 2282 </p> 2283 <p id="rfc.section.D.2.p.3">The original HTTP/1.0 form of persistent connections (the Connection: Keep-Alive and Keep-Alive header) is documented in RFC 2284 2068. <a href="#RFC2068" id="rfc.xref.RFC2068.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> 2283 <p id="rfc.section.D.2.p.3">The original HTTP/1.0 form of persistent connections (the Connection: Keep-Alive and Keep-Alive header) is documented in <a href="#RFC2068" id="rfc.xref.RFC2068.6"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>. 2285 2284 </p> 2286 2285 <h2 id="rfc.section.D.3"><a href="#rfc.section.D.3">D.3</a> <a id="changes.from.rfc.2068" href="#changes.from.rfc.2068">Changes from RFC 2068</a></h2> 2287 2286 <p id="rfc.section.D.3.p.1">This specification has been carefully audited to correct and disambiguate key word usage; RFC 2068 had many problems in respect 2288 to the conventions laid out in RFC 2119<a href="#RFC2119" id="rfc.xref.RFC2119.2"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.2287 to the conventions laid out in <a href="#RFC2119" id="rfc.xref.RFC2119.2"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>. 2289 2288 </p> 2290 2289 <p id="rfc.section.D.3.p.2">Transfer-coding and message lengths all interact in ways that required fixing exactly when chunked encoding is used (to allow … … 2292 2291 computed. 2293 2292 </p> 2294 <p id="rfc.section.D.3.p.3">The use and interpretation of HTTP version numbers has been clarified by RFC 2145. Require proxies to upgrade requests to2295 highest protocol version they support to deal with problems discovered in HTTP/1.0implementations (<a href="#http.version" title="HTTP Version">Section 3.1</a>)2293 <p id="rfc.section.D.3.p.3">The use and interpretation of HTTP version numbers has been clarified by <a href="#RFC2145" id="rfc.xref.RFC2145.3"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a>. Require proxies to upgrade requests to highest protocol version they support to deal with problems discovered in HTTP/1.0 2294 implementations (<a href="#http.version" title="HTTP Version">Section 3.1</a>) 2296 2295 </p> 2297 2296 <p id="rfc.section.D.3.p.4">Proxies should be able to add Content-Length when appropriate.</p> … … 2540 2539 <li class="indline1"><em>RFC2045</em> <a class="iref" href="#rfc.xref.RFC2045.1">1.1</a>, <a class="iref" href="#rfc.xref.RFC2045.2">3.4</a>, <a class="iref" href="#rfc.xref.RFC2045.3">11</a>, <a class="iref" href="#RFC2045"><b>12</b></a></li> 2541 2540 <li class="indline1"><em>RFC2047</em> <a class="iref" href="#rfc.xref.RFC2047.1">2.2</a>, <a class="iref" href="#RFC2047"><b>12</b></a></li> 2542 <li class="indline1"><em>RFC2068</em> <a class="iref" href="#rfc.xref.RFC2068.1">3.1</a>, <a class="iref" href="#rfc.xref.RFC2068.2">7.1. 3</a>, <a class="iref" href="#RFC2068"><b>12</b></a>, <a class="iref" href="#rfc.xref.RFC2068.3">D</a>, <a class="iref" href="#rfc.xref.RFC2068.4">D</a>, <a class="iref" href="#rfc.xref.RFC2068.5">D.2</a><ul class="ind">2543 <li class="indline1"><em>Section 19.7.1</em> <a class="iref" href="#rfc.xref.RFC2068. 3">D</a></li>2541 <li class="indline1"><em>RFC2068</em> <a class="iref" href="#rfc.xref.RFC2068.1">3.1</a>, <a class="iref" href="#rfc.xref.RFC2068.2">7.1.1</a>, <a class="iref" href="#rfc.xref.RFC2068.3">7.1.3</a>, <a class="iref" href="#rfc.xref.RFC2068.4">7.2.3</a>, <a class="iref" href="#RFC2068"><b>12</b></a>, <a class="iref" href="#rfc.xref.RFC2068.5">D</a>, <a class="iref" href="#rfc.xref.RFC2068.6">D.2</a><ul class="ind"> 2542 <li class="indline1"><em>Section 19.7.1</em> <a class="iref" href="#rfc.xref.RFC2068.5">D</a></li> 2544 2543 </ul> 2545 2544 </li> 2546 2545 <li class="indline1"><em>RFC2119</em> <a class="iref" href="#rfc.xref.RFC2119.1">1.2</a>, <a class="iref" href="#RFC2119"><b>12</b></a>, <a class="iref" href="#rfc.xref.RFC2119.2">D.3</a></li> 2547 <li class="indline1"><em>RFC2145</em> <a class="iref" href="#rfc.xref.RFC2145.1">3.1</a>, <a class="iref" href="#rfc.xref.RFC2145.2">3.1</a>, <a class="iref" href="#RFC2145"><b>12</b></a> </li>2546 <li class="indline1"><em>RFC2145</em> <a class="iref" href="#rfc.xref.RFC2145.1">3.1</a>, <a class="iref" href="#rfc.xref.RFC2145.2">3.1</a>, <a class="iref" href="#RFC2145"><b>12</b></a>, <a class="iref" href="#rfc.xref.RFC2145.3">D.3</a></li> 2548 2547 <li class="indline1"><em>RFC2324</em> <a class="iref" href="#rfc.xref.RFC2324.1">1.1</a>, <a class="iref" href="#RFC2324"><b>12</b></a></li> 2549 2548 <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> … … 2552 2551 <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> 2553 2552 <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> 2554 <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">2553 <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">8.3</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"> 2555 2554 <li class="indline1"><em>Section 3.1</em> <a class="iref" href="#rfc.xref.RFC822.5">4.2</a></li> 2556 2555 </ul> -
draft-ietf-httpbis/latest/p1-messaging.xml
r96 r97 243 243 information initiative since 1990. The first version of HTTP, 244 244 referred to as HTTP/0.9, was a simple protocol for raw data transfer 245 across the Internet. HTTP/1.0, as defined by RFC 1945<xref target="RFC1945"/>, improved245 across the Internet. HTTP/1.0, as defined by <xref target="RFC1945"/>, improved 246 246 the protocol by allowing messages to be in the format of MIME-like 247 247 messages, containing metainformation about the data transferred and … … 661 661 All of the mechanisms specified in this document are described in 662 662 both prose and an augmented Backus-Naur Form (BNF) similar to that 663 used by RFC 822<xref target="RFC822"/>. Implementors will need to be familiar with the663 used by <xref target="RFC822"/>. Implementors will need to be familiar with the 664 664 notation in order to understand this specification. The augmented BNF 665 665 includes the following constructs: … … 865 865 that are not intended to be interpreted by the message parser. Words 866 866 of *TEXT &MAY; contain characters from character sets other than ISO-8859-1 867 <xref target="ISO-8859"/> only when encoded according to the rules of RFC 2047867 <xref target="ISO-8859"/> only when encoded according to the rules of 868 868 <xref target="RFC2047"/>. 869 869 </t> … … 942 942 additional capabilities of the sender. The <major> number is 943 943 incremented when the format of a message within the protocol is 944 changed. See RFC 2145<xref target="RFC2145"/> for a fuller explanation.944 changed. See <xref target="RFC2145"/> for a fuller explanation. 945 945 </t> 946 946 <t> … … 965 965 "HTTP/1.1" in their messages, and &MUST; do so for any message that is 966 966 not compatible with HTTP/1.0. For more details on when to send 967 specific HTTP-Version values, see RFC 2145<xref target="RFC2145"/>.967 specific HTTP-Version values, see <xref target="RFC2145"/>. 968 968 </t> 969 969 <t> … … 983 983 <t> 984 984 Due to interoperability problems with HTTP/1.0 proxies discovered 985 since the publication of RFC 2068<xref target="RFC2068"/>, caching proxies &MUST;, gateways985 since the publication of <xref target="RFC2068"/>, caching proxies &MUST;, gateways 986 986 &MAY;, and tunnels &MUST-NOT; upgrade the request to the highest version 987 987 they support. The proxy/gateway's response to that request &MUST; be in … … 1015 1015 with a scheme name followed by a colon. For definitive information on 1016 1016 URL syntax and semantics, see "Uniform Resource Identifiers (URI): 1017 Generic Syntax and Semantics," RFC 2396 <xref target="RFC2396"/> (which replaces RFCs1018 1738 <xref target="RFC1738"/> and RFC 1808<xref target="RFC1808"/>). This specification adopts the1017 Generic Syntax and Semantics," <xref target="RFC2396"/> (which replaces <xref target="RFC1738"/> 1018 and <xref target="RFC1808"/>). This specification adopts the 1019 1019 definitions of "URI-reference", "absoluteURI", "relativeURI", "port", 1020 1020 "host","abs_path", "rel_path", and "authority" from that … … 1054 1054 for TCP connections on that port of that host, and the Request-URI 1055 1055 for the resource is abs_path (<xref target="request-uri"/>). The use of IP addresses 1056 in URLs &SHOULD; be avoided whenever possible (see RFC 1900<xref target="RFC1900"/>). If1056 in URLs &SHOULD; be avoided whenever possible (see <xref target="RFC1900"/>). If 1057 1057 the abs_path is not present in the URL, it &MUST; be given as "/" when 1058 1058 used as a Request-URI for a resource (<xref target="request-uri"/>). If a proxy … … 1080 1080 <t> 1081 1081 Characters other than those in the "reserved" set (see 1082 RFC 2396<xref target="RFC2396"/>) are equivalent to their ""%" HEX HEX" encoding.1082 <xref target="RFC2396"/>) are equivalent to their ""%" HEX HEX" encoding. 1083 1083 </t> 1084 1084 <t> … … 1106 1106 <t> 1107 1107 The first format is preferred as an Internet standard and represents 1108 a fixed-length subset of that defined by RFC 1123<xref target="RFC1123"/> (an update to1109 RFC 822<xref target="RFC822"/>). The other formats are described here only for1108 a fixed-length subset of that defined by <xref target="RFC1123"/> (an update to 1109 <xref target="RFC822"/>). The other formats are described here only for 1110 1110 compatibility with obsolete implementations. 1111 1111 HTTP/1.1 clients and servers that parse the date value &MUST; accept … … 1324 1324 <t> 1325 1325 Request (<xref target="request"/>) and Response (<xref target="response"/>) messages use the generic 1326 message format of RFC 822<xref target="RFC822"/> for transferring entities (the payload1326 message format of <xref target="RFC822"/> for transferring entities (the payload 1327 1327 of the message). Both types of message consist of a start-line, zero 1328 1328 or more header fields (also known as "headers"), an empty line (i.e., … … 1356 1356 request-header (&request-header-fields;), response-header (&response-header-fields;), and 1357 1357 entity-header (&entity-header-fields;) fields, follow the same generic format as 1358 that given in <xref target="RFC822" x:fmt=" sec" x:sec="3.1"/> of RFC 822 <xref target="RFC822"/>. Each header field consists1358 that given in <xref target="RFC822" x:fmt="of" x:sec="3.1"/>. Each header field consists 1359 1359 of a name followed by a colon (":") and the field value. Field names 1360 1360 are case-insensitive. The field value &MAY; be preceded by any amount … … 1805 1805 these performance problems and results from a prototype 1806 1806 implementation are available <xref target="Pad1995"/> <xref target="Spe"/>. Implementation experience and 1807 measurements of actual HTTP/1.1 ( RFC 2068) implementations show good1807 measurements of actual HTTP/1.1 (<xref target="RFC2068" x:fmt="none">RFC 2068</xref>) implementations show good 1808 1808 results <xref target="Nie1997"/>. Alternatives have also been explored, for example, 1809 1809 T/TCP <xref target="Tou1998"/>. … … 1938 1938 <t> 1939 1939 A proxy server &MUST-NOT; establish a HTTP/1.1 persistent connection 1940 with an HTTP/1.0 client (but see RFC 2068<xref target="RFC2068"/> for information and1940 with an HTTP/1.0 client (but see <xref target="RFC2068"/> for information and 1941 1941 discussion of the problems with the Keep-Alive header implemented by 1942 1942 many HTTP/1.0 clients). … … 2075 2075 100 (Continue) response if such a request comes from an HTTP/1.0 2076 2076 (or earlier) client. There is an exception to this rule: for 2077 compatibility with RFC 2068, a server &MAY; send a 100 (Continue)2077 compatibility with <xref target="RFC2068"/>, a server &MAY; send a 100 (Continue) 2078 2078 status in response to an HTTP/1.1 PUT or POST request that does 2079 2079 not include an Expect request-header field with the "100-continue" … … 2302 2302 The Date general-header field represents the date and time at which 2303 2303 the message was originated, having the same semantics as orig-date in 2304 RFC 822. The field value is an HTTP-date, as described in <xref target="full.date"/>;2304 <xref target="RFC822"/>. The field value is an HTTP-date, as described in <xref target="full.date"/>; 2305 2305 it &MUST; be sent in rfc1123-date format. 2306 2306 </t> … … 2410 2410 </t> 2411 2411 <t> 2412 See sections <xref target="the.resource.identified.by.a.request" format="counter"/>2412 See Sections <xref target="the.resource.identified.by.a.request" format="counter"/> 2413 2413 and <xref target="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" format="counter"/> 2414 2414 for other requirements relating to Host. … … 2625 2625 agent and the server on requests, and between the origin server and 2626 2626 the client on responses. It is analogous to the "Received" field of 2627 RFC 822<xref target="RFC822"/> and is intended to be used for tracking message forwards,2627 <xref target="RFC822"/> and is intended to be used for tracking message forwards, 2628 2628 avoiding request loops, and identifying the protocol capabilities of 2629 2629 all senders along the request/response chain. … … 2859 2859 <t> 2860 2860 This specification makes heavy use of the augmented BNF and generic 2861 constructs defined by David H. Crocker for RFC 822<xref target="RFC822"/>. Similarly, it2861 constructs defined by David H. Crocker for <xref target="RFC822"/>. Similarly, it 2862 2862 reuses many of the definitions provided by Nathaniel Borenstein and 2863 2863 Ned Freed for MIME <xref target="RFC2045"/>. We hope that their inclusion in this … … 3204 3204 3205 3205 <reference anchor="RFC1738"> 3206 <front> 3207 <title>Uniform Resource Locators (URL)</title> 3208 <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> 3209 <organization>CERN, World-Wide Web project</organization> 3210 <address> 3211 <postal> 3212 <street>1211 Geneva 23</street> 3213 <city/> 3214 <region/> 3215 <code/> 3216 <country>CH</country></postal> 3217 <phone>+41 22 7673755</phone> 3218 <facsimile>+41 22 7677155</facsimile> 3219 <email>timbl@info.cern.ch</email></address></author> 3220 <author initials="L." surname="Masinter" fullname="Larry Masinter"> 3221 <organization>Xerox PARC</organization> 3222 <address> 3223 <postal> 3224 <street>3333 Coyote Hill Road</street> 3225 <city>Palo Alto</city> 3226 <region>CA</region> 3227 <code>94034</code> 3228 <country>US</country></postal> 3229 <phone>+1 415 812 4365</phone> 3230 <facsimile>+1 415 812 4333</facsimile> 3231 <email>masinter@parc.xerox.com</email></address></author> 3232 <author initials="M." surname="McCahill" fullname="Mark McCahill"> 3233 <organization>University of Minnesota, Computer and Information Services</organization> 3234 <address> 3235 <postal> 3236 <street>100 Union Street SE, Shepherd Labs</street> 3237 <street>Room 152</street> 3238 <city>Minneapolis</city> 3239 <region>MN</region> 3240 <code>55455</code> 3241 <country>US</country></postal> 3242 <phone>+1 612 625 1300</phone> 3243 <email>mpm@boombox.micro.umn.edu</email></address></author> 3244 <date month="December" year="1994"/> 3245 </front> 3246 <seriesInfo name="RFC" value="1738"/> 3206 <front> 3207 <title>Uniform Resource Locators (URL)</title> 3208 <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> 3209 <organization>CERN, World-Wide Web project</organization> 3210 <address><email>timbl@info.cern.ch</email></address> 3211 </author> 3212 <author initials="L." surname="Masinter" fullname="Larry Masinter"> 3213 <organization>Xerox PARC</organization> 3214 <address><email>masinter@parc.xerox.com</email></address> 3215 </author> 3216 <author initials="M." surname="McCahill" fullname="Mark McCahill"> 3217 <organization>University of Minnesota, Computer and Information Services</organization> 3218 <address><email>mpm@boombox.micro.umn.edu</email></address> 3219 </author> 3220 <date month="December" year="1994"/> 3221 </front> 3222 <seriesInfo name="RFC" value="1738"/> 3247 3223 </reference> 3248 3224 3249 3225 <reference anchor="RFC1945"> 3250 <front> 3251 <title abbrev="HTTP/1.0">Hypertext Transfer Protocol -- HTTP/1.0</title> 3252 <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> 3253 <organization>MIT, Laboratory for Computer Science</organization> 3254 <address> 3255 <postal> 3256 <street>545 Technology Square</street> 3257 <city>Cambridge</city> 3258 <region>MA</region> 3259 <code>02139</code> 3260 <country>US</country></postal> 3261 <phone/> 3262 <facsimile>+1 617 258 8682</facsimile> 3263 <email>timbl@w3.org</email></address></author> 3264 <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding"> 3265 <organization>University of California, Irvine, Department of Information and Computer Science</organization> 3266 <address> 3267 <postal> 3268 <street/> 3269 <city>Irvine</city> 3270 <region>CA</region> 3271 <code>92717-3425</code> 3272 <country>US</country></postal> 3273 <phone/> 3274 <facsimile>+1 714 824 4056</facsimile> 3275 <email>fielding@ics.uci.edu</email></address></author> 3276 <author initials="H.F." surname="Nielsen" fullname="Henrik Frystyk Nielsen"> 3277 <organization>W3 Consortium, MIT Laboratory for Computer Science</organization> 3278 <address> 3279 <postal> 3280 <street>545 Technology Square</street> 3281 <city>Cambridge</city> 3282 <region>MA</region> 3283 <code>02139</code> 3284 <country>US</country></postal> 3285 <phone/> 3286 <facsimile>+1 617 258 8682</facsimile> 3287 <email>frystyk@w3.org</email></address></author> 3288 <date month="May" year="1996"/> 3289 </front> 3290 <seriesInfo name="RFC" value="1945"/> 3226 <front> 3227 <title abbrev="HTTP/1.0">Hypertext Transfer Protocol -- HTTP/1.0</title> 3228 <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> 3229 <organization>MIT, Laboratory for Computer Science</organization> 3230 <address><email>timbl@w3.org</email></address> 3231 </author> 3232 <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding"> 3233 <organization>University of California, Irvine, Department of Information and Computer Science</organization> 3234 <address><email>fielding@ics.uci.edu</email></address> 3235 </author> 3236 <author initials="H.F." surname="Nielsen" fullname="Henrik Frystyk Nielsen"> 3237 <organization>W3 Consortium, MIT Laboratory for Computer Science</organization> 3238 <address><email>frystyk@w3.org</email></address> 3239 </author> 3240 <date month="May" year="1996"/> 3241 </front> 3242 <seriesInfo name="RFC" value="1945"/> 3291 3243 </reference> 3292 3244 3293 3245 <reference anchor="RFC2045"> 3294 <front> 3295 <title abbrev="Internet Message Bodies">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</title> 3296 <author initials="N." surname="Freed" fullname="Ned Freed"> 3297 <organization>Innosoft International, Inc.</organization> 3298 <address> 3299 <postal> 3300 <street>1050 East Garvey Avenue South</street> 3301 <city>West Covina</city> 3302 <region>CA</region> 3303 <code>91790</code> 3304 <country>US</country></postal> 3305 <phone>+1 818 919 3600</phone> 3306 <facsimile>+1 818 919 3614</facsimile> 3307 <email>ned@innosoft.com</email></address></author> 3308 <author initials="N.S." surname="Borenstein" fullname="Nathaniel S. Borenstein"> 3309 <organization>First Virtual Holdings</organization> 3310 <address> 3311 <postal> 3312 <street>25 Washington Avenue</street> 3313 <city>Morristown</city> 3314 <region>NJ</region> 3315 <code>07960</code> 3316 <country>US</country></postal> 3317 <phone>+1 201 540 8967</phone> 3318 <facsimile>+1 201 993 3032</facsimile> 3319 <email>nsb@nsb.fv.com</email></address></author> 3320 <date month="November" year="1996"/> 3321 </front> 3322 <seriesInfo name="RFC" value="2045"/> 3246 <front> 3247 <title abbrev="Internet Message Bodies">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</title> 3248 <author initials="N." surname="Freed" fullname="Ned Freed"> 3249 <organization>Innosoft International, Inc.</organization> 3250 <address><email>ned@innosoft.com</email></address> 3251 </author> 3252 <author initials="N.S." surname="Borenstein" fullname="Nathaniel S. Borenstein"> 3253 <organization>First Virtual Holdings</organization> 3254 <address><email>nsb@nsb.fv.com</email></address> 3255 </author> 3256 <date month="November" year="1996"/> 3257 </front> 3258 <seriesInfo name="RFC" value="2045"/> 3323 3259 </reference> 3324 3260 3325 3261 <reference anchor="RFC1123"> 3326 <front> 3327 <title>Requirements for Internet Hosts - Application and Support</title> 3328 <author initials="R." surname="Braden" fullname="Robert Braden"> 3329 <organization>University of Southern California (USC), Information Sciences Institute</organization> 3330 <address> 3331 <postal> 3332 <street>4676 Admiralty Way</street> 3333 <city>Marina del Rey</city> 3334 <region>CA</region> 3335 <code>90292-6695</code> 3336 <country>US</country></postal> 3337 <phone>+1 213 822 1511</phone> 3338 <email>Braden@ISI.EDU</email></address></author> 3339 <date month="October" year="1989"/></front> 3340 <seriesInfo name="STD" value="3"/> 3341 <seriesInfo name="RFC" value="1123"/> 3262 <front> 3263 <title>Requirements for Internet Hosts - Application and Support</title> 3264 <author initials="R." surname="Braden" fullname="Robert Braden"> 3265 <organization>University of Southern California (USC), Information Sciences Institute</organization> 3266 <address><email>Braden@ISI.EDU</email></address> 3267 </author> 3268 <date month="October" year="1989"/> 3269 </front> 3270 <seriesInfo name="STD" value="3"/> 3271 <seriesInfo name="RFC" value="1123"/> 3342 3272 </reference> 3343 3273 3344 3274 <reference anchor="RFC822"> 3345 <front> 3346 <title abbrev="Standard for ARPA Internet Text Messages">Standard for the format of ARPA Internet text messages</title> 3347 <author initials="D.H." surname="Crocker" fullname="David H. Crocker"> 3348 <organization>University of Delaware, Dept. of Electrical Engineering</organization> 3349 <address> 3350 <postal> 3351 <street/> 3352 <city>Newark</city> 3353 <region>DE</region> 3354 <code>19711</code> 3355 <country>US</country></postal> 3356 <email>DCrocker@UDel-Relay</email></address></author> 3357 <date month="August" day="13" year="1982"/></front> 3358 <seriesInfo name="STD" value="11"/> 3359 <seriesInfo name="RFC" value="822"/> 3275 <front> 3276 <title abbrev="Standard for ARPA Internet Text Messages">Standard for the format of ARPA Internet text messages</title> 3277 <author initials="D.H." surname="Crocker" fullname="David H. Crocker"> 3278 <organization>University of Delaware, Dept. of Electrical Engineering</organization> 3279 <address><email>DCrocker@UDel-Relay</email></address> 3280 </author> 3281 <date month="August" day="13" year="1982"/> 3282 </front> 3283 <seriesInfo name="STD" value="11"/> 3284 <seriesInfo name="RFC" value="822"/> 3360 3285 </reference> 3361 3286 … … 3392 3317 3393 3318 <reference anchor="RFC1808"> 3394 <front> 3395 <title>Relative Uniform Resource Locators</title> 3396 <author initials="R." surname="Fielding" fullname="Roy T. Fielding"> 3397 <organization>University of California Irvine, Department of Information and Computer Science</organization> 3398 <address> 3399 <postal> 3400 <street/> 3401 <city>Irvine</city> 3402 <region>CA</region> 3403 <code>92717-3425</code> 3404 <country>US</country></postal> 3405 <phone>+1 714 824 4049</phone> 3406 <facsimile>+1 714 824 4056</facsimile> 3407 <email>fielding@ics.uci.edu</email></address></author> 3408 <date month="June" year="1995"/> 3409 </front> 3410 <seriesInfo name="RFC" value="1808"/> 3319 <front> 3320 <title>Relative Uniform Resource Locators</title> 3321 <author initials="R." surname="Fielding" fullname="Roy T. Fielding"> 3322 <organization>University of California Irvine, Department of Information and Computer Science</organization> 3323 <address><email>fielding@ics.uci.edu</email></address> 3324 </author> 3325 <date month="June" year="1995"/> 3326 </front> 3327 <seriesInfo name="RFC" value="1808"/> 3411 3328 </reference> 3412 3329 … … 3425 3342 3426 3343 <reference anchor="RFC2047"> 3427 <front> 3428 <title abbrev="Message Header Extensions">MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text</title> 3429 <author initials="K." surname="Moore" fullname="Keith Moore"> 3430 <organization>University of Tennessee</organization> 3431 <address> 3432 <postal> 3433 <street>107 Ayres Hall</street> 3434 <street>Knoxville TN 37996-1301</street></postal> 3435 <email>moore@cs.utk.edu</email></address></author> 3436 <date month="November" year="1996"/> 3437 <area>Applications</area> 3438 <keyword>Amercian Standard Code for Information Interchange</keyword> 3439 <keyword>mail</keyword> 3440 <keyword>multipurpose internet mail extensions</keyword> 3441 </front> 3442 <seriesInfo name="RFC" value="2047"/> 3344 <front> 3345 <title abbrev="Message Header Extensions">MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text</title> 3346 <author initials="K." surname="Moore" fullname="Keith Moore"> 3347 <organization>University of Tennessee</organization> 3348 <address><email>moore@cs.utk.edu</email></address> 3349 </author> 3350 <date month="November" year="1996"/> 3351 </front> 3352 <seriesInfo name="RFC" value="2047"/> 3443 3353 </reference> 3444 3354 … … 3557 3467 3558 3468 <reference anchor="RFC1900"> 3559 <front> 3560 <title>Renumbering Needs Work</title> 3561 <author initials="B." surname="Carpenter" fullname="Brian E. Carpenter"> 3562 <organization>CERN, Computing and Networks Division</organization> 3563 <address> 3564 <postal> 3565 <street>1211 Geneva 23</street> 3566 <country>CH</country></postal> 3567 <phone>+41 22 7674967</phone> 3568 <facsimile>+41 22 7677155</facsimile> 3569 <email>brian@dxcoms.cern.ch</email></address></author> 3570 <author initials="Y." surname="Rekhter" fullname="Yakov Rekhter"> 3571 <organization>cisco Systems</organization> 3572 <address> 3573 <postal> 3574 <street>170 West Tasman Drive</street> 3575 <city>San Jose</city> 3576 <region>CA</region> 3577 <code>95134</code> 3578 <country>US</country></postal> 3579 <phone>+1 914 528 0090</phone> 3580 <email>yakov@cisco.com</email></address></author> 3581 <date month="February" year="1996"/> 3582 </front> 3583 <seriesInfo name="RFC" value="1900"/> 3469 <front> 3470 <title>Renumbering Needs Work</title> 3471 <author initials="B." surname="Carpenter" fullname="Brian E. Carpenter"> 3472 <organization>CERN, Computing and Networks Division</organization> 3473 <address><email>brian@dxcoms.cern.ch</email></address> 3474 </author> 3475 <author initials="Y." surname="Rekhter" fullname="Yakov Rekhter"> 3476 <organization>cisco Systems</organization> 3477 <address><email>yakov@cisco.com</email></address> 3478 </author> 3479 <date month="February" year="1996"/> 3480 </front> 3481 <seriesInfo name="RFC" value="1900"/> 3584 3482 </reference> 3585 3483 … … 3649 3547 3650 3548 <reference anchor="RFC2068"> 3651 <front> 3652 <title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title> 3653 <author initials="R." surname="Fielding" fullname="Roy T. Fielding"> 3654 <organization>University of California, Irvine, Department of Information and Computer Science</organization> 3655 <address> 3656 <postal> 3657 <street/> 3658 <city>Irvine</city> 3659 <region>CA</region> 3660 <code>92717-3425</code> 3661 <country>US</country></postal> 3662 <facsimile>+1 714 824 4056</facsimile> 3663 <email>fielding@ics.uci.edu</email></address></author> 3664 <author initials="J." surname="Gettys" fullname="Jim Gettys"> 3665 <organization>MIT Laboratory for Computer Science</organization> 3666 <address> 3667 <postal> 3668 <street>545 Technology Square</street> 3669 <city>Cambridge</city> 3670 <region>MA</region> 3671 <code>02139</code> 3672 <country>US</country></postal> 3673 <facsimile>+1 617 258 8682</facsimile> 3674 <email>jg@w3.org</email></address></author> 3675 <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> 3676 <organization>Digital Equipment Corporation, Western Research Laboratory</organization> 3677 <address> 3678 <postal> 3679 <street>250 University Avenue</street> 3680 <city>Palo Alto</city> 3681 <region>CA</region> 3682 <code>94301</code> 3683 <country>US</country></postal> 3684 <email>mogul@wrl.dec.com</email></address></author> 3685 <author initials="H." surname="Nielsen" fullname="Henrik Frystyk Nielsen"> 3686 <organization>MIT Laboratory for Computer Science</organization> 3687 <address> 3688 <postal> 3689 <street>545 Technology Square</street> 3690 <city>Cambridge</city> 3691 <region>MA</region> 3692 <code>02139</code> 3693 <country>US</country></postal> 3694 <facsimile>+1 617 258 8682</facsimile> 3695 <email>frystyk@w3.org</email></address></author> 3696 <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> 3697 <organization>MIT Laboratory for Computer Science</organization> 3698 <address> 3699 <postal> 3700 <street>545 Technology Square</street> 3701 <city>Cambridge</city> 3702 <region>MA</region> 3703 <code>02139</code> 3704 <country>US</country></postal> 3705 <facsimile>+1 617 258 8682</facsimile> 3706 <email>timbl@w3.org</email></address></author> 3707 <date month="January" year="1997"/> 3708 <abstract> 3709 <t>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.</t> 3710 <t>HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1".</t></abstract></front> 3711 <seriesInfo name="RFC" value="2068"/> 3549 <front> 3550 <title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title> 3551 <author initials="R." surname="Fielding" fullname="Roy T. Fielding"> 3552 <organization>University of California, Irvine, Department of Information and Computer Science</organization> 3553 <address><email>fielding@ics.uci.edu</email></address> 3554 </author> 3555 <author initials="J." surname="Gettys" fullname="Jim Gettys"> 3556 <organization>MIT Laboratory for Computer Science</organization> 3557 <address><email>jg@w3.org</email></address> 3558 </author> 3559 <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> 3560 <organization>Digital Equipment Corporation, Western Research Laboratory</organization> 3561 <address><email>mogul@wrl.dec.com</email></address> 3562 </author> 3563 <author initials="H." surname="Nielsen" fullname="Henrik Frystyk Nielsen"> 3564 <organization>MIT Laboratory for Computer Science</organization> 3565 <address><email>frystyk@w3.org</email></address> 3566 </author> 3567 <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> 3568 <organization>MIT Laboratory for Computer Science</organization> 3569 <address><email>timbl@w3.org</email></address> 3570 </author> 3571 <date month="January" year="1997"/> 3572 </front> 3573 <seriesInfo name="RFC" value="2068"/> 3712 3574 </reference> 3713 3575 … … 3726 3588 3727 3589 <reference anchor="RFC2145"> 3728 <front> 3729 <title abbrev="HTTP Version Numbers">Use and Interpretation of HTTP Version Numbers</title> 3730 <author initials="J.C." surname="Mogul" fullname="Jeffrey C. Mogul"> 3731 <organization>Western Research Laboratory</organization> 3732 <address> 3733 <postal> 3734 <street>Digital Equipment Corporation</street> 3735 <street>250 University Avenue</street> 3736 <street>Palo Alto</street> 3737 <street>California</street> 3738 <street>94305</street> 3739 <country>USA</country></postal> 3740 <email>mogul@wrl.dec.com</email></address></author> 3741 <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding"> 3742 <organization>Department of Information and Computer Science</organization> 3743 <address> 3744 <postal> 3745 <street>University of California</street> 3746 <street>Irvine</street> 3747 <street>CA 92717-3425</street> 3748 <country>USA</country></postal> 3749 <facsimile>+1 (714) 824-4056</facsimile> 3750 <email>fielding@ics.uci.edu</email></address></author> 3751 <author initials="J." surname="Gettys" fullname="Jim Gettys"> 3752 <organization>MIT Laboratory for Computer Science</organization> 3753 <address> 3754 <postal> 3755 <street>545 Technology Square</street> 3756 <street>Cambridge</street> 3757 <street>MA 02139</street> 3758 <country>USA</country></postal> 3759 <facsimile>+1 (617) 258 8682</facsimile> 3760 <email>jg@w3.org</email></address></author> 3761 <author initials="H.F." surname="Nielsen" fullname="Henrik Frystyk Nielsen"> 3762 <organization>W3 Consortium</organization> 3763 <address> 3764 <postal> 3765 <street>MIT Laboratory for Computer Science</street> 3766 <street>545 Technology Square</street> 3767 <street>Cambridge</street> 3768 <street>MA 02139</street> 3769 <country>USA</country></postal> 3770 <facsimile>+1 (617) 258 8682</facsimile> 3771 <email>frystyk@w3.org</email></address></author> 3772 <date month="May" year="1997"/> 3773 <area>Applications</area> 3774 <keyword>HTTP</keyword> 3775 <keyword>hypertext transfer protocol</keyword> 3776 <abstract> 3777 <t> 3778 HTTP request and response messages include an HTTP protocol version 3779 number. Some confusion exists concerning the proper use and 3780 interpretation of HTTP version numbers, and concerning 3781 interoperability of HTTP implementations of different protocol 3782 versions. This document is an attempt to clarify the situation. It 3783 is not a modification of the intended meaning of the existing 3784 HTTP/1.0 and HTTP/1.1 documents, but it does describe the intention 3785 of the authors of those documents, and can be considered definitive 3786 when there is any ambiguity in those documents concerning HTTP 3787 version numbers, for all versions of HTTP. 3788 </t></abstract></front> 3789 <seriesInfo name="RFC" value="2145"/> 3590 <front> 3591 <title abbrev="HTTP Version Numbers">Use and Interpretation of HTTP Version Numbers</title> 3592 <author initials="J.C." surname="Mogul" fullname="Jeffrey C. Mogul"> 3593 <organization>Western Research Laboratory</organization> 3594 <address><email>mogul@wrl.dec.com</email></address> 3595 </author> 3596 <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding"> 3597 <organization>Department of Information and Computer Science</organization> 3598 <address><email>fielding@ics.uci.edu</email></address> 3599 </author> 3600 <author initials="J." surname="Gettys" fullname="Jim Gettys"> 3601 <organization>MIT Laboratory for Computer Science</organization> 3602 <address><email>jg@w3.org</email></address> 3603 </author> 3604 <author initials="H.F." surname="Nielsen" fullname="Henrik Frystyk Nielsen"> 3605 <organization>W3 Consortium</organization> 3606 <address><email>frystyk@w3.org</email></address> 3607 </author> 3608 <date month="May" year="1997"/> 3609 </front> 3610 <seriesInfo name="RFC" value="2145"/> 3790 3611 </reference> 3791 3612 … … 3814 3635 3815 3636 <reference anchor="RFC2396"> 3816 <front> 3817 <title abbrev="URI Generic Syntax">Uniform Resource Identifiers (URI): Generic Syntax</title> 3818 <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> 3819 <organization abbrev="MIT/LCS">World Wide Web Consortium</organization> 3820 <address> 3821 <postal> 3822 <street>MIT Laboratory for Computer Science, NE43-356</street> 3823 <street>545 Technology Square</street> 3824 <city>Cambridge</city> 3825 <region>MA</region> 3826 <code>02139</code></postal> 3827 <facsimile>+1(617)258-8682</facsimile> 3828 <email>timbl@w3.org</email></address></author> 3829 <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding"> 3830 <organization abbrev="U.C. Irvine">Department of Information and Computer Science</organization> 3831 <address> 3832 <postal> 3833 <street>University of California, Irvine</street> 3834 <city>Irvine</city> 3835 <region>CA</region> 3836 <code>92697-3425</code></postal> 3837 <facsimile>+1(949)824-1715</facsimile> 3838 <email>fielding@ics.uci.edu</email></address></author> 3839 <author initials="L." surname="Masinter" fullname="Larry Masinter"> 3840 <organization abbrev="Xerox Corporation">Xerox PARC</organization> 3841 <address> 3842 <postal> 3843 <street>3333 Coyote Hill Road</street> 3844 <city>Palo Alto</city> 3845 <region>CA</region> 3846 <code>94034</code></postal> 3847 <facsimile>+1(415)812-4333</facsimile> 3848 <email>masinter@parc.xerox.com</email></address></author> 3849 <date month="August" year="1998"/> 3850 <area>Applications</area> 3851 <keyword>uniform resource</keyword> 3852 <keyword>URI</keyword> 3853 </front> 3854 <seriesInfo name="RFC" value="2396"/> 3637 <front> 3638 <title abbrev="URI Generic Syntax">Uniform Resource Identifiers (URI): Generic Syntax</title> 3639 <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> 3640 <organization abbrev="MIT/LCS">World Wide Web Consortium</organization> 3641 <address><email>timbl@w3.org</email></address> 3642 </author> 3643 <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding"> 3644 <organization abbrev="U.C. Irvine">Department of Information and Computer Science</organization> 3645 <address><email>fielding@ics.uci.edu</email></address> 3646 </author> 3647 <author initials="L." surname="Masinter" fullname="Larry Masinter"> 3648 <organization abbrev="Xerox Corporation">Xerox PARC</organization> 3649 <address><email>masinter@parc.xerox.com</email></address> 3650 </author> 3651 <date month="August" year="1998"/> 3652 </front> 3653 <seriesInfo name="RFC" value="2396"/> 3855 3654 </reference> 3856 3655 … … 4058 3857 by the client prior to the request and closed by the server after 4059 3858 sending the response. Some implementations implement the Keep-Alive 4060 version of persistent connections described in <xref x:sec="19.7.1" x:fmt="sec" target="RFC2068"/> of RFC 4061 2068 <xref target="RFC2068"/>. 3859 version of persistent connections described in <xref x:sec="19.7.1" x:fmt="of" target="RFC2068"/>. 4062 3860 </t> 4063 3861 … … 4133 3931 <t> 4134 3932 The original HTTP/1.0 form of persistent connections (the Connection: 4135 Keep-Alive and Keep-Alive header) is documented in RFC 2068. <xref target="RFC2068"/>3933 Keep-Alive and Keep-Alive header) is documented in <xref target="RFC2068"/>. 4136 3934 </t> 4137 3935 </section> … … 4141 3939 This specification has been carefully audited to correct and 4142 3940 disambiguate key word usage; RFC 2068 had many problems in respect to 4143 the conventions laid out in RFC 2119<xref target="RFC2119"/>.3941 the conventions laid out in <xref target="RFC2119"/>. 4144 3942 </t> 4145 3943 <t> … … 4151 3949 <t> 4152 3950 The use and interpretation of HTTP version numbers has been clarified 4153 by RFC 2145. Require proxies to upgrade requests to highest protocol3951 by <xref target="RFC2145"/>. Require proxies to upgrade requests to highest protocol 4154 3952 version they support to deal with problems discovered in HTTP/1.0 4155 3953 implementations (<xref target="http.version"/>) -
draft-ietf-httpbis/latest/p2-semantics.html
r96 r97 1096 1096 </p> 1097 1097 <dl class="empty"> 1098 <dd> <b>Note:</b> RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most1099 existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless1100 of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear1101 which kind of reaction is expectedof the client.1098 <dd> <b>Note:</b> <a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a> and <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations 1099 treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. 1100 The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected 1101 of the client. 1102 1102 </dd> 1103 1103 </dl> … … 1129 1129 </p> 1130 1130 <dl class="empty"> 1131 <dd> <b>Note:</b> RFC 2068 was not clear that 305 was intended to redirect a single request, and to be generated by origin servers only. Not1132 observingthese limitations has significant security consequences.1131 <dd> <b>Note:</b> <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> was not clear that 305 was intended to redirect a single request, and to be generated by origin servers only. Not observing 1132 these limitations has significant security consequences. 1133 1133 </dd> 1134 1134 </dl> … … 1391 1391 <div id="rfc.iref.h.4"></div> 1392 1392 <h2 id="rfc.section.10.3"><a href="#rfc.section.10.3">10.3</a> <a id="header.from" href="#header.from">From</a></h2> 1393 <p id="rfc.section.10.3.p.1">The From request-header field, if given, <em class="bcp14">SHOULD</em> contain an Internet e-mail address for the human user who controls the requesting user agent. The address <em class="bcp14">SHOULD</em> be machine-usable, as defined by "mailbox" in RFC 822 <a href="#RFC822" id="rfc.xref.RFC822.1"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a> as updated by RFC 1123<a href="#RFC1123" id="rfc.xref.RFC1123.1"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a>:1393 <p id="rfc.section.10.3.p.1">The From request-header field, if given, <em class="bcp14">SHOULD</em> contain an Internet e-mail address for the human user who controls the requesting user agent. The address <em class="bcp14">SHOULD</em> be machine-usable, as defined by "mailbox" in <a href="#RFC822" id="rfc.xref.RFC822.1"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a> as updated by <a href="#RFC1123" id="rfc.xref.RFC1123.1"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a>: 1394 1394 </p> 1395 1395 <div id="rfc.figure.u.10"></div><pre class="inline"><span id="rfc.iref.g.16"></span> From = "From" ":" mailbox … … 1544 1544 <h1 id="rfc.references"><a href="#rfc.section.14" id="rfc.section.14">14.</a> References 1545 1545 </h1> 1546 <table summary="References"> 1546 <table summary="References"> 1547 1547 <tr> 1548 1548 <td class="reference"><b id="Luo1998">[Luo1998]</b></td> … … 1582 1582 <td class="reference"><b id="RFC1123">[RFC1123]</b></td> 1583 1583 <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. 1584 </td> 1585 </tr> 1586 <tr> 1587 <td class="reference"><b id="RFC1945">[RFC1945]</b></td> 1588 <td class="top"><a title="MIT, Laboratory for Computer Science">Berners-Lee, T.</a>, <a title="University of California, Irvine, Department of Information and Computer Science">Fielding, R.T.</a>, and <a title="W3 Consortium, MIT Laboratory for Computer Science">H.F. Nielsen</a>, “<a href="http://tools.ietf.org/html/rfc1945">Hypertext Transfer Protocol -- HTTP/1.0</a>”, RFC 1945, May 1996. 1584 1589 </td> 1585 1590 </tr> … … 1646 1651 <p id="rfc.section.A.p.5">Clean up confusion between 403 and 404 responses. (Section <a href="#status.403" id="rfc.xref.status.403.2" title="403 Forbidden">9.4.4</a>, <a href="#status.404" id="rfc.xref.status.404.2" title="404 Not Found">9.4.5</a>, and <a href="#status.410" id="rfc.xref.status.410.2" title="410 Gone">9.4.11</a>) 1647 1652 </p> 1648 <p id="rfc.section.A.p.6">The PATCH<span id="rfc.iref.p.3"></span><span id="rfc.iref.m.10"></span>, LINK<span id="rfc.iref.l.2"></span><span id="rfc.iref.m.11"></span>, UNLINK<span id="rfc.iref.u.2"></span><span id="rfc.iref.m.12"></span> methods were defined but not commonly implemented in previous versions of this specification. See RFC 2068 <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.1653 <p id="rfc.section.A.p.6">The PATCH<span id="rfc.iref.p.3"></span><span id="rfc.iref.m.10"></span>, LINK<span id="rfc.iref.l.2"></span><span id="rfc.iref.m.11"></span>, UNLINK<span id="rfc.iref.u.2"></span><span id="rfc.iref.m.12"></span> methods were defined but not commonly implemented in previous versions of this specification. See <a href="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>. 1649 1654 </p> 1650 1655 <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1> … … 1887 1892 <li class="indline1">Retry-After header <a class="iref" href="#rfc.xref.header.retry-after.1">6</a>, <a class="iref" href="#rfc.iref.r.2"><b>10.7</b></a></li> 1888 1893 <li class="indline1"><em>RFC1123</em> <a class="iref" href="#rfc.xref.RFC1123.1">10.3</a>, <a class="iref" href="#RFC1123"><b>14</b></a></li> 1889 <li class="indline1"><em>RFC2068</em> <a class="iref" href="#RFC2068"><b>14</b></a>, <a class="iref" href="#rfc.xref.RFC2068.1">A</a></li> 1894 <li class="indline1"><em>RFC1945</em> <a class="iref" href="#rfc.xref.RFC1945.1">9.3.3</a>, <a class="iref" href="#RFC1945"><b>14</b></a></li> 1895 <li class="indline1"><em>RFC2068</em> <a class="iref" href="#rfc.xref.RFC2068.1">9.3.3</a>, <a class="iref" href="#rfc.xref.RFC2068.2">9.3.6</a>, <a class="iref" href="#RFC2068"><b>14</b></a>, <a class="iref" href="#rfc.xref.RFC2068.3">A</a></li> 1890 1896 <li class="indline1"><em>RFC2119</em> <a class="iref" href="#rfc.xref.RFC2119.1">1.1</a>, <a class="iref" href="#RFC2119"><b>14</b></a></li> 1891 1897 <li class="indline1"><em>RFC2616</em> <a class="iref" href="#rfc.xref.RFC2616.1">§</a>, <a class="iref" href="#RFC2616"><b>14</b></a></li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r96 r97 1190 1190 change the conditions under which the request was issued. 1191 1191 <list><t> 1192 <x:h>Note:</x:h> RFC 1945 and RFC 2068specify that the client is not allowed1192 <x:h>Note:</x:h> <xref target="RFC1945"/> and <xref target="RFC2068"/> specify that the client is not allowed 1193 1193 to change the method on the redirected request. However, most 1194 1194 existing user agent implementations treat 302 as if it were a 303 … … 1245 1245 proxy. 305 responses &MUST; only be generated by origin servers. 1246 1246 <list><t> 1247 <x:h>Note:</x:h> RFC 2068was not clear that 305 was intended to redirect a1247 <x:h>Note:</x:h> <xref target="RFC2068"/> was not clear that 305 was intended to redirect a 1248 1248 single request, and to be generated by origin servers only. Not 1249 1249 observing these limitations has significant security consequences. … … 1758 1758 e-mail address for the human user who controls the requesting user 1759 1759 agent. The address &SHOULD; be machine-usable, as defined by "mailbox" 1760 in RFC 822 <xref target="RFC822"/> as updated by RFC 1123<xref target="RFC1123"/>:1760 in <xref target="RFC822"/> as updated by <xref target="RFC1123"/>: 1761 1761 </t> 1762 1762 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="From"/> … … 2397 2397 2398 2398 <reference anchor="RFC1123"> 2399 <front> 2400 <title>Requirements for Internet Hosts - Application and Support</title> 2401 <author initials="R." surname="Braden" fullname="Robert Braden"> 2402 <organization>University of Southern California (USC), Information Sciences Institute</organization> 2403 <address> 2404 <postal> 2405 <street>4676 Admiralty Way</street> 2406 <city>Marina del Rey</city> 2407 <region>CA</region> 2408 <code>90292-6695</code> 2409 <country>US</country></postal> 2410 <phone>+1 213 822 1511</phone> 2411 <email>Braden@ISI.EDU</email></address></author> 2412 <date month="October" year="1989"/></front> 2413 <seriesInfo name="STD" value="3"/> 2414 <seriesInfo name="RFC" value="1123"/> 2399 <front> 2400 <title>Requirements for Internet Hosts - Application and Support</title> 2401 <author initials="R." surname="Braden" fullname="Robert Braden"> 2402 <organization>University of Southern California (USC), Information Sciences Institute</organization> 2403 <address><email>Braden@ISI.EDU</email></address> 2404 </author> 2405 <date month="October" year="1989"/> 2406 </front> 2407 <seriesInfo name="STD" value="3"/> 2408 <seriesInfo name="RFC" value="1123"/> 2415 2409 </reference> 2416 2410 2417 2411 <reference anchor="RFC822"> 2418 <front> 2419 <title abbrev="Standard for ARPA Internet Text Messages">Standard for the format of ARPA Internet text messages</title> 2420 <author initials="D.H." surname="Crocker" fullname="David H. Crocker"> 2421 <organization>University of Delaware, Dept. of Electrical Engineering</organization> 2422 <address> 2423 <postal> 2424 <street/> 2425 <city>Newark</city> 2426 <region>DE</region> 2427 <code>19711</code> 2428 <country>US</country></postal> 2429 <email>DCrocker@UDel-Relay</email></address></author> 2430 <date month="August" day="13" year="1982"/></front> 2431 <seriesInfo name="STD" value="11"/> 2432 <seriesInfo name="RFC" value="822"/> 2412 <front> 2413 <title abbrev="Standard for ARPA Internet Text Messages">Standard for the format of ARPA Internet text messages</title> 2414 <author initials="D.H." surname="Crocker" fullname="David H. Crocker"> 2415 <organization>University of Delaware, Dept. of Electrical Engineering</organization> 2416 <address><email>DCrocker@UDel-Relay</email></address> 2417 </author> 2418 <date month="August" day="13" year="1982"/> 2419 </front> 2420 <seriesInfo name="STD" value="11"/> 2421 <seriesInfo name="RFC" value="822"/> 2433 2422 </reference> 2434 2423 2424 <reference anchor="RFC1945"> 2425 <front> 2426 <title abbrev="HTTP/1.0">Hypertext Transfer Protocol -- HTTP/1.0</title> 2427 <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> 2428 <organization>MIT, Laboratory for Computer Science</organization> 2429 <address><email>timbl@w3.org</email></address> 2430 </author> 2431 <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding"> 2432 <organization>University of California, Irvine, Department of Information and Computer Science</organization> 2433 <address><email>fielding@ics.uci.edu</email></address> 2434 </author> 2435 <author initials="H.F." surname="Nielsen" fullname="Henrik Frystyk Nielsen"> 2436 <organization>W3 Consortium, MIT Laboratory for Computer Science</organization> 2437 <address><email>frystyk@w3.org</email></address> 2438 </author> 2439 <date month="May" year="1996"/> 2440 </front> 2441 <seriesInfo name="RFC" value="1945"/> 2442 </reference> 2443 2435 2444 <reference anchor="RFC2068"> 2436 <front> 2437 <title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title> 2438 <author initials="R." surname="Fielding" fullname="Roy T. Fielding"> 2439 <organization>University of California, Irvine, Department of Information and Computer Science</organization> 2440 <address> 2441 <postal> 2442 <street/> 2443 <city>Irvine</city> 2444 <region>CA</region> 2445 <code>92717-3425</code> 2446 <country>US</country></postal> 2447 <facsimile>+1 714 824 4056</facsimile> 2448 <email>fielding@ics.uci.edu</email></address></author> 2449 <author initials="J." surname="Gettys" fullname="Jim Gettys"> 2450 <organization>MIT Laboratory for Computer Science</organization> 2451 <address> 2452 <postal> 2453 <street>545 Technology Square</street> 2454 <city>Cambridge</city> 2455 <region>MA</region> 2456 <code>02139</code> 2457 <country>US</country></postal> 2458 <facsimile>+1 617 258 8682</facsimile> 2459 <email>jg@w3.org</email></address></author> 2460 <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> 2461 <organization>Digital Equipment Corporation, Western Research Laboratory</organization> 2462 <address> 2463 <postal> 2464 <street>250 University Avenue</street> 2465 <city>Palo Alto</city> 2466 <region>CA</region> 2467 <code>94301</code> 2468 <country>US</country></postal> 2469 <email>mogul@wrl.dec.com</email></address></author> 2470 <author initials="H." surname="Nielsen" fullname="Henrik Frystyk Nielsen"> 2471 <organization>MIT Laboratory for Computer Science</organization> 2472 <address> 2473 <postal> 2474 <street>545 Technology Square</street> 2475 <city>Cambridge</city> 2476 <region>MA</region> 2477 <code>02139</code> 2478 <country>US</country></postal> 2479 <facsimile>+1 617 258 8682</facsimile> 2480 <email>frystyk@w3.org</email></address></author> 2481 <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> 2482 <organization>MIT Laboratory for Computer Science</organization> 2483 <address> 2484 <postal> 2485 <street>545 Technology Square</street> 2486 <city>Cambridge</city> 2487 <region>MA</region> 2488 <code>02139</code> 2489 <country>US</country></postal> 2490 <facsimile>+1 617 258 8682</facsimile> 2491 <email>timbl@w3.org</email></address></author> 2492 <date month="January" year="1997"/> 2493 <abstract> 2494 <t>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.</t> 2495 <t>HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1".</t></abstract></front> 2496 <seriesInfo name="RFC" value="2068"/> 2445 <front> 2446 <title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title> 2447 <author initials="R." surname="Fielding" fullname="Roy T. Fielding"> 2448 <organization>University of California, Irvine, Department of Information and Computer Science</organization> 2449 <address><email>fielding@ics.uci.edu</email></address> 2450 </author> 2451 <author initials="J." surname="Gettys" fullname="Jim Gettys"> 2452 <organization>MIT Laboratory for Computer Science</organization> 2453 <address><email>jg@w3.org</email></address> 2454 </author> 2455 <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> 2456 <organization>Digital Equipment Corporation, Western Research Laboratory</organization> 2457 <address><email>mogul@wrl.dec.com</email></address> 2458 </author> 2459 <author initials="H." surname="Nielsen" fullname="Henrik Frystyk Nielsen"> 2460 <organization>MIT Laboratory for Computer Science</organization> 2461 <address><email>frystyk@w3.org</email></address> 2462 </author> 2463 <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> 2464 <organization>MIT Laboratory for Computer Science</organization> 2465 <address><email>timbl@w3.org</email></address> 2466 </author> 2467 <date month="January" year="1997"/> 2468 </front> 2469 <seriesInfo name="RFC" value="2068"/> 2497 2470 </reference> 2498 2471 … … 2571 2544 <t> 2572 2545 The PATCH<iref item="PATCH method" primary="true"/><iref item="Methods" subitem="PATCH" primary="true"/>, LINK<iref item="LINK method" primary="true"/><iref item="Methods" subitem="LINK" primary="true"/>, UNLINK<iref item="UNLINK method" primary="true"/><iref item="Methods" subitem="UNLINK" primary="true"/> methods were defined but not commonly 2573 implemented in previous versions of this specification. See RFC 2068 2574 <xref target="RFC2068"/>. 2546 implemented in previous versions of this specification. See <xref target="RFC2068"/>. 2575 2547 </t> 2576 2548 </section> -
draft-ietf-httpbis/latest/p3-payload.html
r96 r97 620 620 </p> 621 621 <dl class="empty"> 622 <dd>An encoding format produced by the file compression program "gzip" (GNU zip) as described in RFC 1952<a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a>. This format is a Lempel-Ziv coding (LZ77) with a 32 bit CRC.622 <dd>An encoding format produced by the file compression program "gzip" (GNU zip) as described in <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a>. This format is a Lempel-Ziv coding (LZ77) with a 32 bit CRC. 623 623 </dd> 624 624 </dl> … … 637 637 </p> 638 638 <dl class="empty"> 639 <dd>The "zlib" format defined in RFC 1950 <a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a> in combination with the "deflate" compression mechanism described in RFC 1951<a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>.639 <dd>The "zlib" format defined in <a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a> in combination with the "deflate" compression mechanism described in <a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>. 640 640 </dd> 641 641 </dl> … … 692 692 <h3 id="rfc.section.2.3.2"><a href="#rfc.section.2.3.2">2.3.2</a> <a id="multipart.types" href="#multipart.types">Multipart Types</a></h3> 693 693 <p id="rfc.section.2.3.2.p.1">MIME provides for a number of "multipart" types -- encapsulations of one or more entities within a single message-body. All 694 multipart types share a common syntax, as defined in section <a href="http://tools.ietf.org/html/rfc2046#section-5.1.1" id="rfc.xref.RFC2046.1">5.1.1</a> of RFC 2046 <a href="#RFC2046" id="rfc.xref.RFC2046.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, and <em class="bcp14">MUST</em> include a boundary parameter as part of the media type value. The message body is itself a protocol element and <em class="bcp14">MUST</em> therefore use only CRLF to represent line breaks between body-parts. Unlike in RFC 2046, the epilogue of any multipart message <em class="bcp14">MUST</em> be empty; HTTP applications <em class="bcp14">MUST NOT</em> transmit the epilogue (even if the original multipart contains an epilogue). These restrictions exist in order to preserve694 multipart types share a common syntax, as defined in <a href="http://tools.ietf.org/html/rfc2046#section-5.1.1">Section 5.1.1</a> of <a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, and <em class="bcp14">MUST</em> include a boundary parameter as part of the media type value. The message body is itself a protocol element and <em class="bcp14">MUST</em> therefore use only CRLF to represent line breaks between body-parts. Unlike in RFC 2046, the epilogue of any multipart message <em class="bcp14">MUST</em> be empty; HTTP applications <em class="bcp14">MUST NOT</em> transmit the epilogue (even if the original multipart contains an epilogue). These restrictions exist in order to preserve 695 695 the self-delimiting nature of a multipart message-body, wherein the "end" of the message-body is indicated by the ending multipart 696 696 boundary. 697 697 </p> 698 698 <p id="rfc.section.2.3.2.p.2">In general, HTTP treats a multipart message-body no differently than any other media type: strictly as payload. The one exception 699 is the "multipart/byteranges" type (<a href="p5-range.html#internet.media.type.multipart.byteranges" title="Internet Media Type multipart/byteranges">Appendix A</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) when it appears in a 206 (Partial Content) response. In all other cases, an HTTP user agent <em class="bcp14">SHOULD</em> follow the same or similar behavior as a MIME user agent would upon receipt of a multipart type. The MIME header fields within 700 each body-part of a multipart message-body do not have any significance to HTTP beyond that defined by their MIME semantics. 699 is the "multipart/byteranges" type (<a href="p5-range.html#internet.media.type.multipart.byteranges" title="Internet Media Type multipart/byteranges">Appendix A</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) when it appears in a 206 (Partial Content) response. 701 700 </p> 702 701 <p id="rfc.section.2.3.2.p.3">In general, an HTTP user agent <em class="bcp14">SHOULD</em> follow the same or similar behavior as a MIME user agent would upon receipt of a multipart type. If an application receives … … 705 704 <dl class="empty"> 706 705 <dd> <b>Note:</b> The "multipart/form-data" type has been specifically defined for carrying form data suitable for processing via the POST request 707 method, as described in RFC 1867<a href="#RFC1867" id="rfc.xref.RFC1867.1"><cite title="Form-based File Upload in HTML">[RFC1867]</cite></a>.706 method, as described in <a href="#RFC1867" id="rfc.xref.RFC1867.1"><cite title="Form-based File Upload in HTML">[RFC1867]</cite></a>. 708 707 </dd> 709 708 </dl> … … 721 720 Content-Language fields. 722 721 </p> 723 <p id="rfc.section.2.5.p.2">The syntax and registry of HTTP language tags is the same as that defined by RFC 1766<a href="#RFC1766" id="rfc.xref.RFC1766.1"><cite title="Tags for the Identification of Languages">[RFC1766]</cite></a>. In summary, a language tag is composed of 1 or more parts: A primary language tag and a possibly empty series of subtags:722 <p id="rfc.section.2.5.p.2">The syntax and registry of HTTP language tags is the same as that defined by <a href="#RFC1766" id="rfc.xref.RFC1766.1"><cite title="Tags for the Identification of Languages">[RFC1766]</cite></a>. In summary, a language tag is composed of 1 or more parts: A primary language tag and a possibly empty series of subtags: 724 723 </p> 725 724 <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span><span id="rfc.iref.g.13"></span> language-tag = primary-tag *( "-" subtag ) … … 963 962 </p> 964 963 <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span> Accept-Encoding = "Accept-Encoding" ":" 965 964 1#( codings [ ";" "q" "=" qvalue ] ) 965 codings = ( content-coding | "*" ) 966 </pre><p id="rfc.section.5.3.p.3">Examples of its use are:</p> 967 <div id="rfc.figure.u.21"></div><pre class="text"> Accept-Encoding: compress, gzip 968 Accept-Encoding: 969 Accept-Encoding: * 970 Accept-Encoding: compress;q=0.5, gzip;q=1.0 971 Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 972 </pre><p id="rfc.section.5.3.p.5">A server tests whether a content-coding is acceptable, according to an Accept-Encoding field, using these rules: </p> 973 <ol> 974 <li>If the content-coding is one of the content-codings listed in the Accept-Encoding field, then it is acceptable, unless it 975 is accompanied by a qvalue of 0. (As defined in <a href="#quality.values" title="Quality Values">Section 2.4</a>, a qvalue of 0 means "not acceptable.") 976 </li> 977 <li>The special "*" symbol in an Accept-Encoding field matches any available content-coding not explicitly listed in the header 978 field. 979 </li> 980 <li>If multiple content-codings are acceptable, then the acceptable content-coding with the highest non-zero qvalue is preferred.</li> 981 <li>The "identity" content-coding is always acceptable, unless specifically refused because the Accept-Encoding field includes 982 "identity;q=0", or because the field includes "*;q=0" and does not explicitly include the "identity" content-coding. If the 983 Accept-Encoding field-value is empty, then only the "identity" encoding is acceptable. 984 </li> 985 </ol> 986 <p id="rfc.section.5.3.p.6">If an Accept-Encoding field is present in a request, and if the server cannot send a response which is acceptable according 987 to the Accept-Encoding header, then the server <em class="bcp14">SHOULD</em> send an error response with the 406 (Not Acceptable) status code. 988 </p> 989 <p id="rfc.section.5.3.p.7">If no Accept-Encoding field is present in a request, the server <em class="bcp14">MAY</em> assume that the client will accept any content coding. In this case, if "identity" is one of the available content-codings, 990 then the server <em class="bcp14">SHOULD</em> use the "identity" content-coding, unless it has additional information that a different content-coding is meaningful to the 991 client. 992 </p> 993 <dl class="empty"> 994 <dd> <b>Note:</b> If the request does not include an Accept-Encoding field, and if the "identity" content-coding is unavailable, then content-codings 995 commonly understood by HTTP/1.0 clients (i.e., "gzip" and "compress") are preferred; some older clients improperly display 996 messages sent with other content-codings. The server might also make this decision based on information about the particular 997 user-agent or client. 998 </dd> 999 <dd> <b>Note:</b> Most HTTP/1.0 applications do not recognize or obey qvalues associated with content-codings. This means that qvalues will 1000 not work and are not permitted with x-gzip or x-compress. 1001 </dd> 1002 </dl> 1003 <div id="rfc.iref.a.4"></div> 1004 <div id="rfc.iref.h.4"></div> 1005 <h2 id="rfc.section.5.4"><a href="#rfc.section.5.4">5.4</a> <a id="header.accept-language" href="#header.accept-language">Accept-Language</a></h2> 1006 <p id="rfc.section.5.4.p.1">The Accept-Language request-header field is similar to Accept, but restricts the set of natural languages that are preferred 1007 as a response to the request. Language tags are defined in <a href="#language.tags" title="Language Tags">Section 2.5</a>. 1008 </p> 1009 <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span> Accept-Language = "Accept-Language" ":" 1010 1#( language-range [ ";" "q" "=" qvalue ] ) 1011 language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" ) 1012 </pre><p id="rfc.section.5.4.p.3">Each language-range <em class="bcp14">MAY</em> be given an associated quality value which represents an estimate of the user's preference for the languages specified by 1013 that range. The quality value defaults to "q=1". For example, 1014 </p> 1015 <div id="rfc.figure.u.23"></div><pre class="text"> Accept-Language: da, en-gb;q=0.8, en;q=0.7 1016 </pre><p id="rfc.section.5.4.p.5">would mean: "I prefer Danish, but will accept British English and other types of English." A language-range matches a language-tag 1017 if it exactly equals the tag, or if it exactly equals a prefix of the tag such that the first tag character following the 1018 prefix is "-". The special range "*", if present in the Accept-Language field, matches every tag not matched by any other 1019 range present in the Accept-Language field. 1020 </p> 1021 <dl class="empty"> 1022 <dd> <b>Note:</b> This use of a prefix matching rule does not imply that language tags are assigned to languages in such a way that it is always 1023 true that if a user understands a language with a certain tag, then this user will also understand all languages with tags 1024 for which this tag is a prefix. The prefix rule simply allows the use of prefix tags if this is the case. 1025 </dd> 1026 </dl> 1027 <p id="rfc.section.5.4.p.6">The language quality factor assigned to a language-tag by the Accept-Language field is the quality value of the longest language-range 1028 in the field that matches the language-tag. If no language-range in the field matches the tag, the language quality factor 1029 assigned is 0. If no Accept-Language header is present in the request, the server <em class="bcp14">SHOULD</em> assume that all languages are equally acceptable. If an Accept-Language header is present, then all languages which are assigned 1030 a quality factor greater than 0 are acceptable. 1031 </p> 1032 <p id="rfc.section.5.4.p.7">It might be contrary to the privacy expectations of the user to send an Accept-Language header with the complete linguistic 1033 preferences of the user in every request. For a discussion of this issue, see <a href="#privacy.issues.connected.to.accept.headers" title="Privacy Issues Connected to Accept Headers">Section 7.1</a>. 1034 </p> 1035 <p id="rfc.section.5.4.p.8">As intelligibility is highly dependent on the individual user, it is recommended that client applications make the choice 1036 of linguistic preference available to the user. If the choice is not made available, then the Accept-Language header field <em class="bcp14">MUST NOT</em> be given in the request. 1037 </p> 1038 <dl class="empty"> 1039 <dd> <b>Note:</b> When making the choice of linguistic preference available to the user, we remind implementors of the fact that users are not 1040 familiar with the details of language matching as described above, and should provide appropriate guidance. As an example, 1041 users might assume that on selecting "en-gb", they will be served any kind of English document if British English is not available. 1042 A user agent might suggest in such a case to add "en" to get the best matching behavior. 1043 </dd> 1044 </dl> 1045 <div id="rfc.iref.c.2"></div> 1046 <div id="rfc.iref.h.5"></div> 1047 <h2 id="rfc.section.5.5"><a href="#rfc.section.5.5">5.5</a> <a id="header.content-encoding" href="#header.content-encoding">Content-Encoding</a></h2> 1048 <p id="rfc.section.5.5.p.1">The Content-Encoding entity-header field is used as a modifier to the media-type. When present, its value indicates what additional 1049 content codings have been applied to the entity-body, and thus what decoding mechanisms must be applied in order to obtain 1050 the media-type referenced by the Content-Type header field. Content-Encoding is primarily used to allow a document to be compressed 1051 without losing the identity of its underlying media type. 1052 </p> 1053 <div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.26"></span> Content-Encoding = "Content-Encoding" ":" 1#content-coding 1054 </pre><p id="rfc.section.5.5.p.3">Content codings are defined in <a href="#content.codings" title="Content Codings">Section 2.2</a>. An example of its use is 1055 </p> 1056 <div id="rfc.figure.u.25"></div><pre class="text"> Content-Encoding: gzip 1057 </pre><p id="rfc.section.5.5.p.5">The content-coding is a characteristic of the entity identified by the Request-URI. Typically, the entity-body is stored with 1058 this encoding and is only decoded before rendering or analogous usage. However, a non-transparent proxy <em class="bcp14">MAY</em> modify the content-coding if the new coding is known to be acceptable to the recipient, unless the "no-transform" cache-control 1059 directive is present in the message. 1060 </p> 1061 <p id="rfc.section.5.5.p.6">If the content-coding of an entity is not "identity", then the response <em class="bcp14">MUST</em> include a Content-Encoding entity-header (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.3" title="Content-Encoding">Section 5.5</a>) that lists the non-identity content-coding(s) used. 1062 </p> 1063 <p id="rfc.section.5.5.p.7">If the content-coding of an entity in a request message is not acceptable to the origin server, the server <em class="bcp14">SHOULD</em> respond with a status code of 415 (Unsupported Media Type). 1064 </p> 1065 <p id="rfc.section.5.5.p.8">If multiple encodings have been applied to an entity, the content codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other entity-header fields not defined by this specification. 1066 </p> 1067 <div id="rfc.iref.c.3"></div> 1068 <div id="rfc.iref.h.6"></div> 1069 <h2 id="rfc.section.5.6"><a href="#rfc.section.5.6">5.6</a> <a id="header.content-language" href="#header.content-language">Content-Language</a></h2> 1070 <p id="rfc.section.5.6.p.1">The Content-Language entity-header field describes the natural language(s) of the intended audience for the enclosed entity. 1071 Note that this might not be equivalent to all the languages used within the entity-body. 1072 </p> 1073 <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.27"></span> Content-Language = "Content-Language" ":" 1#language-tag 1074 </pre><p id="rfc.section.5.6.p.3">Language tags are defined in <a href="#language.tags" title="Language Tags">Section 2.5</a>. The primary purpose of Content-Language is to allow a user to identify and differentiate entities according to the user's 1075 own preferred language. Thus, if the body content is intended only for a Danish-literate audience, the appropriate field is 1076 </p> 1077 <div id="rfc.figure.u.27"></div><pre class="text"> Content-Language: da 1078 </pre><p id="rfc.section.5.6.p.5">If no Content-Language is specified, the default is that the content is intended for all language audiences. This might mean 1079 that the sender does not consider it to be specific to any natural language, or that the sender does not know for which language 1080 it is intended. 1081 </p> 1082 <p id="rfc.section.5.6.p.6">Multiple languages <em class="bcp14">MAY</em> be listed for content that is intended for multiple audiences. For example, a rendition of the "Treaty of Waitangi," presented 1083 simultaneously in the original Maori and English versions, would call for 1084 </p> 1085 <div id="rfc.figure.u.28"></div><pre class="text"> Content-Language: mi, en 1086 </pre><p id="rfc.section.5.6.p.8">However, just because multiple languages are present within an entity does not mean that it is intended for multiple linguistic 1087 audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin," which is clearly intended 1088 to be used by an English-literate audience. In this case, the Content-Language would properly only include "en". 1089 </p> 1090 <p id="rfc.section.5.6.p.9">Content-Language <em class="bcp14">MAY</em> be applied to any media type -- it is not limited to textual documents. 1091 </p> 1092 <div id="rfc.iref.c.4"></div> 1093 <div id="rfc.iref.h.7"></div> 1094 <h2 id="rfc.section.5.7"><a href="#rfc.section.5.7">5.7</a> <a id="header.content-location" href="#header.content-location">Content-Location</a></h2> 1095 <p id="rfc.section.5.7.p.1">The Content-Location entity-header field <em class="bcp14">MAY</em> be used to supply the resource location for the entity enclosed in the message when that entity is accessible from a location 1096 separate from the requested resource's URI. A server <em class="bcp14">SHOULD</em> provide a Content-Location for the variant corresponding to the response entity; especially in the case where a resource has 1097 multiple entities associated with it, and those entities actually have separate locations by which they might be individually 1098 accessed, the server <em class="bcp14">SHOULD</em> provide a Content-Location for the particular variant which is returned. 1099 </p> 1100 <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.28"></span> Content-Location = "Content-Location" ":" 1101 ( absoluteURI | relativeURI ) 1102 </pre><p id="rfc.section.5.7.p.3">The value of Content-Location also defines the base URI for the entity.</p> 1103 <p id="rfc.section.5.7.p.4">The Content-Location value is not a replacement for the original requested URI; it is only a statement of the location of 1104 the resource corresponding to this particular entity at the time of the request. Future requests <em class="bcp14">MAY</em> specify the Content-Location URI as the request-URI if the desire is to identify the source of that particular entity. 1105 </p> 1106 <p id="rfc.section.5.7.p.5">A cache cannot assume that an entity with a Content-Location different from the URI used to retrieve it can be used to respond 1107 to later requests on that Content-Location URI. However, the Content-Location can be used to differentiate between multiple 1108 entities retrieved from a single requested resource, as described in <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. 1109 </p> 1110 <p id="rfc.section.5.7.p.6">If the Content-Location is a relative URI, the relative URI is interpreted relative to the Request-URI.</p> 1111 <p id="rfc.section.5.7.p.7">The meaning of the Content-Location header in PUT or POST requests is undefined; servers are free to ignore it in those cases.</p> 1112 <div id="rfc.iref.c.5"></div> 1113 <div id="rfc.iref.h.8"></div> 1114 <h2 id="rfc.section.5.8"><a href="#rfc.section.5.8">5.8</a> <a id="header.content-md5" href="#header.content-md5">Content-MD5</a></h2> 1115 <p id="rfc.section.5.8.p.1">The Content-MD5 entity-header field, as defined in <a href="#RFC1864" id="rfc.xref.RFC1864.1"><cite title="The Content-MD5 Header Field">[RFC1864]</cite></a>, is an MD5 digest of the entity-body for the purpose of providing an end-to-end message integrity check (MIC) of the entity-body. 1116 (Note: a MIC is good for detecting accidental modification of the entity-body in transit, but is not proof against malicious 1117 attacks.) 1118 </p> 1119 <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span> Content-MD5 = "Content-MD5" ":" md5-digest 1120 md5-digest = <base64 of 128 bit MD5 digest as per RFC 1864> 1121 </pre><p id="rfc.section.5.8.p.3">The Content-MD5 header field <em class="bcp14">MAY</em> be generated by an origin server or client to function as an integrity check of the entity-body. Only origin servers or clients <em class="bcp14">MAY</em> generate the Content-MD5 header field; proxies and gateways <em class="bcp14">MUST NOT</em> generate it, as this would defeat its value as an end-to-end integrity check. Any recipient of the entity-body, including 1122 gateways and proxies, <em class="bcp14">MAY</em> check that the digest value in this header field matches that of the entity-body as received. 1123 </p> 1124 <p id="rfc.section.5.8.p.4">The MD5 digest is computed based on the content of the entity-body, including any content-coding that has been applied, but 1125 not including any transfer-encoding applied to the message-body. If the message is received with a transfer-encoding, that 1126 encoding <em class="bcp14">MUST</em> be removed prior to checking the Content-MD5 value against the received entity. 1127 </p> 1128 <p id="rfc.section.5.8.p.5">This has the result that the digest is computed on the octets of the entity-body exactly as, and in the order that, they would 1129 be sent if no transfer-encoding were being applied. 1130 </p> 1131 <p id="rfc.section.5.8.p.6">HTTP extends RFC 1864 to permit the digest to be computed for MIME composite media-types (e.g., multipart/* and message/rfc822), 1132 but this does not change how the digest is computed as defined in the preceding paragraph. 1133 </p> 1134 <p id="rfc.section.5.8.p.7">There are several consequences of this. The entity-body for composite types <em class="bcp14">MAY</em> contain many body-parts, each with its own MIME and HTTP headers (including Content-MD5, Content-Transfer-Encoding, and Content-Encoding 1135 headers). If a body-part has a Content-Transfer-Encoding or Content-Encoding header, it is assumed that the content of the 1136 body-part has had the encoding applied, and the body-part is included in the Content-MD5 digest as is -- i.e., after the application. 1137 The Transfer-Encoding header field is not allowed within body-parts. 1138 </p> 1139 <p id="rfc.section.5.8.p.8">Conversion of all line breaks to CRLF <em class="bcp14">MUST NOT</em> be done before computing or checking the digest: the line break convention used in the text actually transmitted <em class="bcp14">MUST</em> be left unaltered when computing the digest. 1140 </p> 1141 <dl class="empty"> 1142 <dd> <b>Note:</b> while the definition of Content-MD5 is exactly the same for HTTP as in RFC 1864 for MIME entity-bodies, there are several 1143 ways in which the application of Content-MD5 to HTTP entity-bodies differs from its application to MIME entity-bodies. One 1144 is that HTTP, unlike MIME, does not use Content-Transfer-Encoding, and does use Transfer-Encoding and Content-Encoding. Another 1145 is that HTTP more frequently uses binary content types than MIME, so it is worth noting that, in such cases, the byte order 1146 used to compute the digest is the transmission byte order defined for the type. Lastly, HTTP allows transmission of text types 1147 with any of several line break conventions and not just the canonical form using CRLF. 1148 </dd> 1149 </dl> 1150 <div id="rfc.iref.c.6"></div> 1151 <div id="rfc.iref.h.9"></div> 1152 <h2 id="rfc.section.5.9"><a href="#rfc.section.5.9">5.9</a> <a id="header.content-type" href="#header.content-type">Content-Type</a></h2> 1153 <p id="rfc.section.5.9.p.1">The Content-Type entity-header field indicates the media type of the entity-body sent to the recipient or, in the case of 1154 the HEAD method, the media type that would have been sent had the request been a GET. 1155 </p> 1156 <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.31"></span> Content-Type = "Content-Type" ":" media-type 1157 </pre><p id="rfc.section.5.9.p.3">Media types are defined in <a href="#media.types" title="Media Types">Section 2.3</a>. An example of the field is 1158 </p> 1159 <div id="rfc.figure.u.32"></div><pre class="text"> Content-Type: text/html; charset=ISO-8859-4 1160 </pre><p id="rfc.section.5.9.p.5">Further discussion of methods for identifying the media type of an entity is provided in <a href="#type" title="Type">Section 3.2.1</a>. 1161 </p> 1162 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> 1163 <p id="rfc.section.6.p.1">TBD.</p> 1164 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1> 1165 <p id="rfc.section.7.p.1">This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.1 1166 as described by this document. The discussion does not include definitive solutions to the problems revealed, though it does 1167 make some suggestions for reducing security risks. 1168 </p> 1169 <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a> <a id="privacy.issues.connected.to.accept.headers" href="#privacy.issues.connected.to.accept.headers">Privacy Issues Connected to Accept Headers</a></h2> 1170 <p id="rfc.section.7.1.p.1">Accept request-headers can reveal information about the user to all servers which are accessed. The Accept-Language header 1171 in particular can reveal information the user would consider to be of a private nature, because the understanding of particular 1172 languages is often strongly correlated to the membership of a particular ethnic group. User agents which offer the option 1173 to configure the contents of an Accept-Language header to be sent in every request are strongly encouraged to let the configuration 1174 process include a message which makes the user aware of the loss of privacy involved. 1175 </p> 1176 <p id="rfc.section.7.1.p.2">An approach that limits the loss of privacy would be for a user agent to omit the sending of Accept-Language headers by default, 1177 and to ask the user whether or not to start sending Accept-Language headers to a server if it detects, by looking for any 1178 Vary response-header fields generated by the server, that such sending could improve the quality of service. 1179 </p> 1180 <p id="rfc.section.7.1.p.3">Elaborate user-customized accept header fields sent in every request, in particular if these include quality values, can be 1181 used by servers as relatively reliable and long-lived user identifiers. Such user identifiers would allow content providers 1182 to do click-trail tracking, and would allow collaborating content providers to match cross-server click-trails or form submissions 1183 of individual users. Note that for many users not behind a proxy, the network address of the host running the user agent will 1184 also serve as a long-lived user identifier. In environments where proxies are used to enhance privacy, user agents ought to 1185 be conservative in offering accept header configuration options to end users. As an extreme privacy measure, proxies could 1186 filter the accept headers in relayed requests. General purpose user agents which provide a high degree of header configurability <em class="bcp14">SHOULD</em> warn users about the loss of privacy which can be involved. 1187 </p> 1188 <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a> <a id="content-disposition.issues" href="#content-disposition.issues">Content-Disposition Issues</a></h2> 1189 <p id="rfc.section.7.2.p.1"> <a href="#RFC1806" id="rfc.xref.RFC1806.1"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header">[RFC1806]</cite></a>, from which the often implemented Content-Disposition (see <a href="#content-disposition" id="rfc.xref.content-disposition.1" title="Content-Disposition">Appendix B.1</a>) header in HTTP is derived, has a number of very serious security considerations. Content-Disposition is not part of the 1190 HTTP standard, but since it is widely implemented, we are documenting its use and risks for implementors. See <a href="#RFC2183" id="rfc.xref.RFC2183.1"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a> (which updates <a href="#RFC1806" id="rfc.xref.RFC1806.2"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header">[RFC1806]</cite></a>) for details. 1191 </p> 1192 <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="ack" href="#ack">Acknowledgments</a></h1> 1193 <h1 id="rfc.references"><a href="#rfc.section.9" id="rfc.section.9">9.</a> References 1194 </h1> 1195 <table summary="References"> 1196 <tr> 1197 <td class="reference"><b id="Part1">[Part1]</b></td> 1198 <td class="top"><a title="Day Software">Fielding, R., Ed.</a>, <a title="One Laptop per Child">Gettys, J.</a>, <a title="Hewlett-Packard Company">Mogul, J.</a>, <a title="Microsoft Corporation">Frystyk, H.</a>, <a title="Adobe Systems, Incorporated">Masinter, L.</a>, <a title="Microsoft Corporation">Leach, P.</a>, <a title="World Wide Web Consortium">Berners-Lee, T.</a>, <a title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a title="greenbytes GmbH">J. F. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-latest">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</a>”, Internet-Draft draft-ietf-httpbis-p1-messaging-latest (work in progress), December 2007. 1199 </td> 1200 </tr> 1201 <tr> 1202 <td class="reference"><b id="Part2">[Part2]</b></td> 1203 <td class="top"><a title="Day Software">Fielding, R., Ed.</a>, <a title="One Laptop per Child">Gettys, J.</a>, <a title="Hewlett-Packard Company">Mogul, J.</a>, <a title="Microsoft Corporation">Frystyk, H.</a>, <a title="Adobe Systems, Incorporated">Masinter, L.</a>, <a title="Microsoft Corporation">Leach, P.</a>, <a title="World Wide Web Consortium">Berners-Lee, T.</a>, <a title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a title="greenbytes GmbH">J. F. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-latest">HTTP/1.1, part 2: Message Semantics</a>”, Internet-Draft draft-ietf-httpbis-p2-semantics-latest (work in progress), December 2007. 1204 </td> 1205 </tr> 1206 <tr> 1207 <td class="reference"><b id="Part4">[Part4]</b></td> 1208 <td class="top"><a title="Day Software">Fielding, R., Ed.</a>, <a title="One Laptop per Child">Gettys, J.</a>, <a title="Hewlett-Packard Company">Mogul, J.</a>, <a title="Microsoft Corporation">Frystyk, H.</a>, <a title="Adobe Systems, Incorporated">Masinter, L.</a>, <a title="Microsoft Corporation">Leach, P.</a>, <a title="World Wide Web Consortium">Berners-Lee, T.</a>, <a title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a title="greenbytes GmbH">J. F. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-latest">HTTP/1.1, part 4: Conditional Requests</a>”, Internet-Draft draft-ietf-httpbis-p4-conditional-latest (work in progress), December 2007. 1209 </td> 1210 </tr> 1211 <tr> 1212 <td class="reference"><b id="Part5">[Part5]</b></td> 1213 <td class="top"><a title="Day Software">Fielding, R., Ed.</a>, <a title="One Laptop per Child">Gettys, J.</a>, <a title="Hewlett-Packard Company">Mogul, J.</a>, <a title="Microsoft Corporation">Frystyk, H.</a>, <a title="Adobe Systems, Incorporated">Masinter, L.</a>, <a title="Microsoft Corporation">Leach, P.</a>, <a title="World Wide Web Consortium">Berners-Lee, T.</a>, <a title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a title="greenbytes GmbH">J. F. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-latest">HTTP/1.1, part 5: Range Requests and Partial Responses</a>”, Internet-Draft draft-ietf-httpbis-p5-range-latest (work in progress), December 2007. 1214 </td> 1215 </tr> 1216 <tr> 1217 <td class="reference"><b id="Part6">[Part6]</b></td> 1218 <td class="top"><a title="Day Software">Fielding, R., Ed.</a>, <a title="One Laptop per Child">Gettys, J.</a>, <a title="Hewlett-Packard Company">Mogul, J.</a>, <a title="Microsoft Corporation">Frystyk, H.</a>, <a title="Adobe Systems, Incorporated">Masinter, L.</a>, <a title="Microsoft Corporation">Leach, P.</a>, <a title="World Wide Web Consortium">Berners-Lee, T.</a>, <a title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a title="greenbytes GmbH">J. F. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-latest">HTTP/1.1, part 6: Caching</a>”, Internet-Draft draft-ietf-httpbis-p6-cache-latest (work in progress), December 2007. 1219 </td> 1220 </tr> 1221 <tr> 1222 <td class="reference"><b id="RFC1766">[RFC1766]</b></td> 1223 <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. 1224 </td> 1225 </tr> 1226 <tr> 1227 <td class="reference"><b id="RFC1806">[RFC1806]</b></td> 1228 <td class="top"><a title="New Century Systems">Troost, R.</a> and <a title="QUALCOMM Incorporated">S. Dorner</a>, “<a href="http://tools.ietf.org/html/rfc1806">Communicating Presentation Information in Internet Messages: The Content-Disposition Header</a>”, RFC 1806, June 1995. 1229 </td> 1230 </tr> 1231 <tr> 1232 <td class="reference"><b id="RFC1864">[RFC1864]</b></td> 1233 <td class="top"><a title="Carnegie Mellon University">Myers, J.</a> and <a title="Dover Beach Consulting, Inc.">M. Rose</a>, “<a href="http://tools.ietf.org/html/rfc1864">The Content-MD5 Header Field</a>”, RFC 1864, October 1995. 1234 </td> 1235 </tr> 1236 <tr> 1237 <td class="reference"><b id="RFC1867">[RFC1867]</b></td> 1238 <td class="top"><a title="Xerox Palo Alto Research Center">Masinter, L.</a> and <a title="XSoft, Xerox Corporation">E. Nebel</a>, “<a href="http://tools.ietf.org/html/rfc1867">Form-based File Upload in HTML</a>”, RFC 1867, November 1995. 1239 </td> 1240 </tr> 1241 <tr> 1242 <td class="reference"><b id="RFC1945">[RFC1945]</b></td> 1243 <td class="top"><a title="MIT, Laboratory for Computer Science">Berners-Lee, T.</a>, <a title="University of California, Irvine, Department of Information and Computer Science">Fielding, R.T.</a>, and <a title="W3 Consortium, MIT Laboratory for Computer Science">H.F. Nielsen</a>, “<a href="http://tools.ietf.org/html/rfc1945">Hypertext Transfer Protocol -- HTTP/1.0</a>”, RFC 1945, May 1996. 1244 </td> 1245 </tr> 1246 <tr> 1247 <td class="reference"><b id="RFC1950">[RFC1950]</b></td> 1248 <td class="top"><a title="Aladdin Enterprises">Deutsch, L.P.</a> and J-L. Gailly, “<a href="http://tools.ietf.org/html/rfc1950">ZLIB Compressed Data Format Specification version 3.3</a>”, RFC 1950, May 1996. 1249 </td> 1250 </tr> 1251 <tr> 1252 <td class="reference"><b id="RFC1951">[RFC1951]</b></td> 1253 <td class="top"><a title="Aladdin Enterprises">Deutsch, P.</a>, “<a href="http://tools.ietf.org/html/rfc1951">DEFLATE Compressed Data Format Specification version 1.3</a>”, RFC 1951, May 1996. 1254 </td> 1255 </tr> 1256 <tr> 1257 <td class="reference"><b id="RFC1952">[RFC1952]</b></td> 1258 <td class="top"><a title="Aladdin Enterprises">Deutsch, P.</a>, <a>Gailly, J-L.</a>, <a>Adler, M.</a>, <a>Deutsch, L.P.</a>, and <a>G. Randers-Pehrson</a>, “<a href="http://tools.ietf.org/html/rfc1952">GZIP file format specification version 4.3</a>”, RFC 1952, May 1996. 1259 </td> 1260 </tr> 1261 <tr> 1262 <td class="reference"><b id="RFC2045">[RFC2045]</b></td> 1263 <td class="top"><a title="Innosoft International, Inc.">Freed, N.</a> and <a title="First Virtual Holdings">N.S. Borenstein</a>, “<a href="http://tools.ietf.org/html/rfc2045">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</a>”, RFC 2045, November 1996. 1264 </td> 1265 </tr> 1266 <tr> 1267 <td class="reference"><b id="RFC2046">[RFC2046]</b></td> 1268 <td class="top"><a title="Innosoft International, Inc.">Freed, N.</a> and <a title="First Virtual Holdings">N. Borenstein</a>, “<a href="http://tools.ietf.org/html/rfc2046">Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</a>”, RFC 2046, November 1996. 1269 </td> 1270 </tr> 1271 <tr> 1272 <td class="reference"><b id="RFC2049">[RFC2049]</b></td> 1273 <td class="top"><a title="Innosoft International, Inc.">Freed, N.</a> and <a title="First Virtual Holdings">N.S. Borenstein</a>, “<a href="http://tools.ietf.org/html/rfc2049">Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples</a>”, RFC 2049, November 1996. 1274 </td> 1275 </tr> 1276 <tr> 1277 <td class="reference"><b id="RFC2068">[RFC2068]</b></td> 1278 <td class="top"><a title="University of California, Irvine, Department of Information and Computer Science">Fielding, R.</a>, <a title="MIT Laboratory for Computer Science">Gettys, J.</a>, <a title="Digital Equipment Corporation, Western Research Laboratory">Mogul, J.</a>, <a title="MIT Laboratory for Computer Science">Nielsen, H.</a>, and <a title="MIT Laboratory for Computer Science">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2068">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC 2068, January 1997. 1279 </td> 1280 </tr> 1281 <tr> 1282 <td class="reference"><b id="RFC2076">[RFC2076]</b></td> 1283 <td class="top"><a title="Stockholm University/KTH">Palme, J.</a>, “<a href="http://tools.ietf.org/html/rfc2076">Common Internet Message Headers</a>”, RFC 2076, February 1997. 1284 </td> 1285 </tr> 1286 <tr> 1287 <td class="reference"><b id="RFC2110">[RFC2110]</b></td> 1288 <td class="top"><a title="Stockholm University and KTH">Palme, J.</a> and <a title="Microsoft Corporation">A. Hopmann</a>, “<a href="http://tools.ietf.org/html/rfc2110">MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)</a>”, RFC 2110, March 1997. 1289 </td> 1290 </tr> 1291 <tr> 1292 <td class="reference"><b id="RFC2119">[RFC2119]</b></td> 1293 <td class="top"><a title="Harvard University">Bradner, S.</a>, “<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>”, BCP 14, RFC 2119, March 1997. 1294 </td> 1295 </tr> 1296 <tr> 1297 <td class="reference"><b id="RFC2183">[RFC2183]</b></td> 1298 <td class="top"><a title="New Century Systems">Troost, R.</a>, <a title="QUALCOMM Incorporated">Dorner, S.</a>, and <a title="Department of Computer Science">K. Moore</a>, “<a href="http://tools.ietf.org/html/rfc2183">Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field</a>”, RFC 2183, August 1997. 1299 </td> 1300 </tr> 1301 <tr> 1302 <td class="reference"><b id="RFC2277">[RFC2277]</b></td> 1303 <td class="top"><a title="UNINETT">Alvestrand, H.T.</a>, “<a href="http://tools.ietf.org/html/rfc2277">IETF Policy on Character Sets and Languages</a>”, BCP 18, RFC 2277, January 1998. 1304 </td> 1305 </tr> 1306 <tr> 1307 <td class="reference"><b id="RFC2279">[RFC2279]</b></td> 1308 <td class="top"><a title="Alis Technologies">Yergeau, F.</a>, “<a href="http://tools.ietf.org/html/rfc2279">UTF-8, a transformation format of ISO 10646</a>”, RFC 2279, January 1998. 1309 </td> 1310 </tr> 1311 <tr> 1312 <td class="reference"><b id="RFC2616">[RFC2616]</b></td> 1313 <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. 1314 </td> 1315 </tr> 1316 <tr> 1317 <td class="reference"><b id="RFC4288">[RFC4288]</b></td> 1318 <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. 1319 </td> 1320 </tr> 1321 <tr> 1322 <td class="reference"><b id="RFC822">[RFC822]</b></td> 1323 <td class="top"><a title="University of Delaware, Dept. of Electrical Engineering">Crocker, D.H.</a>, “<a href="http://tools.ietf.org/html/rfc822">Standard for the format of ARPA Internet text messages</a>”, STD 11, RFC 822, August 1982. 1324 </td> 1325 </tr> 1326 </table> 1327 <h1 id="rfc.authors"><a href="#rfc.authors">Authors' Addresses</a></h1> 1328 <address class="vcard"><span class="vcardline"><span class="fn">Roy T. Fielding</span> 1329 (editor) 1330 <span class="n hidden"><span class="family-name">Fielding</span><span class="given-name">Roy T.</span></span></span><span class="org vcardline">Day Software</span><span class="adr"><span class="street-address vcardline">23 Corporate Plaza DR, Suite 280</span><span class="vcardline"><span class="locality">Newport Beach</span>, <span class="region">CA</span> <span class="postal-code">92660</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline tel">Phone: <a href="tel:+1-949-706-5300"><span class="value">+1-949-706-5300</span></a></span><span class="vcardline tel"><span class="type">Fax</span>: <a href="fax:+1-949-706-5305"><span class="value">+1-949-706-5305</span></a></span><span class="vcardline">EMail: <a><span class="email">fielding@gbiv.com</span></a></span><span class="vcardline">URI: <a href="http://roy.gbiv.com/" class="url">http://roy.gbiv.com/</a></span></address> 1331 <address class="vcard"><span class="vcardline"><span class="fn">Jim Gettys</span><span class="n hidden"><span class="family-name">Gettys</span><span class="given-name">Jim</span></span></span><span class="org vcardline">One Laptop per Child</span><span class="adr"><span class="street-address vcardline">21 Oak Knoll Road</span><span class="vcardline"><span class="locality">Carlisle</span>, <span class="region">MA</span> <span class="postal-code">01741</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">EMail: <a><span class="email">jg@laptop.org</span></a></span><span class="vcardline">URI: <a href="http://www.laptop.org/" class="url">http://www.laptop.org/</a></span></address> 1332 <address class="vcard"><span class="vcardline"><span class="fn">Jeffrey C. Mogul</span><span class="n hidden"><span class="family-name">Mogul</span><span class="given-name">Jeffrey C.</span></span></span><span class="org vcardline">Hewlett-Packard Company</span><span class="adr"><span class="street-address vcardline">HP Labs, Large Scale Systems Group</span><span class="street-address vcardline">1501 Page Mill Road, MS 1177</span><span class="vcardline"><span class="locality">Palo Alto</span>, <span class="region">CA</span> <span class="postal-code">94304</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">EMail: <a><span class="email">JeffMogul@acm.org</span></a></span></address> 1333 <address class="vcard"><span class="vcardline"><span class="fn">Henrik Frystyk Nielsen</span><span class="n hidden"><span class="family-name">Frystyk</span></span></span><span class="org vcardline">Microsoft Corporation</span><span class="adr"><span class="street-address vcardline">1 Microsoft Way</span><span class="vcardline"><span class="locality">Redmond</span>, <span class="region">WA</span> <span class="postal-code">98052</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">EMail: <a><span class="email">henrikn@microsoft.com</span></a></span></address> 1334 <address class="vcard"><span class="vcardline"><span class="fn">Larry Masinter</span><span class="n hidden"><span class="family-name">Masinter</span><span class="given-name">Larry</span></span></span><span class="org vcardline">Adobe Systems, Incorporated</span><span class="adr"><span class="street-address vcardline">345 Park Ave</span><span class="vcardline"><span class="locality">San Jose</span>, <span class="region">CA</span> <span class="postal-code">95110</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">EMail: <a><span class="email">LMM@acm.org</span></a></span><span class="vcardline">URI: <a href="http://larry.masinter.net/" class="url">http://larry.masinter.net/</a></span></address> 1335 <address class="vcard"><span class="vcardline"><span class="fn">Paul J. Leach</span><span class="n hidden"><span class="family-name">Leach</span><span class="given-name">Paul J.</span></span></span><span class="org vcardline">Microsoft Corporation</span><span class="adr"><span class="street-address vcardline">1 Microsoft Way</span><span class="vcardline"><span class="locality">Redmond</span>, <span class="region">WA</span> <span class="postal-code">98052</span></span></span><span class="vcardline">EMail: <a><span class="email">paulle@microsoft.com</span></a></span></address> 1336 <address class="vcard"><span class="vcardline"><span class="fn">Tim Berners-Lee</span><span class="n hidden"><span class="family-name">Berners-Lee</span><span class="given-name">Tim</span></span></span><span class="org vcardline">World Wide Web Consortium</span><span class="adr"><span class="street-address vcardline">MIT Computer Science and Artificial Intelligence Laboratory</span><span class="street-address vcardline">The Stata Center, Building 32</span><span class="street-address vcardline">32 Vassar Street</span><span class="vcardline"><span class="locality">Cambridge</span>, <span class="region">MA</span> <span class="postal-code">02139</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">EMail: <a><span class="email">timbl@w3.org</span></a></span><span class="vcardline">URI: <a href="http://www.w3.org/People/Berners-Lee/" class="url">http://www.w3.org/People/Berners-Lee/</a></span></address> 1337 <address class="vcard"><span class="vcardline"><span class="fn">Yves Lafon</span> 1338 (editor) 1339 <span class="n hidden"><span class="family-name">Lafon</span><span class="given-name">Yves</span></span></span><span class="org vcardline">World Wide Web Consortium</span><span class="adr"><span class="street-address vcardline">W3C / ERCIM</span><span class="street-address vcardline">2004, rte des Lucioles</span><span class="vcardline"><span class="locality">Sophia-Antipolis</span>, <span class="region">AM</span> <span class="postal-code">06902</span></span><span class="country-name vcardline">France</span></span><span class="vcardline">EMail: <a><span class="email">ylafon@w3.org</span></a></span><span class="vcardline">URI: <a href="http://www.raubacapeu.net/people/yves/" class="url">http://www.raubacapeu.net/people/yves/</a></span></address> 1340 <address class="vcard"><span class="vcardline"><span class="fn">Julian F. Reschke</span> 1341 (editor) 1342 <span class="n hidden"><span class="family-name">Reschke</span><span class="given-name">Julian F.</span></span></span><span class="org vcardline">greenbytes GmbH</span><span class="adr"><span class="street-address vcardline">Hafenweg 16</span><span class="vcardline"><span class="locality">Muenster</span>, <span class="region">NW</span> <span class="postal-code">48155</span></span><span class="country-name vcardline">Germany</span></span><span class="vcardline tel">Phone: <a href="tel:+492512807760"><span class="value">+49 251 2807760</span></a></span><span class="vcardline tel"><span class="type">Fax</span>: <a href="fax:+492512807761"><span class="value">+49 251 2807761</span></a></span><span class="vcardline">EMail: <a><span class="email">julian.reschke@greenbytes.de</span></a></span><span class="vcardline">URI: <a href="http://greenbytes.de/tech/webdav/" class="url">http://greenbytes.de/tech/webdav/</a></span></address> 1343 <h1 id="rfc.section.A"><a href="#rfc.section.A">A.</a> <a id="differences.between.http.entities.and.rfc.2045.entities" href="#differences.between.http.entities.and.rfc.2045.entities">Differences Between HTTP Entities and RFC 2045 Entities</a></h1> 1344 <p id="rfc.section.A.p.1">HTTP/1.1 uses many of the constructs defined for Internet Mail (<a href="#RFC822" id="rfc.xref.RFC822.1"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a>) and the Multipurpose Internet Mail Extensions (MIME <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>) to allow entities to be transmitted in an open variety of representations and with extensible mechanisms. However, RFC 2045 1345 discusses mail, and HTTP has a few features that are different from those described in RFC 2045. These differences were carefully 1346 chosen to optimize performance over binary connections, to allow greater freedom in the use of new media types, to make date 1347 comparisons easier, and to acknowledge the practice of some early HTTP servers and clients. 1348 </p> 1349 <p id="rfc.section.A.p.2">This appendix describes specific areas where HTTP differs from RFC 2045. Proxies and gateways to strict MIME environments <em class="bcp14">SHOULD</em> be aware of these differences and provide the appropriate conversions where necessary. Proxies and gateways from MIME environments 1350 to HTTP also need to be aware of the differences because some conversions might be required. 1351 </p> 1352 <h2 id="rfc.section.A.1"><a href="#rfc.section.A.1">A.1</a> <a id="mime-version" href="#mime-version">MIME-Version</a></h2> 1353 <p id="rfc.section.A.1.p.1">HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages <em class="bcp14">MAY</em> include a single MIME-Version general-header field to indicate what version of the MIME protocol was used to construct the 1354 message. Use of the MIME-Version header field indicates that the message is in full compliance with the MIME protocol (as 1355 defined in RFC 2045<a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>). Proxies/gateways are responsible for ensuring full compliance (where possible) when exporting HTTP messages to strict MIME 1356 environments. 1357 </p> 1358 <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.32"></span> MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT 1359 </pre><p id="rfc.section.A.1.p.3">MIME version "1.0" is the default for use in HTTP/1.1. However, HTTP/1.1 message parsing and semantics are defined by this 1360 document and not the MIME specification. 1361 </p> 1362 <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a> <a id="conversion.to.canonical.form" href="#conversion.to.canonical.form">Conversion to Canonical Form</a></h2> 1363 <p id="rfc.section.A.2.p.1"> <a href="#RFC2045" id="rfc.xref.RFC2045.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> requires that an Internet mail entity be converted to canonical form prior to being transferred, as described in section <a href="http://tools.ietf.org/html/rfc2049#section-4">Section 4</a> of <a href="#RFC2049" id="rfc.xref.RFC2049.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples">[RFC2049]</cite></a>. <a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section 2.3.1</a> of this document describes the forms allowed for subtypes of the "text" media type when transmitted over HTTP. <a href="#RFC2046" id="rfc.xref.RFC2046.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> requires that content with a type of "text" represent line breaks as CRLF and forbids the use of CR or LF outside of line 1364 break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a line break within text content when a message is transmitted 1365 over HTTP. 1366 </p> 1367 <p id="rfc.section.A.2.p.2">Where it is possible, a proxy or gateway from HTTP to a strict MIME environment <em class="bcp14">SHOULD</em> translate all line breaks within the text media types described in <a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section 2.3.1</a> of this document to the RFC 2049 canonical form of CRLF. Note, however, that this might be complicated by the presence of 1368 a Content-Encoding and by the fact that HTTP allows the use of some character sets which do not use octets 13 and 10 to represent 1369 CR and LF, as is the case for some multi-byte character sets. 1370 </p> 1371 <p id="rfc.section.A.2.p.3">Implementors should note that conversion will break any cryptographic checksums applied to the original content unless the 1372 original content is already in canonical form. Therefore, the canonical form is recommended for any content that uses such 1373 checksums in HTTP. 1374 </p> 1375 <h2 id="rfc.section.A.3"><a href="#rfc.section.A.3">A.3</a> <a id="introduction.of.content-encoding" href="#introduction.of.content-encoding">Introduction of Content-Encoding</a></h2> 1376 <p id="rfc.section.A.3.p.1">RFC 2045 does not include any concept equivalent to HTTP/1.1's Content-Encoding header field. Since this acts as a modifier 1377 on the media type, proxies and gateways from HTTP to MIME-compliant protocols <em class="bcp14">MUST</em> either change the value of the Content-Type header field or decode the entity-body before forwarding the message. (Some experimental 1378 applications of Content-Type for Internet mail have used a media-type parameter of ";conversions=<content-coding>" to perform 1379 a function equivalent to Content-Encoding. However, this parameter is not part of RFC 2045). 1380 </p> 1381 <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> 1382 <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. 1383 </p> 1384 <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 1385 format and encoding for safe transport on that protocol, where "safe transport" is defined by the limitations of the protocol 1386 being used. Such a proxy or gateway <em class="bcp14">SHOULD</em> label the data with an appropriate Content-Transfer-Encoding if doing so will improve the likelihood of safe transport over 1387 the destination protocol. 1388 </p> 1389 <h2 id="rfc.section.A.5"><a href="#rfc.section.A.5">A.5</a> <a id="introduction.of.transfer-encoding" href="#introduction.of.transfer-encoding">Introduction of Transfer-Encoding</a></h2> 1390 <p id="rfc.section.A.5.p.1">HTTP/1.1 introduces the Transfer-Encoding header field (<a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 8.7</a> of <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Proxies/gateways <em class="bcp14">MUST</em> remove any transfer-coding prior to forwarding a message via a MIME-compliant protocol. 1391 </p> 1392 <h2 id="rfc.section.A.6"><a href="#rfc.section.A.6">A.6</a> <a id="mhtml.line.length" href="#mhtml.line.length">MHTML and Line Length Limitations</a></h2> 1393 <p id="rfc.section.A.6.p.1">HTTP implementations which share code with MHTML <a href="#RFC2110" id="rfc.xref.RFC2110.1"><cite title="MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2110]</cite></a> implementations need to be aware of MIME line length limitations. Since HTTP does not have this limitation, HTTP does not 1394 fold long lines. MHTML messages being transported by HTTP follow all conventions of MHTML, including line length limitations 1395 and folding, canonicalization, etc., since HTTP transports all message-bodies as payload (see <a href="#multipart.types" title="Multipart Types">Section 2.3.2</a>) and does not interpret the content or any MIME header lines that might be contained therein. 1396 </p> 1397 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="additional.features" href="#additional.features">Additional Features</a></h1> 1398 <p id="rfc.section.B.p.1"> <a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a> and <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> document protocol elements used by some existing HTTP implementations, but not consistently and correctly across most HTTP/1.1 1399 applications. Implementors are advised to be aware of these features, but cannot rely upon their presence in, or interoperability 1400 with, other HTTP/1.1 applications. Some of these describe proposed experimental features, and some describe features that 1401 experimental deployment found lacking that are now addressed in the base HTTP/1.1 specification. 1402 </p> 1403 <p id="rfc.section.B.p.2">A number of other headers, such as Content-Disposition and Title, from SMTP and MIME are also often implemented (see <a href="#RFC2076" id="rfc.xref.RFC2076.1"><cite title="Common Internet Message Headers">[RFC2076]</cite></a>). 1404 </p> 1405 <div id="rfc.iref.h.10"></div> 1406 <div id="rfc.iref.c.7"></div> 1407 <h2 id="rfc.section.B.1"><a href="#rfc.section.B.1">B.1</a> <a id="content-disposition" href="#content-disposition">Content-Disposition</a></h2> 1408 <p id="rfc.section.B.1.p.1">The Content-Disposition response-header field has been proposed as a means for the origin server to suggest a default filename 1409 if the user requests that the content is saved to a file. This usage is derived from the definition of Content-Disposition 1410 in <a href="#RFC1806" id="rfc.xref.RFC1806.3"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header">[RFC1806]</cite></a>. 1411 </p> 1412 <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.33"></span><span id="rfc.iref.g.34"></span><span id="rfc.iref.g.35"></span><span id="rfc.iref.g.36"></span><span id="rfc.iref.g.37"></span><span id="rfc.iref.g.38"></span> content-disposition = "Content-Disposition" ":" 1413 disposition-type *( ";" disposition-parm ) 1414 disposition-type = "attachment" | disp-extension-token 1415 disposition-parm = filename-parm | disp-extension-parm 1416 filename-parm = "filename" "=" quoted-string 1417 disp-extension-token = token 1418 disp-extension-parm = token "=" ( token | quoted-string ) 1419 </pre><p id="rfc.section.B.1.p.3">An example is</p> 1420 <div id="rfc.figure.u.35"></div><pre class="text"> Content-Disposition: attachment; filename="fname.ext" 1421 </pre><p id="rfc.section.B.1.p.5">The receiving user agent <em class="bcp14">SHOULD NOT</em> respect any directory path information present in the filename-parm parameter, which is the only parameter believed to apply 1422 to HTTP implementations at this time. The filename <em class="bcp14">SHOULD</em> be treated as a terminal component only. 1423 </p> 1424 <p id="rfc.section.B.1.p.6">If this header is used in a response with the application/octet-stream content-type, the implied suggestion is that the user 1425 agent should not display the response, but directly enter a `save response as...' dialog. 1426 </p> 1427 <p id="rfc.section.B.1.p.7">See <a href="#content-disposition.issues" title="Content-Disposition Issues">Section 7.2</a> for Content-Disposition security issues. 1428 </p> 1429 <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a> <a id="changes.from.rfc.2068" href="#changes.from.rfc.2068">Changes from RFC 2068</a></h1> 1430 <p id="rfc.section.C.p.1">Charset wildcarding is introduced to avoid explosion of character set names in accept headers. (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.2" title="Accept-Charset">Section 5.2</a>) 1431 </p> 1432 <p id="rfc.section.C.p.2">Content-Base was deleted from the specification: it was not implemented widely, and there is no simple, safe way to introduce 1433 it without a robust extension mechanism. In addition, it is used in a similar, but not identical fashion in MHTML <a href="#RFC2110" id="rfc.xref.RFC2110.2"><cite title="MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2110]</cite></a>. 1434 </p> 1435 <p id="rfc.section.C.p.3">A content-coding of "identity" was introduced, to solve problems discovered in caching. (<a href="#content.codings" title="Content Codings">Section 2.2</a>) 1436 </p> 1437 <p id="rfc.section.C.p.4">Quality Values of zero should indicate that "I don't want something" to allow clients to refuse a representation. (<a href="#quality.values" title="Quality Values">Section 2.4</a>) 1438 </p> 1439 <p id="rfc.section.C.p.5">The Alternates<span id="rfc.iref.a.5"></span><span id="rfc.iref.h.11"></span>, Content-Version<span id="rfc.iref.c.8"></span><span id="rfc.iref.h.12"></span>, Derived-From<span id="rfc.iref.d.2"></span><span id="rfc.iref.h.13"></span>, Link<span id="rfc.iref.l.1"></span><span id="rfc.iref.h.14"></span>, URI<span id="rfc.iref.u.1"></span><span id="rfc.iref.h.15"></span>, Public<span id="rfc.iref.p.1"></span><span id="rfc.iref.h.16"></span> and Content-Base<span id="rfc.iref.c.9"></span><span id="rfc.iref.h.17"></span> header fields were defined in previous versions of this specification, but not commonly implemented. See <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>. 1440 </p> 1441 <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1> 1442 <p>Copyright © The IETF Trust (2007).</p> 1443 <p>This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the 1444 authors retain all their rights. 1445 </p> 1446 <p>This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION 1447 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE 1448 DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 1449 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1450 </p> 1451 <h1><a id="rfc.ipr" href="#rfc.ipr">Intellectual Property</a></h1> 1452 <p>The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might 1453 be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any 1454 license under such rights might or might not be available; nor does it represent that it has made any independent effort to 1455 identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and 1456 BCP 79. 1457 </p> 1458 <p>Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result 1459 of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users 1460 of this specification can be obtained from the IETF on-line IPR repository at <<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>>. 1461 </p> 1462 <p>The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary 1463 rights that may cover technology that may be required to implement this standard. Please address the information to the IETF 1464 at <a href="mailto:ietf-ipr@ietf.org">ietf-ipr@ietf.org</a>. 1465 </p> 1466 <h1>Acknowledgement</h1> 1467 <p>Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).</p> 1468 <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> 1469 <p class="noprint"><a href="#rfc.index.A">A</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.D">D</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.L">L</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.U">U</a> 1470 </p> 1471 <div class="print2col"> 1472 <ul class="ind"> 1473 <li class="indline0"><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul class="ind"> 1474 <li class="indline1">Accept header <a class="iref" href="#rfc.xref.header.accept.1">2.3</a>, <a class="iref" href="#rfc.xref.header.accept.2">4.1</a>, <a class="iref" href="#rfc.iref.a.1"><b>5.1</b></a></li> 1475 <li class="indline1">Accept-Charset header <a class="iref" href="#rfc.xref.header.accept-charset.1">4.1</a>, <a class="iref" href="#rfc.iref.a.2"><b>5.2</b></a>, <a class="iref" href="#rfc.xref.header.accept-charset.2">C</a></li> 1476 <li class="indline1">Accept-Encoding header <a class="iref" href="#rfc.xref.header.accept-encoding.1">2.2</a>, <a class="iref" href="#rfc.xref.header.accept-encoding.2">4.1</a>, <a class="iref" href="#rfc.iref.a.3"><b>5.3</b></a></li> 1477 <li class="indline1">Accept-Language header <a class="iref" href="#rfc.xref.header.accept-language.1">4.1</a>, <a class="iref" href="#rfc.iref.a.4"><b>5.4</b></a></li> 1478 <li class="indline1">Alternates header <a class="iref" href="#rfc.iref.a.5"><b>C</b></a></li> 1479 </ul> 1480 </li> 1481 <li class="indline0"><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul class="ind"> 1482 <li class="indline1">compress <a class="iref" href="#rfc.iref.c.1">2.2</a></li> 1483 <li class="indline1">Content-Base header <a class="iref" href="#rfc.iref.c.9"><b>C</b></a></li> 1484 <li class="indline1">Content-Disposition header <a class="iref" href="#rfc.xref.content-disposition.1">7.2</a>, <a class="iref" href="#rfc.iref.c.7"><b>B.1</b></a></li> 1485 <li class="indline1">Content-Encoding header <a class="iref" href="#rfc.xref.header.content-encoding.1">2.2</a>, <a class="iref" href="#rfc.xref.header.content-encoding.2">3.1</a>, <a class="iref" href="#rfc.iref.c.2"><b>5.5</b></a>, <a class="iref" href="#rfc.xref.header.content-encoding.3">5.5</a></li> 1486 <li class="indline1">Content-Language header <a class="iref" href="#rfc.xref.header.content-language.1">3.1</a>, <a class="iref" href="#rfc.iref.c.3"><b>5.6</b></a></li> 1487 <li class="indline1">Content-Location header <a class="iref" href="#rfc.xref.header.content-location.1">3.1</a>, <a class="iref" href="#rfc.iref.c.4"><b>5.7</b></a></li> 1488 <li class="indline1">Content-MD5 header <a class="iref" href="#rfc.xref.header.content-md5.1">3.1</a>, <a class="iref" href="#rfc.iref.c.5"><b>5.8</b></a></li> 1489 <li class="indline1">Content-Type header <a class="iref" href="#rfc.xref.header.content-type.1">2.3</a>, <a class="iref" href="#rfc.xref.header.content-type.2">3.1</a>, <a class="iref" href="#rfc.iref.c.6"><b>5.9</b></a></li> 1490 <li class="indline1">Content-Version header <a class="iref" href="#rfc.iref.c.8"><b>C</b></a></li> 1491 </ul> 1492 </li> 1493 <li class="indline0"><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul class="ind"> 1494 <li class="indline1">deflate <a class="iref" href="#rfc.iref.d.1">2.2</a></li> 1495 <li class="indline1">Derived-From header <a class="iref" href="#rfc.iref.d.2"><b>C</b></a></li> 1496 </ul> 1497 </li> 1498 <li class="indline0"><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul class="ind"> 1499 <li class="indline1"><tt>Grammar</tt> 1500 <ul class="ind"> 1501 <li class="indline1"><tt>Accept</tt> <a class="iref" href="#rfc.iref.g.17"><b>5.1</b></a></li> 1502 <li class="indline1"><tt>Accept-Charset</tt> <a class="iref" href="#rfc.iref.g.21"><b>5.2</b></a></li> 1503 <li class="indline1"><tt>Accept-Encoding</tt> <a class="iref" href="#rfc.iref.g.22"><b>5.3</b></a></li> 1504 <li class="indline1"><tt>accept-extension</tt> <a class="iref" href="#rfc.iref.g.20"><b>5.1</b></a></li> 1505 <li class="indline1"><tt>Accept-Language</tt> <a class="iref" href="#rfc.iref.g.24"><b>5.4</b></a></li> 1506 <li class="indline1"><tt>accept-params</tt> <a class="iref" href="#rfc.iref.g.19"><b>5.1</b></a></li> 1507 <li class="indline1"><tt>attribute</tt> <a class="iref" href="#rfc.iref.g.8"><b>2.3</b></a></li> 1508 <li class="indline1"><tt>charset</tt> <a class="iref" href="#rfc.iref.g.1"><b>2.1</b></a></li> 1509 <li class="indline1"><tt>codings</tt> <a class="iref" href="#rfc.iref.g.23"><b>5.3</b></a></li> 1510 <li class="indline1"><tt>content-coding</tt> <a class="iref" href="#rfc.iref.g.2"><b>2.2</b></a></li> 1511 <li class="indline1"><tt>content-disposition</tt> <a class="iref" href="#rfc.iref.g.33"><b>B.1</b></a></li> 1512 <li class="indline1"><tt>Content-Encoding</tt> <a class="iref" href="#rfc.iref.g.26"><b>5.5</b></a></li> 1513 <li class="indline1"><tt>Content-Language</tt> <a class="iref" href="#rfc.iref.g.27"><b>5.6</b></a></li> 1514 <li class="indline1"><tt>Content-Location</tt> <a class="iref" href="#rfc.iref.g.28"><b>5.7</b></a></li> 1515 <li class="indline1"><tt>Content-MD5</tt> <a class="iref" href="#rfc.iref.g.29"><b>5.8</b></a></li> 1516 <li class="indline1"><tt>Content-Type</tt> <a class="iref" href="#rfc.iref.g.31"><b>5.9</b></a></li> 1517 <li class="indline1"><tt>disp-extension-parm</tt> <a class="iref" href="#rfc.iref.g.38"><b>B.1</b></a></li> 1518 <li class="indline1"><tt>disp-extension-token</tt> <a class="iref" href="#rfc.iref.g.37"><b>B.1</b></a></li> 1519 <li class="indline1"><tt>disposition-parm</tt> <a class="iref" href="#rfc.iref.g.35"><b>B.1</b></a></li> 1520 <li class="indline1"><tt>disposition-type</tt> <a class="iref" href="#rfc.iref.g.34"><b>B.1</b></a></li> 1521 <li class="indline1"><tt>entity-body</tt> <a class="iref" href="#rfc.iref.g.16"><b>3.2</b></a></li> 1522 <li class="indline1"><tt>entity-header</tt> <a class="iref" href="#rfc.iref.g.14"><b>3.1</b></a></li> 1523 <li class="indline1"><tt>extension-header</tt> <a class="iref" href="#rfc.iref.g.15"><b>3.1</b></a></li> 1524 <li class="indline1"><tt>filename-parm</tt> <a class="iref" href="#rfc.iref.g.36"><b>B.1</b></a></li> 1525 <li class="indline1"><tt>language-range</tt> <a class="iref" href="#rfc.iref.g.25"><b>5.4</b></a></li> 1526 <li class="indline1"><tt>language-tag</tt> <a class="iref" href="#rfc.iref.g.11"><b>2.5</b></a></li> 1527 <li class="indline1"><tt>md5-digest</tt> <a class="iref" href="#rfc.iref.g.30"><b>5.8</b></a></li> 1528 <li class="indline1"><tt>media-range</tt> <a class="iref" href="#rfc.iref.g.18"><b>5.1</b></a></li> 1529 <li class="indline1"><tt>media-type</tt> <a class="iref" href="#rfc.iref.g.4"><b>2.3</b></a></li> 1530 <li class="indline1"><tt>MIME-Version</tt> <a class="iref" href="#rfc.iref.g.32"><b>A.1</b></a></li> 1531 <li class="indline1"><tt>parameter</tt> <a class="iref" href="#rfc.iref.g.7"><b>2.3</b></a></li> 1532 <li class="indline1"><tt>primary-tag</tt> <a class="iref" href="#rfc.iref.g.12"><b>2.5</b></a></li> 1533 <li class="indline1"><tt>qvalue</tt> <a class="iref" href="#rfc.iref.g.10"><b>2.4</b></a></li> 1534 <li class="indline1"><tt>subtag</tt> <a class="iref" href="#rfc.iref.g.13"><b>2.5</b></a></li> 1535 <li class="indline1"><tt>subtype</tt> <a class="iref" href="#rfc.iref.g.6"><b>2.3</b></a></li> 1536 <li class="indline1"><tt>type</tt> <a class="iref" href="#rfc.iref.g.5"><b>2.3</b></a></li> 1537 <li class="indline1"><tt>value</tt> <a class="iref" href="#rfc.iref.g.9"><b>2.3</b></a></li> 1538 </ul> 1539 </li> 1540 <li class="indline1">gzip <a class="iref" href="#rfc.iref.g.3">2.2</a></li> 1541 </ul> 1542 </li> 1543 <li class="indline0"><a id="rfc.index.H" href="#rfc.index.H"><b>H</b></a><ul class="ind"> 1544 <li class="indline1">Headers 1545 <ul class="ind"> 1546 <li class="indline1">Accept <a class="iref" href="#rfc.xref.header.accept.1">2.3</a>, <a class="iref" href="#rfc.xref.header.accept.2">4.1</a>, <a class="iref" href="#rfc.iref.h.1"><b>5.1</b></a></li> 1547 <li class="indline1">Accept-Charset <a class="iref" href="#rfc.xref.header.accept-charset.1">4.1</a>, <a class="iref" href="#rfc.iref.h.2"><b>5.2</b></a>, <a class="iref" href="#rfc.xref.header.accept-charset.2">C</a></li> 1548 <li class="indline1">Accept-Encoding <a class="iref" href="#rfc.xref.header.accept-encoding.1">2.2</a>, <a class="iref" href="#rfc.xref.header.accept-encoding.2">4.1</a>, <a class="iref" href="#rfc.iref.h.3"><b>5.3</b></a></li> 1549 <li class="indline1">Accept-Language <a class="iref" href="#rfc.xref.header.accept-language.1">4.1</a>, <a class="iref" href="#rfc.iref.h.4"><b>5.4</b></a></li> 1550 <li class="indline1">Alternate <a class="iref" href="#rfc.iref.h.11"><b>C</b></a></li> 1551 <li class="indline1">Content-Base <a class="iref" href="#rfc.iref.h.17"><b>C</b></a></li> 1552 <li class="indline1">Content-Disposition <a class="iref" href="#rfc.xref.content-disposition.1">7.2</a>, <a class="iref" href="#rfc.iref.h.10"><b>B.1</b></a></li> 1553 <li class="indline1">Content-Encoding <a class="iref" href="#rfc.xref.header.content-encoding.1">2.2</a>, <a class="iref" href="#rfc.xref.header.content-encoding.2">3.1</a>, <a class="iref" href="#rfc.iref.h.5"><b>5.5</b></a>, <a class="iref" href="#rfc.xref.header.content-encoding.3">5.5</a></li> 1554 <li class="indline1">Content-Language <a class="iref" href="#rfc.xref.header.content-language.1">3.1</a>, <a class="iref" href="#rfc.iref.h.6"><b>5.6</b></a></li> 1555 <li class="indline1">Content-Location <a class="iref" href="#rfc.xref.header.content-location.1">3.1</a>, <a class="iref" href="#rfc.iref.h.7"><b>5.7</b></a></li> 1556 <li class="indline1">Content-MD5 <a class="iref" href="#rfc.xref.header.content-md5.1">3.1</a>, <a class="iref" href="#rfc.iref.h.8"><b>5.8</b></a></li> 1557 <li class="indline1">Content-Type <a class="iref" href="#rfc.xref.header.content-type.1">2.3</a>, <a class="iref" href="#rfc.xref.header.content-type.2">3.1</a>, <a class="iref" href="#rfc.iref.h.9"><b>5.9</b></a></li> 1558 <li class="indline1">Content-Version <a class="iref" href="#rfc.iref.h.12"><b>C</b></a></li> 1559 <li class="indline1">Derived-From <a class="iref" href="#rfc.iref.h.13"><b>C</b></a></li> 1560 <li class="indline1">Link <a class="iref" href="#rfc.iref.h.14"><b>C</b></a></li> 1561 <li class="indline1">Public <a class="iref" href="#rfc.iref.h.16"><b>C</b></a></li> 1562 <li class="indline1">URI <a class="iref" href="#rfc.iref.h.15"><b>C</b></a></li> 1563 </ul> 1564 </li> 1565 </ul> 1566 </li> 1567 <li class="indline0"><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul class="ind"> 1568 <li class="indline1">identity <a class="iref" href="#rfc.iref.i.1">2.2</a></li> 1569 </ul> 1570 </li> 1571 <li class="indline0"><a id="rfc.index.L" href="#rfc.index.L"><b>L</b></a><ul class="ind"> 1572 <li class="indline1">Link header <a class="iref" href="#rfc.iref.l.1"><b>C</b></a></li> 1573 </ul> 1574 </li> 1575 <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind"> 1576 <li class="indline1"><em>Part1</em> <a class="iref" href="#rfc.xref.Part1.1">3.1</a>, <a class="iref" href="#rfc.xref.Part1.2">3.2</a>, <a class="iref" href="#rfc.xref.Part1.3">3.2.2</a>, <a class="iref" href="#Part1"><b>9</b></a>, <a class="iref" href="#rfc.xref.Part1.4">A.5</a><ul class="ind"> 1577 <li class="indline1"><em>Section 4.3</em> <a class="iref" href="#rfc.xref.Part1.2">3.2</a></li> 1578 <li class="indline1"><em>Section 4.4</em> <a class="iref" href="#rfc.xref.Part1.3">3.2.2</a></li> 1579 <li class="indline1"><em>Section 8.2</em> <a class="iref" href="#rfc.xref.Part1.1">3.1</a></li> 1580 <li class="indline1"><em>Section 8.7</em> <a class="iref" href="#rfc.xref.Part1.4">A.5</a></li> 1581 </ul> 1582 </li> 1583 <li class="indline1"><em>Part2</em> <a class="iref" href="#rfc.xref.Part2.1">3.1</a>, <a class="iref" href="#rfc.xref.Part2.2">4.1</a>, <a class="iref" href="#Part2"><b>9</b></a><ul class="ind"> 1584 <li class="indline1"><em>Section 10.1</em> <a class="iref" href="#rfc.xref.Part2.1">3.1</a></li> 1585 <li class="indline1"><em>Section 10.9</em> <a class="iref" href="#rfc.xref.Part2.2">4.1</a></li> 1586 </ul> 1587 </li> 1588 <li class="indline1"><em>Part4</em> <a class="iref" href="#rfc.xref.Part4.1">3.1</a>, <a class="iref" href="#Part4"><b>9</b></a><ul class="ind"> 1589 <li class="indline1"><em>Section 6.6</em> <a class="iref" href="#rfc.xref.Part4.1">3.1</a></li> 1590 </ul> 1591 </li> 1592 <li class="indline1"><em>Part5</em> <a class="iref" href="#rfc.xref.Part5.1">2.3.2</a>, <a class="iref" href="#rfc.xref.Part5.2">3.1</a>, <a class="iref" href="#Part5"><b>9</b></a><ul class="ind"> 1593 <li class="indline1"><em>Section 5.2</em> <a class="iref" href="#rfc.xref.Part5.2">3.1</a></li> 1594 <li class="indline1"><em>Section A</em> <a class="iref" href="#rfc.xref.Part5.1">2.3.2</a></li> 1595 </ul> 1596 </li> 1597 <li class="indline1"><em>Part6</em> <a class="iref" href="#rfc.xref.Part6.1">3.1</a>, <a class="iref" href="#rfc.xref.Part6.2">4.1</a>, <a class="iref" href="#rfc.xref.Part6.3">5.7</a>, <a class="iref" href="#Part6"><b>9</b></a><ul class="ind"> 1598 <li class="indline1"><em>Section 3.3</em> <a class="iref" href="#rfc.xref.Part6.1">3.1</a></li> 1599 </ul> 1600 </li> 1601 <li class="indline1">Public header <a class="iref" href="#rfc.iref.p.1"><b>C</b></a></li> 1602 </ul> 1603 </li> 1604 <li class="indline0"><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul class="ind"> 1605 <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> 1606 <li class="indline1"><em>RFC1806</em> <a class="iref" href="#rfc.xref.RFC1806.1">7.2</a>, <a class="iref" href="#rfc.xref.RFC1806.2">7.2</a>, <a class="iref" href="#RFC1806"><b>9</b></a>, <a class="iref" href="#rfc.xref.RFC1806.3">B.1</a></li> 1607 <li class="indline1"><em>RFC1864</em> <a class="iref" href="#rfc.xref.RFC1864.1">5.8</a>, <a class="iref" href="#RFC1864"><b>9</b></a></li> 1608 <li class="indline1"><em>RFC1867</em> <a class="iref" href="#rfc.xref.RFC1867.1">2.3.2</a>, <a class="iref" href="#RFC1867"><b>9</b></a></li> 1609 <li class="indline1"><em>RFC1945</em> <a class="iref" href="#RFC1945"><b>9</b></a>, <a class="iref" href="#rfc.xref.RFC1945.1">B</a></li> 1610 <li class="indline1"><em>RFC1950</em> <a class="iref" href="#rfc.xref.RFC1950.1">2.2</a>, <a class="iref" href="#RFC1950"><b>9</b></a></li> 1611 <li class="indline1"><em>RFC1951</em> <a class="iref" href="#rfc.xref.RFC1951.1">2.2</a>, <a class="iref" href="#RFC1951"><b>9</b></a></li> 1612 <li class="indline1"><em>RFC1952</em> <a class="iref" href="#rfc.xref.RFC1952.1">2.2</a>, <a class="iref" href="#RFC1952"><b>9</b></a></li> 1613 <li class="indline1"><em>RFC2045</em> <a class="iref" href="#RFC2045"><b>9</b></a>, <a class="iref" href="#rfc.xref.RFC2045.1">A</a>, <a class="iref" href="#rfc.xref.RFC2045.2">A.1</a>, <a class="iref" href="#rfc.xref.RFC2045.3">A.2</a></li> 1614 <li class="indline1"><em>RFC2046</em> <a class="iref" href="#rfc.xref.RFC2046.1">2.3.2</a>, <a class="iref" href="#RFC2046"><b>9</b></a>, <a class="iref" href="#rfc.xref.RFC2046.2">A.2</a><ul class="ind"> 1615 <li class="indline1"><em>Section 5.1.1</em> <a class="iref" href="#rfc.xref.RFC2046.1">2.3.2</a></li> 1616 </ul> 1617 </li> 1618 <li class="indline1"><em>RFC2049</em> <a class="iref" href="#RFC2049"><b>9</b></a>, <a class="iref" href="#rfc.xref.RFC2049.1">A.2</a><ul class="ind"> 1619 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.RFC2049.1">A.2</a></li> 1620 </ul> 1621 </li> 1622 <li class="indline1"><em>RFC2068</em> <a class="iref" href="#RFC2068"><b>9</b></a>, <a class="iref" href="#rfc.xref.RFC2068.1">B</a>, <a class="iref" href="#rfc.xref.RFC2068.2">C</a></li> 1623 <li class="indline1"><em>RFC2076</em> <a class="iref" href="#RFC2076"><b>9</b></a>, <a class="iref" href="#rfc.xref.RFC2076.1">B</a></li> 1624 <li class="indline1"><em>RFC2110</em> <a class="iref" href="#RFC2110"><b>9</b></a>, <a class="iref" href="#rfc.xref.RFC2110.1">A.6</a>, <a class="iref" href="#rfc.xref.RFC2110.2">C</a></li> 1625 <li class="indline1"><em>RFC2119</em> <a class="iref" href="#rfc.xref.RFC2119.1">1.1</a>, <a class="iref" href="#RFC2119"><b>9</b></a></li> 1626 <li class="indline1"><em>RFC2183</em> <a class="iref" href="#rfc.xref.RFC2183.1">7.2</a>, <a class="iref" href="#RFC2183"><b>9</b></a></li> 1627 <li class="indline1"><em>RFC2277</em> <a class="iref" href="#rfc.xref.RFC2277.1">2.1</a>, <a class="iref" href="#RFC2277"><b>9</b></a></li> 1628 <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> 1629 <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> 1630 <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> 1631 <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> 1632 </ul> 1633 </li> 1634 <li class="indline0"><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul class="ind"> 1635 <li class="indline1">URI header <a class="iref" href="#rfc.iref.u.1"><b>C</b></a></li> 1636 </ul> 1637 </li> 1638 </ul> 1639 </div> 1640 </body> 1641 </html> -
draft-ietf-httpbis/latest/p3-payload.xml
r96 r97 348 348 <t> 349 349 An encoding format produced by the file compression program 350 "gzip" (GNU zip) as described in RFC 1952<xref target="RFC1952"/>. This format is a350 "gzip" (GNU zip) as described in <xref target="RFC1952"/>. This format is a 351 351 Lempel-Ziv coding (LZ77) with a 32 bit CRC. 352 352 </t> … … 371 371 deflate<iref item="deflate"/> 372 372 <list><t> 373 The "zlib" format defined in RFC 1950<xref target="RFC1950"/> in combination with374 the "deflate" compression mechanism described in RFC 1951<xref target="RFC1951"/>.373 The "zlib" format defined in <xref target="RFC1950"/> in combination with 374 the "deflate" compression mechanism described in <xref target="RFC1951"/>. 375 375 </t></list> 376 376 </t> … … 477 477 MIME provides for a number of "multipart" types -- encapsulations of 478 478 one or more entities within a single message-body. All multipart 479 types share a common syntax, as defined in section <xref target="RFC2046" x:sec="5.1.1" x:fmt="number"/> of RFC 2046480 <xref target="RFC2046"/>,and &MUST; include a boundary parameter as part of the media type479 types share a common syntax, as defined in <xref target="RFC2046" x:sec="5.1.1" x:fmt="of"/>, 480 and &MUST; include a boundary parameter as part of the media type 481 481 value. The message body is itself a protocol element and &MUST; 482 482 therefore use only CRLF to represent line breaks between body-parts. … … 492 492 any other media type: strictly as payload. The one exception is the 493 493 "multipart/byteranges" type (&multipart-byteranges;) when it appears in a 206 494 (Partial Content) response. In all 494 (Partial Content) response. 495 <!-- jre: re-insert removed text pointing to caching? --> 496 In all 495 497 other cases, an HTTP user agent &SHOULD; follow the same or similar 496 498 behavior as a MIME user agent would upon receipt of a multipart type. … … 508 510 <x:h>Note:</x:h> The "multipart/form-data" type has been specifically defined 509 511 for carrying form data suitable for processing via the POST 510 request method, as described in RFC 1867<xref target="RFC1867"/>.512 request method, as described in <xref target="RFC1867"/>. 511 513 </t></list></t> 512 514 </section> … … 545 547 <t> 546 548 The syntax and registry of HTTP language tags is the same as that 547 defined by RFC 1766<xref target="RFC1766"/>. In summary, a language tag is composed of 1549 defined by <xref target="RFC1766"/>. In summary, a language tag is composed of 1 548 550 or more parts: A primary language tag and a possibly empty series of 549 551 subtags: … … 1291 1293 <iref primary="true" item="Headers" subitem="Content-MD5" x:for-anchor=""/> 1292 1294 <t> 1293 The Content-MD5 entity-header field, as defined in RFC 1864<xref target="RFC1864"/>, is1295 The Content-MD5 entity-header field, as defined in <xref target="RFC1864"/>, is 1294 1296 an MD5 digest of the entity-body for the purpose of providing an 1295 1297 end-to-end message integrity check (MIC) of the entity-body. (Note: a … … 1441 1443 <section title="Content-Disposition Issues" anchor="content-disposition.issues"> 1442 1444 <t> 1443 RFC 1806<xref target="RFC1806"/>, from which the often implemented Content-Disposition1445 <xref target="RFC1806"/>, from which the often implemented Content-Disposition 1444 1446 (see <xref target="content-disposition"/>) header in HTTP is derived, has a number of very 1445 1447 serious security considerations. Content-Disposition is not part of 1446 1448 the HTTP standard, but since it is widely implemented, we are 1447 documenting its use and risks for implementors. See RFC 2183<xref target="RFC2183"/>1448 (which updates RFC 1806) for details.1449 documenting its use and risks for implementors. See <xref target="RFC2183"/> 1450 (which updates <xref target="RFC1806"/>) for details. 1449 1451 </t> 1450 1452 </section> … … 1720 1722 1721 1723 <reference anchor="RFC1766"> 1722 <front> 1723 <title abbrev="Language Tag">Tags for the Identification of Languages</title> 1724 <author initials="H." surname="Alvestrand" fullname="Harald Tveit Alvestrand"> 1725 <organization>UNINETT</organization> 1726 <address> 1727 <postal> 1728 <street>Pb. 6883 Elgeseter</street> 1729 <city>Trondheim</city> 1730 <region/> 1731 <code>N-7002</code> 1732 <country>NO</country></postal> 1733 <phone>+47 73 597094</phone> 1734 <email>Harald.T.Alvestrand@uninett.no</email></address></author> 1735 <date month="March" year="1995"/> 1736 </front> 1737 <seriesInfo name="RFC" value="1766"/> 1724 <front> 1725 <title abbrev="Language Tag">Tags for the Identification of Languages</title> 1726 <author initials="H." surname="Alvestrand" fullname="Harald Tveit Alvestrand"> 1727 <organization>UNINETT</organization> 1728 <address><email>Harald.T.Alvestrand@uninett.no</email></address> 1729 </author> 1730 <date month="March" year="1995"/> 1731 </front> 1732 <seriesInfo name="RFC" value="1766"/> 1738 1733 </reference> 1739 1734 1740 1735 <reference anchor="RFC2045"> 1741 <front> 1742 <title abbrev="Internet Message Bodies">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</title> 1743 <author initials="N." surname="Freed" fullname="Ned Freed"> 1744 <organization>Innosoft International, Inc.</organization> 1745 <address> 1746 <postal> 1747 <street>1050 East Garvey Avenue South</street> 1748 <city>West Covina</city> 1749 <region>CA</region> 1750 <code>91790</code> 1751 <country>US</country></postal> 1752 <phone>+1 818 919 3600</phone> 1753 <facsimile>+1 818 919 3614</facsimile> 1754 <email>ned@innosoft.com</email></address></author> 1755 <author initials="N.S." surname="Borenstein" fullname="Nathaniel S. Borenstein"> 1756 <organization>First Virtual Holdings</organization> 1757 <address> 1758 <postal> 1759 <street>25 Washington Avenue</street> 1760 <city>Morristown</city> 1761 <region>NJ</region> 1762 <code>07960</code> 1763 <country>US</country></postal> 1764 <phone>+1 201 540 8967</phone> 1765 <facsimile>+1 201 993 3032</facsimile> 1766 <email>nsb@nsb.fv.com</email></address></author> 1767 <date month="November" year="1996"/> 1768 </front> 1769 <seriesInfo name="RFC" value="2045"/> 1736 <front> 1737 <title abbrev="Internet Message Bodies">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</title> 1738 <author initials="N." surname="Freed" fullname="Ned Freed"> 1739 <organization>Innosoft International, Inc.</organization> 1740 <address><email>ned@innosoft.com</email></address> 1741 </author> 1742 <author initials="N.S." surname="Borenstein" fullname="Nathaniel S. Borenstein"> 1743 <organization>First Virtual Holdings</organization> 1744 <address><email>nsb@nsb.fv.com</email></address> 1745 </author> 1746 <date month="November" year="1996"/> 1747 </front> 1748 <seriesInfo name="RFC" value="2045"/> 1770 1749 </reference> 1771 1750 1772 1751 <reference anchor="RFC822"> 1773 <front> 1774 <title abbrev="Standard for ARPA Internet Text Messages">Standard for the format of ARPA Internet text messages</title> 1775 <author initials="D.H." surname="Crocker" fullname="David H. Crocker"> 1776 <organization>University of Delaware, Dept. of Electrical Engineering</organization> 1777 <address> 1778 <postal> 1779 <street/> 1780 <city>Newark</city> 1781 <region>DE</region> 1782 <code>19711</code> 1783 <country>US</country></postal> 1784 <email>DCrocker@UDel-Relay</email></address></author> 1785 <date month="August" day="13" year="1982"/></front> 1786 <seriesInfo name="STD" value="11"/> 1787 <seriesInfo name="RFC" value="822"/> 1752 <front> 1753 <title abbrev="Standard for ARPA Internet Text Messages">Standard for the format of ARPA Internet text messages</title> 1754 <author initials="D.H." surname="Crocker" fullname="David H. Crocker"> 1755 <organization>University of Delaware, Dept. of Electrical Engineering</organization> 1756 <address><email>DCrocker@UDel-Relay</email></address> 1757 </author> 1758 <date month="August" day="13" year="1982"/> 1759 </front> 1760 <seriesInfo name="STD" value="11"/> 1761 <seriesInfo name="RFC" value="822"/> 1788 1762 </reference> 1789 1763 1790 1764 <reference anchor="RFC1867"> 1791 <front> 1792 <title>Form-based File Upload in HTML</title> 1793 <author initials="L." surname="Masinter" fullname="Larry Masinter"> 1794 <organization>Xerox Palo Alto Research Center</organization> 1795 <address> 1796 <postal> 1797 <street>3333 Coyote Hill Road</street> 1798 <city>Palo Alto</city> 1799 <region>CA</region> 1800 <code>94304</code> 1801 <country>US</country></postal> 1802 <phone>+1 415 812 4365</phone> 1803 <facsimile>+1 415 812 4333</facsimile> 1804 <email>masinter@parc.xerox.com</email></address></author> 1805 <author initials="E." surname="Nebel" fullname="Ernesto Nebel"> 1806 <organization>XSoft, Xerox Corporation</organization> 1807 <address> 1808 <postal> 1809 <street>10875 Rancho Bernardo Road</street> 1810 <street>Suite 200</street> 1811 <city>San Diego</city> 1812 <region>CA</region> 1813 <code>92127-2116</code> 1814 <country>US</country></postal> 1815 <phone>+1 619 676 7817</phone> 1816 <facsimile>+1 619 676 7865</facsimile> 1817 <email>nebel@xsoft.sd.xerox.com</email></address></author> 1818 <date month="November" year="1995"/> 1819 </front> 1820 <seriesInfo name="RFC" value="1867"/> 1765 <front> 1766 <title>Form-based File Upload in HTML</title> 1767 <author initials="L." surname="Masinter" fullname="Larry Masinter"> 1768 <organization>Xerox Palo Alto Research Center</organization> 1769 <address><email>masinter@parc.xerox.com</email></address> 1770 </author> 1771 <author initials="E." surname="Nebel" fullname="Ernesto Nebel"> 1772 <organization>XSoft, Xerox Corporation</organization> 1773 <address><email>nebel@xsoft.sd.xerox.com</email></address> 1774 </author> 1775 <date month="November" year="1995"/> 1776 </front> 1777 <seriesInfo name="RFC" value="1867"/> 1821 1778 </reference> 1822 1779 … … 1843 1800 1844 1801 <reference anchor="RFC1864"> 1845 <front> 1846 <title abbrev="Content-MD5 Header Field">The Content-MD5 Header Field</title> 1847 <author initials="J." surname="Myers" fullname="John G. Myers"> 1848 <organization>Carnegie Mellon University</organization> 1849 <address> 1850 <phone/> 1851 <email>jgm+@cmu.edu</email></address></author> 1852 <author initials="M." surname="Rose" fullname="Marshall T. Rose"> 1853 <organization>Dover Beach Consulting, Inc.</organization> 1854 <address> 1855 <phone/> 1856 <email>mrose@dbc.mtview.ca.us</email></address></author> 1857 <date month="October" year="1995"/> 1858 </front> 1859 <seriesInfo name="RFC" value="1864"/> 1860 </reference> 1861 1802 <front> 1803 <title abbrev="Content-MD5 Header Field">The Content-MD5 Header Field</title> 1804 <author initials="J." surname="Myers" fullname="John G. Myers"> 1805 <organization>Carnegie Mellon University</organization> 1806 <address><email>jgm+@cmu.edu</email></address> 1807 </author> 1808 <author initials="M." surname="Rose" fullname="Marshall T. Rose"> 1809 <organization>Dover Beach Consulting, Inc.</organization> 1810 <address><email>mrose@dbc.mtview.ca.us</email></address> 1811 </author> 1812 <date month="October" year="1995"/> 1813 </front> 1814 <seriesInfo name="RFC" value="1864"/> 1815 </reference> 1862 1816 1863 1817 <reference anchor="RFC1952"> 1864 <front> 1865 <title>GZIP file format specification version 4.3</title> 1866 <author initials="P." surname="Deutsch" fullname="L. Peter Deutsch"> 1867 <organization>Aladdin Enterprises</organization> 1868 <address> 1869 <postal> 1870 <street>203 Santa Margarita Ave.</street> 1871 <city>Menlo Park</city> 1872 <region>CA</region> 1873 <code>94025</code> 1874 <country>US</country></postal> 1875 <phone>+1 415 322 0103</phone> 1876 <facsimile>+1 415 322 1734</facsimile> 1877 <email>ghost@aladdin.com</email></address></author> 1878 <author initials="J-L." surname="Gailly" fullname="Jean-Loup Gailly"> 1879 <organization/> 1880 <address> 1881 <postal> 1882 <street/> 1883 <city/> 1884 <region/> 1885 <code/> 1886 <country/></postal> 1887 <phone/> 1888 <email>gzip@prep.ai.mit.edu</email></address></author> 1889 <author initials="M." surname="Adler" fullname="Mark Adler"> 1890 <organization/> 1891 <address> 1892 <postal> 1893 <street/> 1894 <city/> 1895 <region/> 1896 <code/> 1897 <country/></postal> 1898 <phone/> 1899 <email>madler@alumni.caltech.edu</email></address></author> 1900 <author initials="L.P." surname="Deutsch" fullname="L. Peter Deutsch"> 1901 <organization/> 1902 <address> 1903 <postal> 1904 <street/> 1905 <city/> 1906 <region/> 1907 <code/> 1908 <country/></postal> 1909 <phone/> 1910 <email>ghost@aladdin.com</email></address></author> 1911 <author initials="G." surname="Randers-Pehrson" fullname="Glenn Randers-Pehrson"> 1912 <organization/> 1913 <address> 1914 <postal> 1915 <street/> 1916 <city/> 1917 <region/> 1918 <code/> 1919 <country/></postal> 1920 <phone/> 1921 <email>randeg@alumni.rpi.edu</email></address></author> 1922 <date month="May" year="1996"/> 1923 </front> 1924 <seriesInfo name="RFC" value="1952"/> 1818 <front> 1819 <title>GZIP file format specification version 4.3</title> 1820 <author initials="P." surname="Deutsch" fullname="L. Peter Deutsch"> 1821 <organization>Aladdin Enterprises</organization> 1822 <address><email>ghost@aladdin.com</email></address> 1823 </author> 1824 <author initials="J-L." surname="Gailly" fullname="Jean-Loup Gailly"> 1825 <organization/> 1826 <address><email>gzip@prep.ai.mit.edu</email></address></author> 1827 <author initials="M." surname="Adler" fullname="Mark Adler"> 1828 <organization/> 1829 <address><email>madler@alumni.caltech.edu</email></address></author> 1830 <author initials="L.P." surname="Deutsch" fullname="L. Peter Deutsch"> 1831 <organization/> 1832 <address><email>ghost@aladdin.com</email></address> 1833 </author> 1834 <author initials="G." surname="Randers-Pehrson" fullname="Glenn Randers-Pehrson"> 1835 <organization/> 1836 <address><email>randeg@alumni.rpi.edu</email></address> 1837 </author> 1838 <date month="May" year="1996"/> 1839 </front> 1840 <seriesInfo name="RFC" value="1952"/> 1925 1841 </reference> 1926 1842 1927 1843 <reference anchor="RFC1951"> 1928 <front> 1929 <title>DEFLATE Compressed Data Format Specification version 1.3</title> 1930 <author initials="P." surname="Deutsch" fullname="L. Peter Deutsch"> 1931 <organization>Aladdin Enterprises</organization> 1932 <address> 1933 <postal> 1934 <street>203 Santa Margarita Ave.</street> 1935 <city>Menlo Park</city> 1936 <region>CA</region> 1937 <code>94025</code> 1938 <country>US</country></postal> 1939 <phone>+1 415 322 0103</phone> 1940 <facsimile>+1 415 322 1734</facsimile> 1941 <email>ghost@aladdin.com</email></address></author> 1942 <date month="May" year="1996"/> 1943 <abstract> 1944 <t>This specification defines a lossless compressed data format that compresses data using a combination of the LZ77 algorithm and Huffman coding, with efficiency comparable to the best currently available general-purpose compression methods. The data can be produced or consumed, even for an arbitrarily long sequentially presented input data stream, using only an a priori bounded amount of intermediate storage. The format can be implemented readily in a manner not covered by patents.</t></abstract></front> 1945 <seriesInfo name="RFC" value="1951"/> 1844 <front> 1845 <title>DEFLATE Compressed Data Format Specification version 1.3</title> 1846 <author initials="P." surname="Deutsch" fullname="L. Peter Deutsch"> 1847 <organization>Aladdin Enterprises</organization> 1848 <address><email>ghost@aladdin.com</email></address> 1849 </author> 1850 <date month="May" year="1996"/> 1851 </front> 1852 <seriesInfo name="RFC" value="1951"/> 1946 1853 </reference> 1947 1854 1948 1855 <reference anchor="RFC1950"> 1949 <front> 1950 <title>ZLIB Compressed Data Format Specification version 3.3</title> 1951 <author initials="L.P." surname="Deutsch" fullname="L. Peter Deutsch"> 1952 <organization>Aladdin Enterprises</organization> 1953 <address> 1954 <postal> 1955 <street>203 Santa Margarita Ave.</street> 1956 <city>Menlo Park</city> 1957 <region>CA</region> 1958 <code>94025</code> 1959 <country>US</country></postal> 1960 <phone>+1 415 322 0103</phone> 1961 <facsimile>+1 415 322 1734</facsimile> 1962 <email>ghost@aladdin.com</email></address></author> 1963 <author initials="J-L." surname="Gailly" fullname="Jean-Loup Gailly"> 1964 <organization/></author> 1965 <date month="May" year="1996"/> 1966 <abstract> 1967 <t>This specification defines a lossless compressed data format. The data can be produced or consumed, even for an arbitrarily long sequentially presented input data stream, using only an a priori bounded amount of intermediate storage. The format presently uses the DEFLATE compression method but can be easily extended to use 1968 other compression methods. It can be implemented readily in a manner not covered by patents. This specification also defines the ADLER-32 checksum (an extension and improvement of the Fletcher checksum), used for detection of data corruption, and provides an algorithm for computing it.</t></abstract></front> 1969 <seriesInfo name="RFC" value="1950"/> 1856 <front> 1857 <title>ZLIB Compressed Data Format Specification version 3.3</title> 1858 <author initials="L.P." surname="Deutsch" fullname="L. Peter Deutsch"> 1859 <organization>Aladdin Enterprises</organization> 1860 <address><email>ghost@aladdin.com</email></address> 1861 </author> 1862 <author initials="J-L." surname="Gailly" fullname="Jean-Loup Gailly"> 1863 <organization/> 1864 </author> 1865 <date month="May" year="1996"/> 1866 </front> 1867 <seriesInfo name="RFC" value="1950"/> 1970 1868 </reference> 1971 1869 1972 1870 <reference anchor="RFC2068"> 1973 <front> 1974 <title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title> 1975 <author initials="R." surname="Fielding" fullname="Roy T. Fielding"> 1976 <organization>University of California, Irvine, Department of Information and Computer Science</organization> 1977 <address> 1978 <postal> 1979 <street/> 1980 <city>Irvine</city> 1981 <region>CA</region> 1982 <code>92717-3425</code> 1983 <country>US</country></postal> 1984 <facsimile>+1 714 824 4056</facsimile> 1985 <email>fielding@ics.uci.edu</email></address></author> 1986 <author initials="J." surname="Gettys" fullname="Jim Gettys"> 1987 <organization>MIT Laboratory for Computer Science</organization> 1988 <address> 1989 <postal> 1990 <street>545 Technology Square</street> 1991 <city>Cambridge</city> 1992 <region>MA</region> 1993 <code>02139</code> 1994 <country>US</country></postal> 1995 <facsimile>+1 617 258 8682</facsimile> 1996 <email>jg@w3.org</email></address></author> 1997 <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> 1998 <organization>Digital Equipment Corporation, Western Research Laboratory</organization> 1999 <address> 2000 <postal> 2001 <street>250 University Avenue</street> 2002 <city>Palo Alto</city> 2003 <region>CA</region> 2004 <code>94301</code> 2005 <country>US</country></postal> 2006 <email>mogul@wrl.dec.com</email></address></author> 2007 <author initials="H." surname="Nielsen" fullname="Henrik Frystyk Nielsen"> 2008 <organization>MIT Laboratory for Computer Science</organization> 2009 <address> 2010 <postal> 2011 <street>545 Technology Square</street> 2012 <city>Cambridge</city> 2013 <region>MA</region> 2014 <code>02139</code> 2015 <country>US</country></postal> 2016 <facsimile>+1 617 258 8682</facsimile> 2017 <email>frystyk@w3.org</email></address></author> 2018 <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> 2019 <organization>MIT Laboratory for Computer Science</organization> 2020 <address> 2021 <postal> 2022 <street>545 Technology Square</street> 2023 <city>Cambridge</city> 2024 <region>MA</region> 2025 <code>02139</code> 2026 <country>US</country></postal> 2027 <facsimile>+1 617 258 8682</facsimile> 2028 <email>timbl@w3.org</email></address></author> 2029 <date month="January" year="1997"/> 2030 <abstract> 2031 <t>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.</t> 2032 <t>HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1".</t></abstract></front> 2033 <seriesInfo name="RFC" value="2068"/> 1871 <front> 1872 <title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title> 1873 <author initials="R." surname="Fielding" fullname="Roy T. Fielding"> 1874 <organization>University of California, Irvine, Department of Information and Computer Science</organization> 1875 <address><email>fielding@ics.uci.edu</email></address> 1876 </author> 1877 <author initials="J." surname="Gettys" fullname="Jim Gettys"> 1878 <organization>MIT Laboratory for Computer Science</organization> 1879 <address><email>jg@w3.org</email></address> 1880 </author> 1881 <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> 1882 <organization>Digital Equipment Corporation, Western Research Laboratory</organization> 1883 <address><email>mogul@wrl.dec.com</email></address> 1884 </author> 1885 <author initials="H." surname="Nielsen" fullname="Henrik Frystyk Nielsen"> 1886 <organization>MIT Laboratory for Computer Science</organization> 1887 <address><email>frystyk@w3.org</email></address> 1888 </author> 1889 <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> 1890 <organization>MIT Laboratory for Computer Science</organization> 1891 <address><email>timbl@w3.org</email></address> 1892 </author> 1893 <date month="January" year="1997"/> 1894 </front> 1895 <seriesInfo name="RFC" value="2068"/> 2034 1896 </reference> 2035 1897 2036 1898 <reference anchor="RFC1806"> 2037 <front> 2038 <title abbrev="Content-Disposition">Communicating Presentation Information in Internet Messages: The Content-Disposition Header</title> 2039 <author initials="R." surname="Troost" fullname="Rens Troost"> 2040 <organization>New Century Systems</organization> 2041 <address> 2042 <postal> 2043 <street>324 East 41st Street #804</street> 2044 <city>New York</city> 2045 <region>NY</region> 2046 <code>10017</code> 2047 <country>US</country></postal> 2048 <phone>+1 212 557 2050</phone> 2049 <facsimile>+1 212 557 2049</facsimile> 2050 <email>rens@century.com</email></address></author> 2051 <author initials="S." surname="Dorner" fullname="Steve Dorner"> 2052 <organization>QUALCOMM Incorporated</organization> 2053 <address> 2054 <postal> 2055 <street>6455 Lusk Boulevard</street> 2056 <city>San Diego</city> 2057 <region>CA</region> 2058 <code>92121</code> 2059 <country>US</country></postal> 2060 <email>sdorner@qualcomm.com</email></address></author> 2061 <date month="June" year="1995"/> 2062 <abstract> 2063 <t>This memo provides a mechanism whereby messages conforming to the("MIME") specification can convey presentational information. It specifies a new "Content-Disposition" header, optional and valid for anyentity ("message" or "body part"). Two values for this header are described in this memo; one for the ordinary linear presentation of the body part, and another to facilitate the use of mail to transfer files. It is expected that more values will be defined in the future, and procedures are defined for extending this set of values.</t> 2064 <t>This document is intended as an extension to. As such, the reader is assumed to be familiar with, and. The information presented herein supplements but does not replace that found in those documents.</t></abstract></front> 2065 <seriesInfo name="RFC" value="1806"/> 1899 <front> 1900 <title abbrev="Content-Disposition">Communicating Presentation Information in Internet Messages: The Content-Disposition Header</title> 1901 <author initials="R." surname="Troost" fullname="Rens Troost"> 1902 <organization>New Century Systems</organization> 1903 <address><email>rens@century.com</email></address> 1904 </author> 1905 <author initials="S." surname="Dorner" fullname="Steve Dorner"> 1906 <organization>QUALCOMM Incorporated</organization> 1907 <address><email>sdorner@qualcomm.com</email></address> 1908 </author> 1909 <date month="June" year="1995"/> 1910 </front> 1911 <seriesInfo name="RFC" value="1806"/> 1912 </reference> 1913 1914 <reference anchor="RFC1945"> 1915 <front> 1916 <title abbrev="HTTP/1.0">Hypertext Transfer Protocol -- HTTP/1.0</title> 1917 <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> 1918 <organization>MIT, Laboratory for Computer Science</organization> 1919 <address><email>timbl@w3.org</email></address> 1920 </author> 1921 <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding"> 1922 <organization>University of California, Irvine, Department of Information and Computer Science</organization> 1923 <address><email>fielding@ics.uci.edu</email></address> 1924 </author> 1925 <author initials="H.F." surname="Nielsen" fullname="Henrik Frystyk Nielsen"> 1926 <organization>W3 Consortium, MIT Laboratory for Computer Science</organization> 1927 <address><email>frystyk@w3.org</email></address> 1928 </author> 1929 <date month="May" year="1996"/> 1930 </front> 1931 <seriesInfo name="RFC" value="1945"/> 2066 1932 </reference> 2067 1933 2068 1934 <reference anchor="RFC2076"> 2069 <front> 2070 <title abbrev="Internet Message Headers">Common Internet Message Headers</title> 2071 <author initials="J." surname="Palme" fullname="Jacob Palme"> 2072 <organization>Stockholm University/KTH</organization> 2073 <address> 2074 <postal> 2075 <street>Electrum 230</street> 2076 <street>S-164 40 Kista</street> 2077 <country>SE</country></postal> 2078 <phone>+46 8 161667</phone> 2079 <facsimile>+46 8 7830829</facsimile> 2080 <email>jpalme@dsv.su.se</email></address></author> 2081 <date month="February" year="1997"/> 2082 <abstract> 2083 <t>This memo contains a table of commonly occurring headers in headings of e-mail messages. The document compiles information from other RFCs such as RFC 822, RFC 1036, RFC 1123, RFC 1327, RFC 1496, RFC 1521, RFC 1766, RFC 1806, RFC 1864 and RFC 1911. A few commonly occurring headers which are not defined in RFCs are also included. For each header, the memo gives a short description and a reference to the RFC in which the header is defined.</t></abstract></front> 2084 <seriesInfo name="RFC" value="2076"/> 1935 <front> 1936 <title abbrev="Internet Message Headers">Common Internet Message Headers</title> 1937 <author initials="J." surname="Palme" fullname="Jacob Palme"> 1938 <organization>Stockholm University/KTH</organization> 1939 <address><email>jpalme@dsv.su.se</email></address> 1940 </author> 1941 <date month="February" year="1997"/> 1942 </front> 1943 <seriesInfo name="RFC" value="2076"/> 2085 1944 </reference> 2086 1945 … … 2121 1980 2122 1981 <reference anchor="RFC2046"> 2123 <front> 2124 <title abbrev="Media Types">Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</title> 2125 <author initials="N." surname="Freed" fullname="Ned Freed"> 2126 <organization>Innosoft International, Inc.</organization> 2127 <address> 2128 <postal> 2129 <street>1050 East Garvey Avenue South</street> 2130 <city>West Covina</city> 2131 <region>CA</region> 2132 <code>91790</code> 2133 <country>US</country></postal> 2134 <phone>+1 818 919 3600</phone> 2135 <facsimile>+1 818 919 3614</facsimile> 2136 <email>ned@innosoft.com</email></address></author> 2137 <author initials="N." surname="Borenstein" fullname="Nathaniel S. Borenstein"> 2138 <organization>First Virtual Holdings</organization> 2139 <address> 2140 <postal> 2141 <street>25 Washington Avenue</street> 2142 <city>Morristown</city> 2143 <region>NJ</region> 2144 <code>07960</code> 2145 <country>US</country></postal> 2146 <phone>+1 201 540 8967</phone> 2147 <facsimile>+1 201 993 3032</facsimile> 2148 <email>nsb@nsb.fv.com</email></address></author> 2149 <date month="November" year="1996"/> 2150 </front> 2151 <seriesInfo name="RFC" value="2046"/> 1982 <front> 1983 <title abbrev="Media Types">Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</title> 1984 <author initials="N." surname="Freed" fullname="Ned Freed"> 1985 <organization>Innosoft International, Inc.</organization> 1986 <address><email>ned@innosoft.com</email></address> 1987 </author> 1988 <author initials="N." surname="Borenstein" fullname="Nathaniel S. Borenstein"> 1989 <organization>First Virtual Holdings</organization> 1990 <address><email>nsb@nsb.fv.com</email></address> 1991 </author> 1992 <date month="November" year="1996"/> 1993 </front> 1994 <seriesInfo name="RFC" value="2046"/> 2152 1995 </reference> 2153 1996 … … 2206 2049 2207 2050 <reference anchor="RFC2049"> 2208 <front> 2209 <title abbrev="MIME Conformance">Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples</title> 2210 <author initials="N." surname="Freed" fullname="Ned Freed"> 2211 <organization>Innosoft International, Inc.</organization> 2212 <address> 2213 <postal> 2214 <street>1050 East Garvey Avenue South</street> 2215 <street>West Covina</street> 2216 <street>CA 91790</street> 2217 <country>USA</country></postal> 2218 <phone>+1 818 919 3600</phone> 2219 <facsimile>+1 818 919 3614</facsimile> 2220 <email>ned@innosoft.com</email></address></author> 2221 <author initials="N.S." surname="Borenstein" fullname="Nathaniel S. Borenstein"> 2222 <organization>First Virtual Holdings</organization> 2223 <address> 2224 <postal> 2225 <street>25 Washington Avenue</street> 2226 <street>Morristown</street> 2227 <street>NJ 07960</street> 2228 <country>USA</country></postal> 2229 <phone>+1 201 540 8967</phone> 2230 <facsimile>+1 201 993 3032</facsimile> 2231 <email>nsb@nsb.fv.com</email></address></author> 2232 <date month="November" year="1996"/> 2233 <area>Applications</area> 2234 <keyword>mail</keyword> 2235 <keyword>multipurpose internet mail extensions</keyword> 2236 </front> 2237 <seriesInfo name="RFC" value="2049"/> 2051 <front> 2052 <title abbrev="MIME Conformance">Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples</title> 2053 <author initials="N." surname="Freed" fullname="Ned Freed"> 2054 <organization>Innosoft International, Inc.</organization> 2055 <address><email>ned@innosoft.com</email></address> 2056 </author> 2057 <author initials="N.S." surname="Borenstein" fullname="Nathaniel S. Borenstein"> 2058 <organization>First Virtual Holdings</organization> 2059 <address><email>nsb@nsb.fv.com</email></address> 2060 </author> 2061 <date month="November" year="1996"/> 2062 </front> 2063 <seriesInfo name="RFC" value="2049"/> 2238 2064 </reference> 2239 2065 2240 2066 <reference anchor="RFC2183"> 2241 <front> 2242 <title abbrev="Content-Disposition">Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field</title> 2243 <author initials="R." surname="Troost" fullname="Rens Troost"> 2244 <organization>New Century Systems</organization> 2245 <address> 2246 <postal> 2247 <street>324 East 41st Street #804</street> 2248 <street>New York</street> 2249 <street>NY</street> 2250 <street>10017</street> 2251 <country>USA</country></postal> 2252 <phone>+1 (212) 557-2050</phone> 2253 <facsimile>+1 (212) 557-2049</facsimile> 2254 <email>rens@century.com</email></address></author> 2255 <author initials="S." surname="Dorner" fullname="Steve Dorner"> 2256 <organization>QUALCOMM Incorporated</organization> 2257 <address> 2258 <postal> 2259 <street>6455 Lusk Boulevard</street> 2260 <street>San Diego</street> 2261 <street>CA 92121</street> 2262 <country>USA</country></postal> 2263 <email>sdorner@qualcomm.com</email></address></author> 2264 <author initials="K." surname="Moore" fullname="Keith Moore"> 2265 <organization>Department of Computer Science</organization> 2266 <address> 2267 <postal> 2268 <street>University of Tennessee</street> 2269 <street>Knoxville</street> 2270 <street>107 Ayres Hall</street> 2271 <street>Knoxville TN 37996-1301</street> 2272 <country>USA</country></postal> 2273 <phone>+1 (423) 974-5067</phone> 2274 <facsimile>+1 (423) 974-8296</facsimile> 2275 <email>moore@cs.utk.edu</email></address></author> 2276 <date month="August" year="1997"/> 2277 <area>Applications</area> 2278 <keyword>MIME</keyword> 2279 <keyword>internet message</keyword> 2280 <keyword>multipurpose internet mail extensions</keyword> 2281 </front> 2282 <seriesInfo name="RFC" value="2183"/> 2067 <front> 2068 <title abbrev="Content-Disposition">Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field</title> 2069 <author initials="R." surname="Troost" fullname="Rens Troost"> 2070 <organization>New Century Systems</organization> 2071 <address><email>rens@century.com</email></address> 2072 </author> 2073 <author initials="S." surname="Dorner" fullname="Steve Dorner"> 2074 <organization>QUALCOMM Incorporated</organization> 2075 <address><email>sdorner@qualcomm.com</email></address> 2076 </author> 2077 <author initials="K." surname="Moore" fullname="Keith Moore"> 2078 <organization>Department of Computer Science</organization> 2079 <address><email>moore@cs.utk.edu</email></address> 2080 </author> 2081 <date month="August" year="1997"/> 2082 </front> 2083 <seriesInfo name="RFC" value="2183"/> 2283 2084 </reference> 2284 2085 … … 2287 2088 <section title="Differences Between HTTP Entities and RFC 2045 Entities" anchor="differences.between.http.entities.and.rfc.2045.entities"> 2288 2089 <t> 2289 HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC 2290 822 <xref target="RFC822"/>) and the Multipurpose Internet Mail Extensions (MIME <xref target="RFC2045"/>) to 2090 HTTP/1.1 uses many of the constructs defined for Internet Mail (<xref target="RFC822"/>) and the Multipurpose Internet Mail Extensions (MIME <xref target="RFC2045"/>) to 2291 2091 allow entities to be transmitted in an open variety of 2292 2092 representations and with extensible mechanisms. However, RFC 2045 … … 2328 2128 <section title="Conversion to Canonical Form" anchor="conversion.to.canonical.form"> 2329 2129 <t> 2330 RFC 2045<xref target="RFC2045"/> requires that an Internet mail entity be converted to2331 canonical form prior to being transferred, as described in section <xref target="RFC2049" x:fmt=" number" x:sec="4"/>2332 of RFC 2049 <xref target="RFC2049"/>.<xref target="canonicalization.and.text.defaults"/> of this document describes the forms2130 <xref target="RFC2045"/> requires that an Internet mail entity be converted to 2131 canonical form prior to being transferred, as described in section <xref target="RFC2049" x:fmt="of" x:sec="4"/>. 2132 <xref target="canonicalization.and.text.defaults"/> of this document describes the forms 2333 2133 allowed for subtypes of the "text" media type when transmitted over 2334 HTTP. RFC 2046requires that content with a type of "text" represent2134 HTTP. <xref target="RFC2046"/> requires that content with a type of "text" represent 2335 2135 line breaks as CRLF and forbids the use of CR or LF outside of line 2336 2136 break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a … … 2412 2212 <section title="Additional Features" anchor="additional.features"> 2413 2213 <t> 2414 RFC 1945 and RFC 2068document protocol elements used by some2214 <xref target="RFC1945"/> and <xref target="RFC2068"/> document protocol elements used by some 2415 2215 existing HTTP implementations, but not consistently and correctly 2416 2216 across most HTTP/1.1 applications. Implementors are advised to be … … 2423 2223 <t> 2424 2224 A number of other headers, such as Content-Disposition and Title, 2425 from SMTP and MIME are also often implemented (see RFC 2076<xref target="RFC2076"/>).2225 from SMTP and MIME are also often implemented (see <xref target="RFC2076"/>). 2426 2226 </t> 2427 2227 … … 2433 2233 means for the origin server to suggest a default filename if the user 2434 2234 requests that the content is saved to a file. This usage is derived 2435 from the definition of Content-Disposition in RFC 1806<xref target="RFC1806"/>.2235 from the definition of Content-Disposition in <xref target="RFC1806"/>. 2436 2236 </t> 2437 2237 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="content-disposition"/><iref primary="true" item="Grammar" subitem="disposition-type"/><iref primary="true" item="Grammar" subitem="disposition-parm"/><iref primary="true" item="Grammar" subitem="filename-parm"/><iref primary="true" item="Grammar" subitem="disp-extension-token"/><iref primary="true" item="Grammar" subitem="disp-extension-parm"/> … … 2490 2290 The Alternates<iref item="Alternates header" primary="true"/><iref item="Headers" subitem="Alternate" primary="true"/>, Content-Version<iref item="Content-Version header" primary="true"/><iref item="Headers" subitem="Content-Version" primary="true"/>, Derived-From<iref item="Derived-From header" primary="true"/><iref item="Headers" subitem="Derived-From" primary="true"/>, Link<iref item="Link header" primary="true"/><iref item="Headers" subitem="Link" primary="true"/>, URI<iref item="URI header" primary="true"/><iref item="Headers" subitem="URI" primary="true"/>, Public<iref item="Public header" primary="true"/><iref item="Headers" subitem="Public" primary="true"/> and 2491 2291 Content-Base<iref item="Content-Base header" primary="true"/><iref item="Headers" subitem="Content-Base" primary="true"/> header fields were defined in previous versions of this 2492 specification, but not commonly implemented. See RFC 2068<xref target="RFC2068"/>.2292 specification, but not commonly implemented. See <xref target="RFC2068"/>. 2493 2293 </t> 2494 2294 </section> -
draft-ietf-httpbis/latest/p4-conditional.html
r96 r97 550 550 </ul> 551 551 <p id="rfc.section.3.1.p.3">If a clockless origin server obeys these rules, and proxies and clients add their own Date to any response received without 552 one (as already specified by <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, section <a href="http://tools.ietf.org/html/rfc2068#section-14.19" id="rfc.xref.RFC2068.2">14.19</a>), caches will operate correctly.552 one (as already specified by <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, <a href="http://tools.ietf.org/html/rfc2068#section-14.19">Section 14.19</a>), caches will operate correctly. 553 553 </p> 554 554 <ul> … … 718 718 <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="header.etag" href="#header.etag">ETag</a></h2> 719 719 <p id="rfc.section.6.1.p.1">The ETag response-header field provides the current value of the entity tag for the requested variant. The headers used with 720 entity tags are described in sections <a href="#header.if-match" id="rfc.xref.header.if-match.2" title="If-Match">6.2</a>, <a href="#header.if-none-match" id="rfc.xref.header.if-none-match.2" title="If-None-Match">6.4</a> and <a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. The entity tag <em class="bcp14">MAY</em> be used for comparison with other entities from the same resource (see <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a>).720 entity tags are described in Sections <a href="#header.if-match" id="rfc.xref.header.if-match.2" title="If-Match">6.2</a>, <a href="#header.if-none-match" id="rfc.xref.header.if-none-match.2" title="If-None-Match">6.4</a> and <a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. The entity tag <em class="bcp14">MAY</em> be used for comparison with other entities from the same resource (see <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section 4</a>). 721 721 </p> 722 722 <div id="rfc.figure.u.2"></div><pre class="inline"><span id="rfc.iref.g.4"></span> ETag = "ETag" ":" entity-tag … … 1037 1037 </li> 1038 1038 <li class="indline0"><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul class="ind"> 1039 <li class="indline1"><em>RFC2068</em> <a class="iref" href="#rfc.xref.RFC2068.1">3.1</a>, <a class="iref" href="# rfc.xref.RFC2068.2">3.1</a>, <a class="iref" href="#RFC2068"><b>10</b></a><ul class="ind">1040 <li class="indline1"><em>Section 14.19</em> <a class="iref" href="#rfc.xref.RFC2068. 2">3.1</a></li>1039 <li class="indline1"><em>RFC2068</em> <a class="iref" href="#rfc.xref.RFC2068.1">3.1</a>, <a class="iref" href="#RFC2068"><b>10</b></a><ul class="ind"> 1040 <li class="indline1"><em>Section 14.19</em> <a class="iref" href="#rfc.xref.RFC2068.1">3.1</a></li> 1041 1041 </ul> 1042 1042 </li> -
draft-ietf-httpbis/latest/p4-conditional.xml
r96 r97 294 294 If a clockless origin server obeys these rules, and proxies and 295 295 clients add their own Date to any response received without one (as 296 already specified by <xref target="RFC2068" />, section <xref target="RFC2068" x:sec="14.19" x:fmt="number"/>), caches will operate296 already specified by <xref target="RFC2068" x:sec="14.19" x:fmt=","/>), caches will operate 297 297 correctly. 298 298 <list style="symbols"> … … 586 586 The ETag response-header field provides the current value of the 587 587 entity tag for the requested variant. The headers used with entity 588 tags are described in sections <xref target="header.if-match" format="counter"/>, <xref target="header.if-none-match" format="counter"/> and &header-if-range;. The entity tag588 tags are described in Sections <xref target="header.if-match" format="counter"/>, <xref target="header.if-none-match" format="counter"/> and &header-if-range;. The entity tag 589 589 &MAY; be used for comparison with other entities from the same resource 590 590 (see <xref target="weak.and.strong.validators"/>). … … 1130 1130 1131 1131 <reference anchor="RFC2068"> 1132 <front> 1133 <title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title> 1134 <author initials="R." surname="Fielding" fullname="Roy T. Fielding"> 1135 <organization>University of California, Irvine, Department of Information and Computer Science</organization> 1136 <address> 1137 <postal> 1138 <street/> 1139 <city>Irvine</city> 1140 <region>CA</region> 1141 <code>92717-3425</code> 1142 <country>US</country></postal> 1143 <facsimile>+1 714 824 4056</facsimile> 1144 <email>fielding@ics.uci.edu</email></address></author> 1145 <author initials="J." surname="Gettys" fullname="Jim Gettys"> 1146 <organization>MIT Laboratory for Computer Science</organization> 1147 <address> 1148 <postal> 1149 <street>545 Technology Square</street> 1150 <city>Cambridge</city> 1151 <region>MA</region> 1152 <code>02139</code> 1153 <country>US</country></postal> 1154 <facsimile>+1 617 258 8682</facsimile> 1155 <email>jg@w3.org</email></address></author> 1156 <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> 1157 <organization>Digital Equipment Corporation, Western Research Laboratory</organization> 1158 <address> 1159 <postal> 1160 <street>250 University Avenue</street> 1161 <city>Palo Alto</city> 1162 <region>CA</region> 1163 <code>94301</code> 1164 <country>US</country></postal> 1165 <email>mogul@wrl.dec.com</email></address></author> 1166 <author initials="H." surname="Nielsen" fullname="Henrik Frystyk Nielsen"> 1167 <organization>MIT Laboratory for Computer Science</organization> 1168 <address> 1169 <postal> 1170 <street>545 Technology Square</street> 1171 <city>Cambridge</city> 1172 <region>MA</region> 1173 <code>02139</code> 1174 <country>US</country></postal> 1175 <facsimile>+1 617 258 8682</facsimile> 1176 <email>frystyk@w3.org</email></address></author> 1177 <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> 1178 <organization>MIT Laboratory for Computer Science</organization> 1179 <address> 1180 <postal> 1181 <street>545 Technology Square</street> 1182 <city>Cambridge</city> 1183 <region>MA</region> 1184 <code>02139</code> 1185 <country>US</country></postal> 1186 <facsimile>+1 617 258 8682</facsimile> 1187 <email>timbl@w3.org</email></address></author> 1188 <date month="January" year="1997"/> 1189 <abstract> 1190 <t>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.</t> 1191 <t>HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1".</t></abstract></front> 1192 <seriesInfo name="RFC" value="2068"/> 1132 <front> 1133 <title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title> 1134 <author initials="R." surname="Fielding" fullname="Roy T. Fielding"> 1135 <organization>University of California, Irvine, Department of Information and Computer Science</organization> 1136 <address><email>fielding@ics.uci.edu</email></address> 1137 </author> 1138 <author initials="J." surname="Gettys" fullname="Jim Gettys"> 1139 <organization>MIT Laboratory for Computer Science</organization> 1140 <address><email>jg@w3.org</email></address> 1141 </author> 1142 <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul"> 1143 <organization>Digital Equipment Corporation, Western Research Laboratory</organization> 1144 <address><email>mogul@wrl.dec.com</email></address> 1145 </author> 1146 <author initials="H." surname="Nielsen" fullname="Henrik Frystyk Nielsen"> 1147 <organization>MIT Laboratory for Computer Science</organization> 1148 <address><email>frystyk@w3.org</email></address> 1149 </author> 1150 <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"> 1151 <organization>MIT Laboratory for Computer Science</organization> 1152 <address><email>timbl@w3.org</email></address> 1153 </author> 1154 <date month="January" year="1997"/> 1155 </front> 1156 <seriesInfo name="RFC" value="2068"/> 1193 1157 </reference> 1194 1158 -
draft-ietf-httpbis/latest/p5-range.html
r96 r97 864 864 <ol> 865 865 <li>Additional CRLFs may precede the first boundary string in the entity.</li> 866 <li>Although RFC 2046<a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> permits the boundary string to be quoted, some existing implementations handle a quoted boundary string incorrectly.866 <li>Although <a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> permits the boundary string to be quoted, some existing implementations handle a quoted boundary string incorrectly. 867 867 </li> 868 868 <li>A number of browsers and servers were coded to an early draft of the byteranges specification to use a media type of multipart/x-byteranges<span id="rfc.iref.m.3"></span><span id="rfc.iref.m.4"></span>, which is almost, but not quite compatible with the version documented in HTTP/1.1. -
draft-ietf-httpbis/latest/p5-range.xml
r96 r97 876 876 877 877 <reference anchor="RFC2046"> 878 <front> 879 <title abbrev="Media Types">Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</title> 880 <author initials="N." surname="Freed" fullname="Ned Freed"> 881 <organization>Innosoft International, Inc.</organization> 882 <address> 883 <postal> 884 <street>1050 East Garvey Avenue South</street> 885 <city>West Covina</city> 886 <region>CA</region> 887 <code>91790</code> 888 <country>US</country></postal> 889 <phone>+1 818 919 3600</phone> 890 <facsimile>+1 818 919 3614</facsimile> 891 <email>ned@innosoft.com</email></address></author> 892 <author initials="N." surname="Borenstein" fullname="Nathaniel S. Borenstein"> 893 <organization>First Virtual Holdings</organization> 894 <address> 895 <postal> 896 <street>25 Washington Avenue</street> 897 <city>Morristown</city> 898 <region>NJ</region> 899 <code>07960</code> 900 <country>US</country></postal> 901 <phone>+1 201 540 8967</phone> 902 <facsimile>+1 201 993 3032</facsimile> 903 <email>nsb@nsb.fv.com</email></address></author> 904 <date month="November" year="1996"/> 905 </front> 906 <seriesInfo name="RFC" value="2046"/> 878 <front> 879 <title abbrev="Media Types">Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</title> 880 <author initials="N." surname="Freed" fullname="Ned Freed"> 881 <organization>Innosoft International, Inc.</organization> 882 <address><email>ned@innosoft.com</email></address> 883 </author> 884 <author initials="N." surname="Borenstein" fullname="Nathaniel S. Borenstein"> 885 <organization>First Virtual Holdings</organization> 886 <address><email>nsb@nsb.fv.com</email></address> 887 </author> 888 <date month="November" year="1996"/> 889 </front> 890 <seriesInfo name="RFC" value="2046"/> 907 891 </reference> 908 892 … … 985 969 entity.</t> 986 970 987 <t>Although RFC 2046<xref target="RFC2046"/> permits the boundary string to be971 <t>Although <xref target="RFC2046"/> permits the boundary string to be 988 972 quoted, some existing implementations handle a quoted boundary 989 973 string incorrectly.</t> -
draft-ietf-httpbis/latest/p6-cache.html
r96 r97 558 558 <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="introduction" href="#introduction">Introduction</a></h1> 559 559 <p id="rfc.section.1.p.1">This document will define aspects of HTTP related to caching response messages. Right now it only includes the extracted relevant 560 sections of < a href="#RFC2616">RFC 2616</a> <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616.2">[RFC2616]</cite> without edit.560 sections of <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616.2">RFC 2616</cite> without edit. 561 561 </p> 562 562 <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="intro.requirements" href="#intro.requirements">Requirements</a></h2> … … 679 679 </dl> 680 680 <h3 id="rfc.section.2.1.1"><a href="#rfc.section.2.1.1">2.1.1</a> <a id="cache.correctness" href="#cache.correctness">Cache Correctness</a></h3> 681 <p id="rfc.section.2.1.1.p.1">A correct cache <em class="bcp14">MUST</em> respond to a request with the most up-to-date response held by the cache that is appropriate to the request (see sections <a href="#disambiguating.expiration.values" title="Disambiguating Expiration Values">2.2.5</a>, <a href="#disambiguating.multiple.responses" title="Disambiguating Multiple Responses">2.2.6</a>, and <a href="#cache.replacement" title="Cache Replacement">2.12</a>) which meets one of the following conditions:681 <p id="rfc.section.2.1.1.p.1">A correct cache <em class="bcp14">MUST</em> respond to a request with the most up-to-date response held by the cache that is appropriate to the request (see Sections <a href="#disambiguating.expiration.values" title="Disambiguating Expiration Values">2.2.5</a>, <a href="#disambiguating.multiple.responses" title="Disambiguating Multiple Responses">2.2.6</a>, and <a href="#cache.replacement" title="Cache Replacement">2.12</a>) which meets one of the following conditions: 682 682 </p> 683 683 <ol> … … 688 688 cache (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.1" title="Cache-Control">Section 3.2</a>); if the origin server so specifies, it is the freshness requirement of the origin server alone. If a stored response is 689 689 not "fresh enough" by the most restrictive freshness requirement of both the client and the origin server, in carefully considered 690 circumstances the cache <em class="bcp14">MAY</em> still return the response with the appropriate Warning header (see section<a href="#exceptions.to.the.rules.and.warnings" title="Exceptions to the Rules and Warnings">2.1.5</a> and <a href="#header.warning" id="rfc.xref.header.warning.1" title="Warning">3.6</a>), unless such a response is prohibited (e.g., by a "no-store" cache-directive, or by a "no-cache" cache-request-directive;690 circumstances the cache <em class="bcp14">MAY</em> still return the response with the appropriate Warning header (see Sections <a href="#exceptions.to.the.rules.and.warnings" title="Exceptions to the Rules and Warnings">2.1.5</a> and <a href="#header.warning" id="rfc.xref.header.warning.1" title="Warning">3.6</a>), unless such a response is prohibited (e.g., by a "no-store" cache-directive, or by a "no-cache" cache-request-directive; 691 691 see <a href="#header.cache-control" id="rfc.xref.header.cache-control.2" title="Cache-Control">Section 3.2</a>). 692 692 </li> … … 1182 1182 </p> 1183 1183 <h2 id="rfc.section.2.12"><a href="#rfc.section.2.12">2.12</a> <a id="cache.replacement" href="#cache.replacement">Cache Replacement</a></h2> 1184 <p id="rfc.section.2.12.p.1">If a new cacheable (see sections <a href="#what.may.be.stored.by.caches" title="What May be Stored by Caches">3.2.2</a>, <a href="#disambiguating.expiration.values" title="Disambiguating Expiration Values">2.2.5</a>, <a href="#disambiguating.multiple.responses" title="Disambiguating Multiple Responses">2.2.6</a> and <a href="#errors.or.incomplete.response.cache.behavior" title="Errors or Incomplete Response Cache Behavior">2.8</a>) response is received from a resource while any existing responses for the same resource are cached, the cache <em class="bcp14">SHOULD</em> use the new response to reply to the current request. It <em class="bcp14">MAY</em> insert it into cache storage and <em class="bcp14">MAY</em>, if it meets all other requirements, use it to respond to any future requests that would previously have caused the old response1184 <p id="rfc.section.2.12.p.1">If a new cacheable (see Sections <a href="#what.may.be.stored.by.caches" title="What May be Stored by Caches">3.2.2</a>, <a href="#disambiguating.expiration.values" title="Disambiguating Expiration Values">2.2.5</a>, <a href="#disambiguating.multiple.responses" title="Disambiguating Multiple Responses">2.2.6</a> and <a href="#errors.or.incomplete.response.cache.behavior" title="Errors or Incomplete Response Cache Behavior">2.8</a>) response is received from a resource while any existing responses for the same resource are cached, the cache <em class="bcp14">SHOULD</em> use the new response to reply to the current request. It <em class="bcp14">MAY</em> insert it into cache storage and <em class="bcp14">MAY</em>, if it meets all other requirements, use it to respond to any future requests that would previously have caused the old response 1185 1185 to be returned. If it inserts the new response into cache storage the rules in <a href="#combining.headers" title="Combining Headers">Section 2.5.3</a> apply. 1186 1186 </p> … … 1642 1642 Content-Language field in a response, etc. The default language is English and the default character set is ISO-8859-1. 1643 1643 </p> 1644 <p id="rfc.section.3.6.p.6">If a character set other than ISO-8859-1 is used, it <em class="bcp14">MUST</em> be encoded in the warn-text using the method described in RFC 2047<a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a>.1644 <p id="rfc.section.3.6.p.6">If a character set other than ISO-8859-1 is used, it <em class="bcp14">MUST</em> be encoded in the warn-text using the method described in <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a>. 1645 1645 </p> 1646 1646 <p id="rfc.section.3.6.p.7">Warning headers can in general be applied to any message, however some specific warn-codes are specific to caches and can -
draft-ietf-httpbis/latest/p6-cache.xml
r96 r97 224 224 This document will define aspects of HTTP related to caching response 225 225 messages. Right now it only includes the extracted relevant sections 226 of <xref target="RFC2616" >RFC 2616</xref> without edit.226 of <xref target="RFC2616" x:fmt="none">RFC 2616</xref> without edit. 227 227 </t> 228 228 … … 458 458 A correct cache &MUST; respond to a request with the most up-to-date 459 459 response held by the cache that is appropriate to the request (see 460 sections <xref target="disambiguating.expiration.values" format="counter"/>,460 Sections <xref target="disambiguating.expiration.values" format="counter"/>, 461 461 <xref target="disambiguating.multiple.responses" format="counter"/>, 462 462 and <xref target="cache.replacement" format="counter"/>) which meets one of the following … … 477 477 origin server, in carefully considered circumstances the cache 478 478 &MAY; still return the response with the appropriate Warning 479 header (see section<xref target="exceptions.to.the.rules.and.warnings" format="counter"/>479 header (see Sections <xref target="exceptions.to.the.rules.and.warnings" format="counter"/> 480 480 and <xref target="header.warning" format="counter"/>), unless such a response 481 481 is prohibited (e.g., by a "no-store" cache-directive, or by a … … 1480 1480 <section title="Cache Replacement" anchor="cache.replacement"> 1481 1481 <t> 1482 If a new cacheable (see sections <xref target="what.may.be.stored.by.caches" format="counter"/>,1482 If a new cacheable (see Sections <xref target="what.may.be.stored.by.caches" format="counter"/>, 1483 1483 <xref target="disambiguating.expiration.values" format="counter"/>, 1484 1484 <xref target="disambiguating.multiple.responses" format="counter"/> … … 2314 2314 <t> 2315 2315 If a character set other than ISO-8859-1 is used, it &MUST; be encoded 2316 in the warn-text using the method described in RFC 2047<xref target="RFC2047"/>.2316 in the warn-text using the method described in <xref target="RFC2047"/>. 2317 2317 </t> 2318 2318 <t> … … 2778 2778 2779 2779 <reference anchor="RFC2047"> 2780 <front> 2781 <title abbrev="Message Header Extensions">MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text</title> 2782 <author initials="K." surname="Moore" fullname="Keith Moore"> 2783 <organization>University of Tennessee</organization> 2784 <address> 2785 <postal> 2786 <street>107 Ayres Hall</street> 2787 <street>Knoxville TN 37996-1301</street></postal> 2788 <email>moore@cs.utk.edu</email></address></author> 2789 <date month="November" year="1996"/> 2790 <area>Applications</area> 2791 <keyword>Amercian Standard Code for Information Interchange</keyword> 2792 <keyword>mail</keyword> 2793 <keyword>multipurpose internet mail extensions</keyword> 2794 </front> 2795 <seriesInfo name="RFC" value="2047"/> 2780 <front> 2781 <title abbrev="Message Header Extensions">MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text</title> 2782 <author initials="K." surname="Moore" fullname="Keith Moore"> 2783 <organization>University of Tennessee</organization> 2784 <address><email>moore@cs.utk.edu</email></address> 2785 </author> 2786 <date month="November" year="1996"/> 2787 </front> 2788 <seriesInfo name="RFC" value="2047"/> 2796 2789 </reference> 2797 2790 -
draft-ietf-httpbis/latest/p7-auth.html
r96 r97 510 510 <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="introduction" href="#introduction">Introduction</a></h1> 511 511 <p id="rfc.section.1.p.1">This document will define aspects of HTTP related to access control and authentication. Right now it only includes the extracted 512 relevant sections of < a href="#RFC2616">RFC 2616</a> <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616.2">[RFC2616]</cite> with only minor edits.512 relevant sections of <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616.2">RFC 2616</cite> with only minor edits. 513 513 </p> 514 514 <p id="rfc.section.1.p.2">HTTP provides several <em class="bcp14">OPTIONAL</em> challenge-response authentication mechanisms which can be used by a server to challenge a client request and by a client to -
draft-ietf-httpbis/latest/p7-auth.xml
r96 r97 210 210 This document will define aspects of HTTP related to access control and 211 211 authentication. Right now it only includes the extracted relevant sections 212 of <xref target="RFC2616" >RFC 2616</xref> with only minor edits.212 of <xref target="RFC2616" x:fmt="none">RFC 2616</xref> with only minor edits. 213 213 </t> 214 214 <t>
Note: See TracChangeset
for help on using the changeset viewer.