Changeset 97


Ignore:
Timestamp:
Dec 23, 2007, 5:22:38 AM (12 years ago)
Author:
julian.reschke@…
Message:

Cleanup references after switch to symbolic references (removing duplicated RFC numbers), clean up some of the references XML code.

Location:
draft-ietf-httpbis/latest
Files:
14 edited

Legend:

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

    r96 r97  
    616616      <p id="rfc.section.1.1.p.1">The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information
    617617         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 the
     618         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
    619619         data transferred and modifiers on the request/response semantics. However, HTTP/1.0 does not sufficiently take into consideration
    620620         the effects of hierarchical proxies, caching, the need for persistent connections, or virtual hosts. In addition, the proliferation
     
    838838      <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="notation.abnf" href="#notation.abnf">Augmented BNF</a></h2>
    839839      <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 includes
     840         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
    841841         the following constructs:
    842842      </p>
     
    934934      <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.14"></span>    LWS            = [CRLF] 1*( SP | HT )
    935935</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>.
    937937      </p>
    938938      <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.15"></span>    TEXT           = &lt;any OCTET except CTLs,
     
    971971         when the changes made to the protocol add features which do not change the general message parsing algorithm, but which may
    972972         add to the message semantics and imply additional capabilities of the sender. The &lt;major&gt; 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.
    974974      </p>
    975975      <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>
     
    980980      <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
    981981         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>.
    983983      </p>
    984984      <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>
     
    987987         the proxy/gateway <em class="bcp14">MUST</em> either downgrade the request version, or respond with an error, or switch to tunnel behavior.
    988988      </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.
    990990      </p>
    991991      <p id="rfc.section.3.1.p.9"> </p>
     
    10011001      <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
    10021002         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",
    10041004         "rel_path", and "authority" from that specification.
    10051005      </p>
     
    10181018      <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 ]]
    10191019</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&nbsp;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&nbsp;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&nbsp;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&nbsp;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.
    10211021      </p>
    10221022      <h3 id="rfc.section.3.2.3"><a href="#rfc.section.3.2.3">3.2.3</a>&nbsp;<a id="uri.comparison" href="#uri.comparison">URI Comparison</a></h3>
     
    10311031         <li>An empty abs_path is equivalent to an abs_path of "/".</li>
    10321032      </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.
    10341034      </p>
    10351035      <p id="rfc.section.3.2.3.p.3">For example, the following three URIs are equivalent:</p>
     
    10431043   Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
    10441044   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 servers
     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 <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
    10461046         that parse the date value <em class="bcp14">MUST</em> accept all three formats (for compatibility with HTTP/1.0), though they <em class="bcp14">MUST</em> only generate the RFC 1123 format for representing HTTP-date values in header fields. See <a href="#tolerant.applications" title="Tolerant Applications">Appendix&nbsp;B</a> for further information.
    10471047      </p>
     
    11681168      <p id="rfc.section.4.1.p.1">HTTP messages consist of requests from client to server and responses from server to client.</p>
    11691169      <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&nbsp;5</a>) and Response (<a href="#response" title="Response">Section&nbsp;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 header
     1170</pre><p id="rfc.section.4.1.p.3">Request (<a href="#request" title="Request">Section&nbsp;5</a>) and Response (<a href="#response" title="Response">Section&nbsp;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
    11711171         fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header
    11721172         fields, and possibly a message-body.
     
    11841184      </p>
    11851185      <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<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&nbsp;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. The
     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&nbsp;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
    11871187         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
    11881188         each extra line with at least one SP or HT. Applications ought to follow "common form", where one is known or indicated, when
     
    14091409         servers and causing congestion on the Internet. The use of inline images and other associated data often require a client
    14101410         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>.
    14121412      </p>
    14131413      <p id="rfc.section.7.1.1.p.2">Persistent HTTP connections have a number of advantages: </p>
     
    14661466         to. Each persistent connection applies to only one transport link.
    14671467      </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).
    14691469      </p>
    14701470      <h3 id="rfc.section.7.1.4"><a href="#rfc.section.7.1.4">7.1.4</a>&nbsp;<a id="persistent.practical" href="#persistent.practical">Practical Considerations</a></h3>
     
    15241524         <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"
    15251525            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-header
     1526            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
    15271527            field with the "100-continue" expectation. This exception, the purpose of which is to minimize any client processing delays
    15281528            associated with an undeclared wait for 100 (Continue) status, applies only to HTTP/1.1 requests, and not to requests with
     
    16341634      <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a>&nbsp;<a id="header.date" href="#header.date">Date</a></h2>
    16351635      <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&nbsp;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&nbsp;3.3.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format.
    16371637      </p>
    16381638      <div id="rfc.figure.u.41"></div><pre class="inline"><span id="rfc.iref.g.73"></span>    Date  = "Date" ":" HTTP-date
     
    16841684         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.
    16851685      </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.
    16871687      </p>
    16881688      <div id="rfc.iref.t.2"></div>
     
    17971797      <h2 id="rfc.section.8.9"><a href="#rfc.section.8.9">8.9</a>&nbsp;<a id="header.via" href="#header.via">Via</a></h2>
    17981798      <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 capabilities
     1799         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
    18001800         of all senders along the request/response chain.
    18011801      </p>
     
    19051905      <p id="rfc.section.10.6.p.1">They exist. They are hard to defend against. Research continues. Beware.</p>
    19061906      <h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a>&nbsp;<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 and
     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 <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
    19081908         Internet mail message formats.
    19091909      </p>
     
    22412241      <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
    22422242         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>.
    22442244      </p>
    22452245      <h2 id="rfc.section.D.1"><a href="#rfc.section.D.1">D.1</a>&nbsp;<a id="changes.from.1.0" href="#changes.from.1.0">Changes from HTTP/1.0</a></h2>
     
    22812281         a new keyword (Connection: close) for declaring non-persistence. See <a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section&nbsp;8.1</a>.
    22822282      </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>.
    22852284      </p>
    22862285      <h2 id="rfc.section.D.3"><a href="#rfc.section.D.3">D.3</a>&nbsp;<a id="changes.from.rfc.2068" href="#changes.from.rfc.2068">Changes from RFC 2068</a></h2>
    22872286      <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>.
    22892288      </p>
    22902289      <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
     
    22922291         computed.
    22932292      </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 to
    2295          highest protocol version they support to deal with problems discovered in HTTP/1.0 implementations (<a href="#http.version" title="HTTP Version">Section&nbsp;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&nbsp;3.1</a>)
    22962295      </p>
    22972296      <p id="rfc.section.D.3.p.4">Proxies should be able to add Content-Length when appropriate.</p>
     
    25402539                  <li class="indline1"><em>RFC2045</em>&nbsp;&nbsp;<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>
    25412540                  <li class="indline1"><em>RFC2047</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2068.3">D</a></li>
     2541                  <li class="indline1"><em>RFC2068</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2068.5">D</a></li>
    25442543                     </ul>
    25452544                  </li>
    25462545                  <li class="indline1"><em>RFC2119</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>
    25482547                  <li class="indline1"><em>RFC2324</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2324.1">1.1</a>, <a class="iref" href="#RFC2324"><b>12</b></a></li>
    25492548                  <li class="indline1"><em>RFC2396</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2396.1">3.2.1</a>, <a class="iref" href="#rfc.xref.RFC2396.2">3.2.3</a>, <a class="iref" href="#rfc.xref.RFC2396.3">5.1.2</a>, <a class="iref" href="#RFC2396"><b>12</b></a></li>
     
    25522551                  <li class="indline1"><em>RFC4288</em>&nbsp;&nbsp;<a class="iref" href="#RFC4288"><b>12</b></a>, <a class="iref" href="#rfc.xref.RFC4288.1">A</a></li>
    25532552                  <li class="indline1"><em>RFC821</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC821.1">1.1</a>, <a class="iref" href="#RFC821"><b>12</b></a></li>
    2554                   <li class="indline1"><em>RFC822</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC822.1">1.1</a>, <a class="iref" href="#rfc.xref.RFC822.2">2.1</a>, <a class="iref" href="#rfc.xref.RFC822.3">3.3.1</a>, <a class="iref" href="#rfc.xref.RFC822.4">4.1</a>, <a class="iref" href="#rfc.xref.RFC822.5">4.2</a>, <a class="iref" href="#rfc.xref.RFC822.6">4.2</a>, <a class="iref" href="#rfc.xref.RFC822.7">8.9</a>, <a class="iref" href="#rfc.xref.RFC822.8">11</a>, <a class="iref" href="#RFC822"><b>12</b></a><ul class="ind">
     2553                  <li class="indline1"><em>RFC822</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC822.1">1.1</a>, <a class="iref" href="#rfc.xref.RFC822.2">2.1</a>, <a class="iref" href="#rfc.xref.RFC822.3">3.3.1</a>, <a class="iref" href="#rfc.xref.RFC822.4">4.1</a>, <a class="iref" href="#rfc.xref.RFC822.5">4.2</a>, <a class="iref" href="#rfc.xref.RFC822.6">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">
    25552554                        <li class="indline1"><em>Section 3.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC822.5">4.2</a></li>
    25562555                     </ul>
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r96 r97  
    243243   information initiative since 1990. The first version of HTTP,
    244244   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"/>, improved
     245   across the Internet. HTTP/1.0, as defined by <xref target="RFC1945"/>, improved
    246246   the protocol by allowing messages to be in the format of MIME-like
    247247   messages, containing metainformation about the data transferred and
     
    661661   All of the mechanisms specified in this document are described in
    662662   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 the
     663   used by <xref target="RFC822"/>. Implementors will need to be familiar with the
    664664   notation in order to understand this specification. The augmented BNF
    665665   includes the following constructs:
     
    865865   that are not intended to be interpreted by the message parser. Words
    866866   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 2047
     867   <xref target="ISO-8859"/> only when encoded according to the rules of
    868868   <xref target="RFC2047"/>.
    869869</t>
     
    942942   additional capabilities of the sender. The &lt;major&gt; number is
    943943   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.
    945945</t>
    946946<t>
     
    965965   "HTTP/1.1" in their messages, and &MUST; do so for any message that is
    966966   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"/>.
    968968</t>
    969969<t>
     
    983983<t>
    984984   Due to interoperability problems with HTTP/1.0 proxies discovered
    985    since the publication of RFC 2068 <xref target="RFC2068"/>, caching proxies &MUST;, gateways
     985   since the publication of <xref target="RFC2068"/>, caching proxies &MUST;, gateways
    986986   &MAY;, and tunnels &MUST-NOT; upgrade the request to the highest version
    987987   they support. The proxy/gateway's response to that request &MUST; be in
     
    10151015   with a scheme name followed by a colon. For definitive information on
    10161016   URL syntax and semantics, see "Uniform Resource Identifiers (URI):
    1017    Generic Syntax and Semantics," RFC 2396 <xref target="RFC2396"/> (which replaces RFCs
    1018    1738 <xref target="RFC1738"/> and RFC 1808 <xref target="RFC1808"/>). This specification adopts the
     1017   Generic Syntax and Semantics," <xref target="RFC2396"/> (which replaces <xref target="RFC1738"/>
     1018   and <xref target="RFC1808"/>). This specification adopts the
    10191019   definitions of "URI-reference", "absoluteURI", "relativeURI", "port",
    10201020   "host","abs_path", "rel_path", and "authority" from that
     
    10541054   for TCP connections on that port of that host, and the Request-URI
    10551055   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"/>). If
     1056   in URLs &SHOULD; be avoided whenever possible (see <xref target="RFC1900"/>). If
    10571057   the abs_path is not present in the URL, it &MUST; be given as "/" when
    10581058   used as a Request-URI for a resource (<xref target="request-uri"/>). If a proxy
     
    10801080<t>
    10811081   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.
    10831083</t>
    10841084<t>
     
    11061106<t>
    11071107   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 to
    1109    RFC 822 <xref target="RFC822"/>). The other formats are described here only for
     1108   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
    11101110   compatibility with obsolete implementations.
    11111111   HTTP/1.1 clients and servers that parse the date value &MUST; accept
     
    13241324<t>
    13251325   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 payload
     1326   message format of <xref target="RFC822"/> for transferring entities (the payload
    13271327   of the message). Both types of message consist of a start-line, zero
    13281328   or more header fields (also known as "headers"), an empty line (i.e.,
     
    13561356   request-header (&request-header-fields;), response-header (&response-header-fields;), and
    13571357   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 consists
     1358   that given in <xref target="RFC822" x:fmt="of" x:sec="3.1"/>. Each header field consists
    13591359   of a name followed by a colon (":") and the field value. Field names
    13601360   are case-insensitive. The field value &MAY; be preceded by any amount
     
    18051805   these performance problems and results from a prototype
    18061806   implementation are available <xref target="Pad1995"/> <xref target="Spe"/>. Implementation experience and
    1807    measurements of actual HTTP/1.1 (RFC 2068) implementations show good
     1807   measurements of actual HTTP/1.1 (<xref target="RFC2068" x:fmt="none">RFC 2068</xref>) implementations show good
    18081808   results <xref target="Nie1997"/>. Alternatives have also been explored, for example,
    18091809   T/TCP <xref target="Tou1998"/>.
     
    19381938<t>
    19391939   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 and
     1940   with an HTTP/1.0 client (but see <xref target="RFC2068"/> for information and
    19411941   discussion of the problems with the Keep-Alive header implemented by
    19421942   many HTTP/1.0 clients).
     
    20752075        100 (Continue) response if such a request comes from an HTTP/1.0
    20762076        (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)
    20782078        status in response to an HTTP/1.1 PUT or POST request that does
    20792079        not include an Expect request-header field with the "100-continue"
     
    23022302   The Date general-header field represents the date and time at which
    23032303   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"/>;
    23052305   it &MUST; be sent in rfc1123-date format.
    23062306</t>
     
    24102410</t>
    24112411<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"/>
    24132413   and <xref target="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" format="counter"/>
    24142414   for other requirements relating to Host.
     
    26252625   agent and the server on requests, and between the origin server and
    26262626   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,
    26282628   avoiding request loops, and identifying the protocol capabilities of
    26292629   all senders along the request/response chain.
     
    28592859<t>
    28602860   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, it
     2861   constructs defined by David H. Crocker for <xref target="RFC822"/>. Similarly, it
    28622862   reuses many of the definitions provided by Nathaniel Borenstein and
    28632863   Ned Freed for MIME <xref target="RFC2045"/>. We hope that their inclusion in this
     
    32043204
    32053205<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"/>
    32473223</reference>
    32483224
    32493225<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"/>
    32913243</reference>
    32923244
    32933245<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"/>
    33233259</reference>
    33243260
    33253261<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"/>
    33423272</reference>
    33433273
    33443274<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"/>
    33603285</reference>
    33613286
     
    33923317
    33933318<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"/>
    34113328</reference>
    34123329
     
    34253342
    34263343<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"/>
    34433353</reference>
    34443354
     
    35573467
    35583468<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"/>
    35843482</reference>
    35853483
     
    36493547
    36503548<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"/>
    37123574</reference>
    37133575
     
    37263588
    37273589<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"/>
    37903611</reference>
    37913612
     
    38143635
    38153636<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"/>
    38553654</reference>
    38563655
     
    40583857   by the client prior to the request and closed by the server after
    40593858   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"/>.
    40623860</t>
    40633861
     
    41333931<t>
    41343932   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"/>.
    41363934</t>
    41373935</section>
     
    41413939   This specification has been carefully audited to correct and
    41423940   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"/>.
    41443942</t>
    41453943<t>
     
    41513949<t>
    41523950   The use and interpretation of HTTP version numbers has been clarified
    4153    by RFC 2145. Require proxies to upgrade requests to highest protocol
     3951   by <xref target="RFC2145"/>. Require proxies to upgrade requests to highest protocol
    41543952   version they support to deal with problems discovered in HTTP/1.0
    41553953   implementations (<xref target="http.version"/>)
  • draft-ietf-httpbis/latest/p2-semantics.html

    r96 r97  
    10961096      </p>
    10971097      <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, most
    1099             existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless
    1100             of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear
    1101             which kind of reaction is expected of 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.
    11021102         </dd>
    11031103      </dl>
     
    11291129      </p>
    11301130      <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. Not
    1132             observing these 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.
    11331133         </dd>
    11341134      </dl>
     
    13911391      <div id="rfc.iref.h.4"></div>
    13921392      <h2 id="rfc.section.10.3"><a href="#rfc.section.10.3">10.3</a>&nbsp;<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>:
    13941394      </p>
    13951395      <div id="rfc.figure.u.10"></div><pre class="inline"><span id="rfc.iref.g.16"></span>    From   = "From" ":" mailbox
     
    15441544      <h1 id="rfc.references"><a href="#rfc.section.14" id="rfc.section.14">14.</a> References
    15451545      </h1>
    1546       <table summary="References">                       
     1546      <table summary="References">                         
    15471547         <tr>
    15481548            <td class="reference"><b id="Luo1998">[Luo1998]</b></td>
     
    15821582            <td class="reference"><b id="RFC1123">[RFC1123]</b></td>
    15831583            <td class="top"><a title="University of Southern California (USC), Information Sciences Institute">Braden, R.</a>, “<a href="http://tools.ietf.org/html/rfc1123">Requirements for Internet Hosts - Application and Support</a>”, STD&nbsp;3, RFC&nbsp;1123, October&nbsp;1989.
     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&nbsp;1945, May&nbsp;1996.
    15841589            </td>
    15851590         </tr>
     
    16461651      <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>)
    16471652      </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>.
    16491654      </p>
    16501655      <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1>
     
    18871892                  <li class="indline1">Retry-After header&nbsp;&nbsp;<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>
    18881893                  <li class="indline1"><em>RFC1123</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>
    18901896                  <li class="indline1"><em>RFC2119</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2119.1">1.1</a>, <a class="iref" href="#RFC2119"><b>14</b></a></li>
    18911897                  <li class="indline1"><em>RFC2616</em>&nbsp;&nbsp;<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  
    11901190   change the conditions under which the request was issued.
    11911191  <list><t>
    1192       <x:h>Note:</x:h> RFC 1945 and RFC 2068 specify that the client is not allowed
     1192      <x:h>Note:</x:h> <xref target="RFC1945"/> and <xref target="RFC2068"/> specify that the client is not allowed
    11931193      to change the method on the redirected request.  However, most
    11941194      existing user agent implementations treat 302 as if it were a 303
     
    12451245   proxy. 305 responses &MUST; only be generated by origin servers.
    12461246  <list><t>
    1247       <x:h>Note:</x:h> RFC 2068 was not clear that 305 was intended to redirect a
     1247      <x:h>Note:</x:h> <xref target="RFC2068"/> was not clear that 305 was intended to redirect a
    12481248      single request, and to be generated by origin servers only.  Not
    12491249      observing these limitations has significant security consequences.
     
    17581758   e-mail address for the human user who controls the requesting user
    17591759   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"/>:
    17611761</t>
    17621762<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="From"/>
     
    23972397
    23982398<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"/>
    24152409</reference>
    24162410
    24172411<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"/>
    24332422</reference>
    24342423
     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
    24352444<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"/>
    24972470</reference>
    24982471
     
    25712544<t>
    25722545   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"/>.
    25752547</t>
    25762548</section>
  • draft-ietf-httpbis/latest/p3-payload.html

    r96 r97  
    620620      </p>
    621621      <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.
    623623         </dd>
    624624      </dl>
     
    637637      </p>
    638638      <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>.
    640640         </dd>
    641641      </dl>
     
    692692      <h3 id="rfc.section.2.3.2"><a href="#rfc.section.2.3.2">2.3.2</a>&nbsp;<a id="multipart.types" href="#multipart.types">Multipart Types</a></h3>
    693693      <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 preserve
     694         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
    695695         the self-delimiting nature of a multipart message-body, wherein the "end" of the message-body is indicated by the ending multipart
    696696         boundary.
    697697      </p>
    698698      <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.
    701700      </p>
    702701      <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
     
    705704      <dl class="empty">
    706705         <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>.
    708707         </dd>
    709708      </dl>
     
    721720         Content-Language fields.
    722721      </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:
    724723      </p>
    725724      <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 )
     
    963962      </p>
    964963      <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&nbsp;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>&nbsp;<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&nbsp;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&nbsp;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>&nbsp;<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&nbsp;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&nbsp;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>&nbsp;<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&nbsp;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>&nbsp;<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>&nbsp;<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   = &lt;base64 of 128 bit MD5 digest as per RFC 1864&gt;
     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>&nbsp;<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&nbsp;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&nbsp;3.2.1</a>.
     1161      </p>
     1162      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<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>&nbsp;<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>&nbsp;<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>&nbsp;<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&nbsp;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>&nbsp;<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&nbsp;draft-ietf-httpbis-p1-messaging-latest (work in progress), December&nbsp;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&nbsp;draft-ietf-httpbis-p2-semantics-latest (work in progress), December&nbsp;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&nbsp;draft-ietf-httpbis-p4-conditional-latest (work in progress), December&nbsp;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&nbsp;draft-ietf-httpbis-p5-range-latest (work in progress), December&nbsp;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&nbsp;draft-ietf-httpbis-p6-cache-latest (work in progress), December&nbsp;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&nbsp;1766, March&nbsp;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&nbsp;1806, June&nbsp;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&nbsp;1864, October&nbsp;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&nbsp;1867, November&nbsp;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&nbsp;1945, May&nbsp;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&nbsp;1950, May&nbsp;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&nbsp;1951, May&nbsp;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&nbsp;1952, May&nbsp;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&nbsp;2045, November&nbsp;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&nbsp;2046, November&nbsp;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&nbsp;2049, November&nbsp;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&nbsp;2068, January&nbsp;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&nbsp;2076, February&nbsp;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&nbsp;2110, March&nbsp;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&nbsp;14, RFC&nbsp;2119, March&nbsp;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&nbsp;2183, August&nbsp;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&nbsp;18, RFC&nbsp;2277, January&nbsp;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&nbsp;2279, January&nbsp;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&nbsp;2616, June&nbsp;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&nbsp;13, RFC&nbsp;4288, December&nbsp;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&nbsp;11, RFC&nbsp;822, August&nbsp;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>&nbsp;<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>&nbsp;<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>&nbsp;<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>&nbsp;<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>&nbsp;<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>&nbsp;<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>&nbsp;<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>&nbsp;<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>&nbsp;<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>&nbsp;<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>&nbsp;<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>&nbsp;<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&nbsp;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&nbsp;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>&nbsp;<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=&lt;content-coding&gt;" 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>&nbsp;<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>&nbsp;<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>&nbsp;<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&nbsp;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>&nbsp;<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>&nbsp;<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&nbsp;7.2</a> for Content-Disposition security issues.
     1428      </p>
     1429      <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<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&nbsp;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&nbsp;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&nbsp;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 &lt;<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>&gt;.
     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&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.1">2.2</a></li>
     1483                  <li class="indline1">Content-Base header&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.9"><b>C</b></a></li>
     1484                  <li class="indline1">Content-Disposition header&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<a class="iref" href="#rfc.iref.d.1">2.2</a></li>
     1495                  <li class="indline1">Derived-From header&nbsp;&nbsp;<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>&nbsp;&nbsp;
     1500                     <ul class="ind">
     1501                        <li class="indline1"><tt>Accept</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.17"><b>5.1</b></a></li>
     1502                        <li class="indline1"><tt>Accept-Charset</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.21"><b>5.2</b></a></li>
     1503                        <li class="indline1"><tt>Accept-Encoding</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.22"><b>5.3</b></a></li>
     1504                        <li class="indline1"><tt>accept-extension</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.20"><b>5.1</b></a></li>
     1505                        <li class="indline1"><tt>Accept-Language</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.24"><b>5.4</b></a></li>
     1506                        <li class="indline1"><tt>accept-params</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.19"><b>5.1</b></a></li>
     1507                        <li class="indline1"><tt>attribute</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.8"><b>2.3</b></a></li>
     1508                        <li class="indline1"><tt>charset</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.1"><b>2.1</b></a></li>
     1509                        <li class="indline1"><tt>codings</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.23"><b>5.3</b></a></li>
     1510                        <li class="indline1"><tt>content-coding</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.2"><b>2.2</b></a></li>
     1511                        <li class="indline1"><tt>content-disposition</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.33"><b>B.1</b></a></li>
     1512                        <li class="indline1"><tt>Content-Encoding</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.26"><b>5.5</b></a></li>
     1513                        <li class="indline1"><tt>Content-Language</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.27"><b>5.6</b></a></li>
     1514                        <li class="indline1"><tt>Content-Location</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.28"><b>5.7</b></a></li>
     1515                        <li class="indline1"><tt>Content-MD5</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.29"><b>5.8</b></a></li>
     1516                        <li class="indline1"><tt>Content-Type</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.31"><b>5.9</b></a></li>
     1517                        <li class="indline1"><tt>disp-extension-parm</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.38"><b>B.1</b></a></li>
     1518                        <li class="indline1"><tt>disp-extension-token</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.37"><b>B.1</b></a></li>
     1519                        <li class="indline1"><tt>disposition-parm</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.35"><b>B.1</b></a></li>
     1520                        <li class="indline1"><tt>disposition-type</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.34"><b>B.1</b></a></li>
     1521                        <li class="indline1"><tt>entity-body</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.16"><b>3.2</b></a></li>
     1522                        <li class="indline1"><tt>entity-header</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.14"><b>3.1</b></a></li>
     1523                        <li class="indline1"><tt>extension-header</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.15"><b>3.1</b></a></li>
     1524                        <li class="indline1"><tt>filename-parm</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.36"><b>B.1</b></a></li>
     1525                        <li class="indline1"><tt>language-range</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.25"><b>5.4</b></a></li>
     1526                        <li class="indline1"><tt>language-tag</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.11"><b>2.5</b></a></li>
     1527                        <li class="indline1"><tt>md5-digest</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.30"><b>5.8</b></a></li>
     1528                        <li class="indline1"><tt>media-range</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.18"><b>5.1</b></a></li>
     1529                        <li class="indline1"><tt>media-type</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.4"><b>2.3</b></a></li>
     1530                        <li class="indline1"><tt>MIME-Version</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.32"><b>A.1</b></a></li>
     1531                        <li class="indline1"><tt>parameter</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.7"><b>2.3</b></a></li>
     1532                        <li class="indline1"><tt>primary-tag</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.12"><b>2.5</b></a></li>
     1533                        <li class="indline1"><tt>qvalue</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.10"><b>2.4</b></a></li>
     1534                        <li class="indline1"><tt>subtag</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.13"><b>2.5</b></a></li>
     1535                        <li class="indline1"><tt>subtype</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.6"><b>2.3</b></a></li>
     1536                        <li class="indline1"><tt>type</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.5"><b>2.3</b></a></li>
     1537                        <li class="indline1"><tt>value</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.9"><b>2.3</b></a></li>
     1538                     </ul>
     1539                  </li>
     1540                  <li class="indline1">gzip&nbsp;&nbsp;<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&nbsp;&nbsp;
     1545                     <ul class="ind">
     1546                        <li class="indline1">Accept&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.11"><b>C</b></a></li>
     1551                        <li class="indline1">Content-Base&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.17"><b>C</b></a></li>
     1552                        <li class="indline1">Content-Disposition&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.12"><b>C</b></a></li>
     1559                        <li class="indline1">Derived-From&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.13"><b>C</b></a></li>
     1560                        <li class="indline1">Link&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.14"><b>C</b></a></li>
     1561                        <li class="indline1">Public&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.16"><b>C</b></a></li>
     1562                        <li class="indline1">URI&nbsp;&nbsp;<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&nbsp;&nbsp;<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&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.2">3.2</a></li>
     1578                        <li class="indline1"><em>Section 4.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.3">3.2.2</a></li>
     1579                        <li class="indline1"><em>Section 8.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">3.1</a></li>
     1580                        <li class="indline1"><em>Section 8.7</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.4">A.5</a></li>
     1581                     </ul>
     1582                  </li>
     1583                  <li class="indline1"><em>Part2</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">3.1</a></li>
     1585                        <li class="indline1"><em>Section 10.9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.2">4.1</a></li>
     1586                     </ul>
     1587                  </li>
     1588                  <li class="indline1"><em>Part4</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part4.1">3.1</a></li>
     1590                     </ul>
     1591                  </li>
     1592                  <li class="indline1"><em>Part5</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part5.2">3.1</a></li>
     1594                        <li class="indline1"><em>Section A</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part5.1">2.3.2</a></li>
     1595                     </ul>
     1596                  </li>
     1597                  <li class="indline1"><em>Part6</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.1">3.1</a></li>
     1599                     </ul>
     1600                  </li>
     1601                  <li class="indline1">Public header&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2046.1">2.3.2</a></li>
     1616                     </ul>
     1617                  </li>
     1618                  <li class="indline1"><em>RFC2049</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2049.1">A.2</a></li>
     1620                     </ul>
     1621                  </li>
     1622                  <li class="indline1"><em>RFC2068</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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&nbsp;&nbsp;<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  
    348348    <t>
    349349        An encoding format produced by the file compression program
    350         "gzip" (GNU zip) as described in RFC 1952 <xref target="RFC1952"/>. This format is a
     350        "gzip" (GNU zip) as described in <xref target="RFC1952"/>. This format is a
    351351        Lempel-Ziv coding (LZ77) with a 32 bit CRC.
    352352    </t>
     
    371371   deflate<iref item="deflate"/>
    372372  <list><t>
    373         The "zlib" format defined in RFC 1950 <xref target="RFC1950"/> in combination with
    374         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"/>.
    375375  </t></list>
    376376</t>
     
    477477   MIME provides for a number of "multipart" types -- encapsulations of
    478478   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 2046
    480    <xref target="RFC2046"/>, and &MUST; include a boundary parameter as part of the media type
     479   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
    481481   value. The message body is itself a protocol element and &MUST;
    482482   therefore use only CRLF to represent line breaks between body-parts.
     
    492492   any other media type: strictly as payload. The one exception is the
    493493   "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
    495497   other cases, an HTTP user agent &SHOULD; follow the same or similar
    496498   behavior as a MIME user agent would upon receipt of a multipart type.
     
    508510      <x:h>Note:</x:h> The "multipart/form-data" type has been specifically defined
    509511      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"/>.
    511513</t></list></t>
    512514</section>
     
    545547<t>
    546548   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 1
     549   defined by <xref target="RFC1766"/>. In summary, a language tag is composed of 1
    548550   or more parts: A primary language tag and a possibly empty series of
    549551   subtags:
     
    12911293  <iref primary="true" item="Headers" subitem="Content-MD5" x:for-anchor=""/>
    12921294<t>
    1293    The Content-MD5 entity-header field, as defined in RFC 1864 <xref target="RFC1864"/>, is
     1295   The Content-MD5 entity-header field, as defined in <xref target="RFC1864"/>, is
    12941296   an MD5 digest of the entity-body for the purpose of providing an
    12951297   end-to-end message integrity check (MIC) of the entity-body. (Note: a
     
    14411443<section title="Content-Disposition Issues" anchor="content-disposition.issues">
    14421444<t>
    1443    RFC 1806 <xref target="RFC1806"/>, from which the often implemented Content-Disposition
     1445   <xref target="RFC1806"/>, from which the often implemented Content-Disposition
    14441446   (see <xref target="content-disposition"/>) header in HTTP is derived, has a number of very
    14451447   serious security considerations. Content-Disposition is not part of
    14461448   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.
    14491451</t>
    14501452</section>
     
    17201722
    17211723<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"/>
    17381733</reference>
    17391734
    17401735<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"/>
    17701749</reference>
    17711750
    17721751<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"/>
    17881762</reference>
    17891763
    17901764<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"/>
    18211778</reference>
    18221779
     
    18431800
    18441801<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>
    18621816
    18631817<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"/>
    19251841</reference>
    19261842
    19271843<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"/>
    19461853</reference>
    19471854
    19481855<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"/>
    19701868</reference>
    19711869
    19721870<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"/>
    20341896</reference>
    20351897
    20361898<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"/>
    20661932</reference>
    20671933
    20681934<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"/>
    20851944</reference>
    20861945
     
    21211980
    21221981<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"/>
    21521995</reference>
    21531996
     
    22062049
    22072050<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"/>
    22382064</reference>
    22392065
    22402066<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"/>
    22832084</reference>
    22842085
     
    22872088<section title="Differences Between HTTP Entities and RFC 2045 Entities" anchor="differences.between.http.entities.and.rfc.2045.entities">
    22882089<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
    22912091   allow entities to be transmitted in an open variety of
    22922092   representations and with extensible mechanisms. However, RFC 2045
     
    23282128<section title="Conversion to Canonical Form" anchor="conversion.to.canonical.form">
    23292129<t>
    2330    RFC 2045 <xref target="RFC2045"/> requires that an Internet mail entity be converted to
    2331    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 forms
     2130   <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
    23332133   allowed for subtypes of the "text" media type when transmitted over
    2334    HTTP. RFC 2046 requires that content with a type of "text" represent
     2134   HTTP. <xref target="RFC2046"/> requires that content with a type of "text" represent
    23352135   line breaks as CRLF and forbids the use of CR or LF outside of line
    23362136   break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a
     
    24122212<section title="Additional Features" anchor="additional.features">
    24132213<t>
    2414    RFC 1945 and RFC 2068 document protocol elements used by some
     2214   <xref target="RFC1945"/> and <xref target="RFC2068"/> document protocol elements used by some
    24152215   existing HTTP implementations, but not consistently and correctly
    24162216   across most HTTP/1.1 applications. Implementors are advised to be
     
    24232223<t>
    24242224   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"/>).
    24262226</t>
    24272227
     
    24332233   means for the origin server to suggest a default filename if the user
    24342234   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"/>.
    24362236</t>
    24372237<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"/>
     
    24902290   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
    24912291   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"/>.
    24932293</t>
    24942294</section>
  • draft-ietf-httpbis/latest/p4-conditional.html

    r96 r97  
    550550      </ul>
    551551      <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.
    553553      </p>
    554554      <ul>
     
    718718      <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="header.etag" href="#header.etag">ETag</a></h2>
    719719      <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&nbsp;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&nbsp;4</a>).
    721721      </p>
    722722      <div id="rfc.figure.u.2"></div><pre class="inline"><span id="rfc.iref.g.4"></span>    ETag = "ETag" ":" entity-tag
     
    10371037            </li>
    10381038            <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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2068.2">3.1</a></li>
     1039                  <li class="indline1"><em>RFC2068</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2068.1">3.1</a></li>
    10411041                     </ul>
    10421042                  </li>
  • draft-ietf-httpbis/latest/p4-conditional.xml

    r96 r97  
    294294   If a clockless origin server obeys these rules, and proxies and
    295295   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 operate
     296   already specified by <xref target="RFC2068" x:sec="14.19" x:fmt=","/>), caches will operate
    297297   correctly.
    298298  <list style="symbols">
     
    586586   The ETag response-header field provides the current value of the
    587587   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 tag
     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 tag
    589589   &MAY; be used for comparison with other entities from the same resource
    590590   (see <xref target="weak.and.strong.validators"/>).
     
    11301130
    11311131<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"/>
    11931157</reference>
    11941158
  • draft-ietf-httpbis/latest/p5-range.html

    r96 r97  
    864864      <ol>
    865865         <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.
    867867         </li>
    868868         <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  
    876876
    877877<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"/>
    907891</reference>
    908892
     
    985969         entity.</t>
    986970
    987       <t>Although RFC 2046 <xref target="RFC2046"/> permits the boundary string to be
     971      <t>Although <xref target="RFC2046"/> permits the boundary string to be
    988972         quoted, some existing implementations handle a quoted boundary
    989973         string incorrectly.</t>
  • draft-ietf-httpbis/latest/p6-cache.html

    r96 r97  
    558558      <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a id="introduction" href="#introduction">Introduction</a></h1>
    559559      <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.
    561561      </p>
    562562      <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a id="intro.requirements" href="#intro.requirements">Requirements</a></h2>
     
    679679      </dl>
    680680      <h3 id="rfc.section.2.1.1"><a href="#rfc.section.2.1.1">2.1.1</a>&nbsp;<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:
    682682      </p>
    683683      <ol>
     
    688688            cache (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.1" title="Cache-Control">Section&nbsp;3.2</a>); if the origin server so specifies, it is the freshness requirement of the origin server alone. If a stored response is
    689689            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;
    691691            see <a href="#header.cache-control" id="rfc.xref.header.cache-control.2" title="Cache-Control">Section&nbsp;3.2</a>).
    692692         </li>
     
    11821182      </p>
    11831183      <h2 id="rfc.section.2.12"><a href="#rfc.section.2.12">2.12</a>&nbsp;<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 response
     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 response
    11851185         to be returned. If it inserts the new response into cache storage the rules in <a href="#combining.headers" title="Combining Headers">Section&nbsp;2.5.3</a> apply.
    11861186      </p>
     
    16421642         Content-Language field in a response, etc. The default language is English and the default character set is ISO-8859-1.
    16431643      </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>.
    16451645      </p>
    16461646      <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  
    224224   This document will define aspects of HTTP related to caching response
    225225   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.
    227227</t>
    228228
     
    458458   A correct cache &MUST; respond to a request with the most up-to-date
    459459   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"/>,
    461461   <xref target="disambiguating.multiple.responses" format="counter"/>,
    462462   and <xref target="cache.replacement" format="counter"/>) which meets one of the following
     
    477477         origin server, in carefully considered circumstances the cache
    478478         &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"/>
    480480         and <xref target="header.warning" format="counter"/>), unless such a response
    481481         is prohibited (e.g., by a "no-store" cache-directive, or by a
     
    14801480<section title="Cache Replacement" anchor="cache.replacement">
    14811481<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"/>,
    14831483   <xref target="disambiguating.expiration.values" format="counter"/>,
    14841484   <xref target="disambiguating.multiple.responses" format="counter"/>
     
    23142314<t>
    23152315   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"/>.
    23172317</t>
    23182318<t>
     
    27782778
    27792779<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"/>
    27962789</reference>
    27972790
  • draft-ietf-httpbis/latest/p7-auth.html

    r96 r97  
    510510      <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a id="introduction" href="#introduction">Introduction</a></h1>
    511511      <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.
    513513      </p>
    514514      <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  
    210210   This document will define aspects of HTTP related to access control and
    211211   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.
    213213</t>
    214214<t>
Note: See TracChangeset for help on using the changeset viewer.