Changeset 1645 for draft-ietf-httpbis
- Timestamp:
- 30/03/12 15:39:09 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 5 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1643 r1645 757 757 <p id="rfc.section.1.p.1">The Hypertext Transfer Protocol (HTTP) is an application-level request/response protocol that uses extensible semantics and 758 758 MIME-like message payloads for flexible interaction with network-based hypertext information systems. HTTP relies upon the 759 Uniform Resource Identifier (URI) standard <a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> to indicate the target resource (<a href="#target-resource" title="Identifying a Target Resource">Section 5.1</a>) and relationships between resources. Messages are passed in a format similar to that used by Internet mail <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</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> (see <a href="p2-semantics.html#differences.between.http.and.mime" title="Differences between HTTP and MIME">Appendix D. 8</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for the differences between HTTP and MIME messages).759 Uniform Resource Identifier (URI) standard <a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> to indicate the target resource (<a href="#target-resource" title="Identifying a Target Resource">Section 5.1</a>) and relationships between resources. Messages are passed in a format similar to that used by Internet mail <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</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> (see <a href="p2-semantics.html#differences.between.http.and.mime" title="Differences between HTTP and MIME">Appendix D.6</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for the differences between HTTP and MIME messages). 760 760 </p> 761 761 <p id="rfc.section.1.p.2">HTTP is a generic interface protocol for information systems. It is designed to hide the details of how a service is implemented … … 1223 1223 ; see <a href="#field.parsing" title="Field Parsing">Section 3.2.2</a> 1224 1224 </pre><p id="rfc.section.3.2.p.3">The field-name token labels the corresponding field-value as having the semantics defined by that header field. For example, 1225 the Date header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 7. 2</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears.1225 the Date header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 7.10</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears. 1226 1226 </p> 1227 1227 <p id="rfc.section.3.2.p.4">HTTP header fields are fully extensible: there is no limit on the introduction of new field names, each presumably defining … … 1418 1418 <p id="rfc.section.3.3.1.p.6">If more than one Transfer-Encoding header field is present in a message, the multiple field-values <em class="bcp14">MUST</em> be combined into one field-value, according to the algorithm defined in <a href="#header.fields" title="Header Fields">Section 3.2</a>, before determining the message body length. 1419 1419 </p> 1420 <p id="rfc.section.3.3.1.p.7">Unlike Content-Encoding (<a href="p2-semantics.html#content.codings" title="Content Codings"> Appendix D.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.1420 <p id="rfc.section.3.3.1.p.7">Unlike Content-Encoding (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 6.4</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification. 1421 1421 </p> 1422 1422 <p id="rfc.section.3.3.1.p.8">Transfer-Encoding <em class="bcp14">MAY</em> be sent in a response to a HEAD request or in a 304 response to a GET request, neither of which includes a message body, to … … 1725 1725 </p> 1726 1726 <h3 id="rfc.section.4.3.1"><a href="#rfc.section.4.3.1">4.3.1</a> <a id="quality.values" href="#quality.values">Quality Values</a></h3> 1727 <p id="rfc.section.4.3.1.p.1">Both transfer codings (TE request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section 4.3</a>) and content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Appendix D. 4</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight1727 <p id="rfc.section.4.3.1.p.1">Both transfer codings (TE request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section 4.3</a>) and content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Appendix D.3</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight 1728 1728 is normalized to a real number in the range 0 through 1, where 0 is the minimum and 1 the maximum value. If a parameter has 1729 1729 a quality value of 0, then content with this parameter is "not acceptable" for the client. HTTP/1.1 applications <em class="bcp14">MUST NOT</em> generate more than three digits after the decimal point. User configuration of these values <em class="bcp14">SHOULD</em> also be limited in this fashion. … … 2187 2187 <p id="rfc.section.6.4.3.p.2">Requirements for HTTP/1.1 clients: </p> 2188 2188 <ul> 2189 <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 7. 3</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.2190 </li> 2191 <li>A client <em class="bcp14">MUST NOT</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 7. 3</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body.2189 <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 7.11</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation. 2190 </li> 2191 <li>A client <em class="bcp14">MUST NOT</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 7.11</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body. 2192 2192 </li> 2193 2193 </ul> … … 2534 2534 <li>Pointer to specification text</li> 2535 2535 </ul> 2536 <p id="rfc.section.7.4.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings"> Appendix D.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) unless the encoding transformation is identical, as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section 4.2</a>.2536 <p id="rfc.section.7.4.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 6.4</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) unless the encoding transformation is identical, as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section 4.2</a>. 2537 2537 </p> 2538 2538 <p id="rfc.section.7.4.p.4">Values to be added to this name space require IETF Review (see <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of transfer coding defined in this section. … … 3758 3758 <li><em>Section 4.6</em> <a href="#rfc.xref.Part2.25">8.6</a></li> 3759 3759 <li><em>Section 4.6.12</em> <a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.24">8.6</a></li> 3760 <li><em>Section 7.2</em> <a href="#rfc.xref.Part2.7">3.2</a></li>3761 <li><em>Section 7. 3</em> <a href="#rfc.xref.Part2.19">6.4.3</a>, <a href="#rfc.xref.Part2.20">6.4.3</a></li>3762 <li><em> Appendix D.1.2</em> <a href="#rfc.xref.Part2.9">3.3.1</a>, <a href="#rfc.xref.Part2.23">7.4</a></li>3763 <li><em>Appendix D. 4</em> <a href="#rfc.xref.Part2.10">4.3.1</a></li>3764 <li><em>Appendix D. 8</em> <a href="#rfc.xref.Part2.1">1</a></li>3760 <li><em>Section 6.4</em> <a href="#rfc.xref.Part2.9">3.3.1</a>, <a href="#rfc.xref.Part2.23">7.4</a></li> 3761 <li><em>Section 7.10</em> <a href="#rfc.xref.Part2.7">3.2</a></li> 3762 <li><em>Section 7.11</em> <a href="#rfc.xref.Part2.19">6.4.3</a>, <a href="#rfc.xref.Part2.20">6.4.3</a></li> 3763 <li><em>Appendix D.3</em> <a href="#rfc.xref.Part2.10">4.3.1</a></li> 3764 <li><em>Appendix D.6</em> <a href="#rfc.xref.Part2.1">1</a></li> 3765 3765 </ul> 3766 3766 </li> -
draft-ietf-httpbis/latest/p2-semantics.html
r1644 r1645 708 708 </li> 709 709 <li>7. <a href="#header.field.definitions">Header Field Definitions</a><ul> 710 <li>7.1 <a href="#header.allow">Allow</a></li> 711 <li>7.2 <a href="#header.date">Date</a></li> 712 <li>7.3 <a href="#header.expect">Expect</a></li> 713 <li>7.4 <a href="#header.from">From</a></li> 714 <li>7.5 <a href="#header.location">Location</a></li> 715 <li>7.6 <a href="#header.max-forwards">Max-Forwards</a></li> 716 <li>7.7 <a href="#header.referer">Referer</a></li> 717 <li>7.8 <a href="#header.retry-after">Retry-After</a></li> 718 <li>7.9 <a href="#header.server">Server</a></li> 719 <li>7.10 <a href="#header.user-agent">User-Agent</a></li> 710 <li>7.1 <a href="#header.accept">Accept</a></li> 711 <li>7.2 <a href="#header.accept-charset">Accept-Charset</a></li> 712 <li>7.3 <a href="#header.accept-encoding">Accept-Encoding</a></li> 713 <li>7.4 <a href="#header.accept-language">Accept-Language</a></li> 714 <li>7.5 <a href="#header.allow">Allow</a></li> 715 <li>7.6 <a href="#header.content-encoding">Content-Encoding</a></li> 716 <li>7.7 <a href="#header.content-language">Content-Language</a></li> 717 <li>7.8 <a href="#header.content-location">Content-Location</a></li> 718 <li>7.9 <a href="#header.content-type">Content-Type</a></li> 719 <li>7.10 <a href="#header.date">Date</a></li> 720 <li>7.11 <a href="#header.expect">Expect</a></li> 721 <li>7.12 <a href="#header.from">From</a></li> 722 <li>7.13 <a href="#header.location">Location</a></li> 723 <li>7.14 <a href="#header.max-forwards">Max-Forwards</a></li> 724 <li>7.15 <a href="#header.referer">Referer</a></li> 725 <li>7.16 <a href="#header.retry-after">Retry-After</a></li> 726 <li>7.17 <a href="#header.server">Server</a></li> 727 <li>7.18 <a href="#header.user-agent">User-Agent</a></li> 720 728 </ul> 721 729 </li> … … 782 790 </ul> 783 791 </li> 784 <li>D.4 <a href="#header.field.definitions3">Header Field Definitions</a><ul> 785 <li>D.4.1 <a href="#header.accept">Accept</a></li> 786 <li>D.4.2 <a href="#header.accept-charset">Accept-Charset</a></li> 787 <li>D.4.3 <a href="#header.accept-encoding">Accept-Encoding</a></li> 788 <li>D.4.4 <a href="#header.accept-language">Accept-Language</a></li> 789 <li>D.4.5 <a href="#header.content-encoding">Content-Encoding</a></li> 790 <li>D.4.6 <a href="#header.content-language">Content-Language</a></li> 791 <li>D.4.7 <a href="#header.content-location">Content-Location</a></li> 792 <li>D.4.8 <a href="#header.content-type">Content-Type</a></li> 792 <li>D.4 <a href="#IANA.considerations3">IANA Considerations</a><ul> 793 <li>D.4.1 <a href="#content.coding.registration">Content Coding Registry</a></li> 793 794 </ul> 794 795 </li> 795 <li>D.5 <a href="# IANA.considerations3">IANAConsiderations</a><ul>796 <li>D.5.1 <a href="# content.coding.registration">Content Coding Registry</a></li>796 <li>D.5 <a href="#security.considerations3">Security Considerations</a><ul> 797 <li>D.5.1 <a href="#privacy.issues.connected.to.accept.header.fields">Privacy Issues Connected to Accept Header Fields</a></li> 797 798 </ul> 798 799 </li> 799 <li>D.6 <a href="#security.considerations3">Security Considerations</a><ul> 800 <li>D.6.1 <a href="#privacy.issues.connected.to.accept.header.fields">Privacy Issues Connected to Accept Header Fields</a></li> 800 <li>D.6 <a href="#differences.between.http.and.mime">Differences between HTTP and MIME</a><ul> 801 <li>D.6.1 <a href="#mime-version">MIME-Version</a></li> 802 <li>D.6.2 <a href="#conversion.to.canonical.form">Conversion to Canonical Form</a></li> 803 <li>D.6.3 <a href="#conversion.of.date.formats">Conversion of Date Formats</a></li> 804 <li>D.6.4 <a href="#introduction.of.content-encoding">Introduction of Content-Encoding</a></li> 805 <li>D.6.5 <a href="#no.content-transfer-encoding">No Content-Transfer-Encoding</a></li> 806 <li>D.6.6 <a href="#introduction.of.transfer-encoding">Introduction of Transfer-Encoding</a></li> 807 <li>D.6.7 <a href="#mhtml.line.length">MHTML and Line Length Limitations</a></li> 801 808 </ul> 802 809 </li> 803 <li>D.7 <a href="#differences.between.http.and.mime">Differences between HTTP and MIME</a><ul> 804 <li>D.7.1 <a href="#mime-version">MIME-Version</a></li> 805 <li>D.7.2 <a href="#conversion.to.canonical.form">Conversion to Canonical Form</a></li> 806 <li>D.7.3 <a href="#conversion.of.date.formats">Conversion of Date Formats</a></li> 807 <li>D.7.4 <a href="#introduction.of.content-encoding">Introduction of Content-Encoding</a></li> 808 <li>D.7.5 <a href="#no.content-transfer-encoding">No Content-Transfer-Encoding</a></li> 809 <li>D.7.6 <a href="#introduction.of.transfer-encoding">Introduction of Transfer-Encoding</a></li> 810 <li>D.7.7 <a href="#mhtml.line.length">MHTML and Line Length Limitations</a></li> 811 </ul> 812 </li> 813 <li>D.8 <a href="#additional.features">Additional Features</a></li> 814 <li>D.9 <a href="#changes.from.rfc.2616-3">Changes from RFC 2616</a></li> 815 <li>D.10 <a href="#change.log3">Change Log (to be removed by RFC Editor before publication)</a><ul> 816 <li>D.10.1 <a href="#rfc.section.D.10.1">Since RFC 2616</a></li> 817 <li>D.10.2 <a href="#rfc.section.D.10.2">Since draft-ietf-httpbis-p3-payload-00</a></li> 818 <li>D.10.3 <a href="#rfc.section.D.10.3">Since draft-ietf-httpbis-p3-payload-01</a></li> 819 <li>D.10.4 <a href="#changes.3.since.02">Since draft-ietf-httpbis-p3-payload-02</a></li> 820 <li>D.10.5 <a href="#changes.3.since.03">Since draft-ietf-httpbis-p3-payload-03</a></li> 821 <li>D.10.6 <a href="#changes.3.since.04">Since draft-ietf-httpbis-p3-payload-04</a></li> 822 <li>D.10.7 <a href="#changes.3.since.05">Since draft-ietf-httpbis-p3-payload-05</a></li> 823 <li>D.10.8 <a href="#changes.3.since.06">Since draft-ietf-httpbis-p3-payload-06</a></li> 824 <li>D.10.9 <a href="#changes.3.since.07">Since draft-ietf-httpbis-p3-payload-07</a></li> 825 <li>D.10.10 <a href="#changes.3.since.08">Since draft-ietf-httpbis-p3-payload-08</a></li> 826 <li>D.10.11 <a href="#changes.3.since.09">Since draft-ietf-httpbis-p3-payload-09</a></li> 827 <li>D.10.12 <a href="#changes.3.since.10">Since draft-ietf-httpbis-p3-payload-10</a></li> 828 <li>D.10.13 <a href="#changes.3.since.11">Since draft-ietf-httpbis-p3-payload-11</a></li> 829 <li>D.10.14 <a href="#changes.3.since.12">Since draft-ietf-httpbis-p3-payload-12</a></li> 830 <li>D.10.15 <a href="#changes.3.since.13">Since draft-ietf-httpbis-p3-payload-13</a></li> 831 <li>D.10.16 <a href="#changes.3.since.14">Since draft-ietf-httpbis-p3-payload-14</a></li> 832 <li>D.10.17 <a href="#changes.3.since.15">Since draft-ietf-httpbis-p3-payload-15</a></li> 833 <li>D.10.18 <a href="#changes.3.since.16">Since draft-ietf-httpbis-p3-payload-16</a></li> 834 <li>D.10.19 <a href="#changes.3.since.17">Since draft-ietf-httpbis-p3-payload-17</a></li> 835 <li>D.10.20 <a href="#changes.3.since.18">Since draft-ietf-httpbis-p3-payload-18</a></li> 836 <li>D.10.21 <a href="#changes.3.since.19">Since draft-ietf-httpbis-p3-payload-19</a></li> 810 <li>D.7 <a href="#additional.features">Additional Features</a></li> 811 <li>D.8 <a href="#changes.from.rfc.2616-3">Changes from RFC 2616</a></li> 812 <li>D.9 <a href="#change.log3">Change Log (to be removed by RFC Editor before publication)</a><ul> 813 <li>D.9.1 <a href="#rfc.section.D.9.1">Since RFC 2616</a></li> 814 <li>D.9.2 <a href="#rfc.section.D.9.2">Since draft-ietf-httpbis-p3-payload-00</a></li> 815 <li>D.9.3 <a href="#rfc.section.D.9.3">Since draft-ietf-httpbis-p3-payload-01</a></li> 816 <li>D.9.4 <a href="#changes.3.since.02">Since draft-ietf-httpbis-p3-payload-02</a></li> 817 <li>D.9.5 <a href="#changes.3.since.03">Since draft-ietf-httpbis-p3-payload-03</a></li> 818 <li>D.9.6 <a href="#changes.3.since.04">Since draft-ietf-httpbis-p3-payload-04</a></li> 819 <li>D.9.7 <a href="#changes.3.since.05">Since draft-ietf-httpbis-p3-payload-05</a></li> 820 <li>D.9.8 <a href="#changes.3.since.06">Since draft-ietf-httpbis-p3-payload-06</a></li> 821 <li>D.9.9 <a href="#changes.3.since.07">Since draft-ietf-httpbis-p3-payload-07</a></li> 822 <li>D.9.10 <a href="#changes.3.since.08">Since draft-ietf-httpbis-p3-payload-08</a></li> 823 <li>D.9.11 <a href="#changes.3.since.09">Since draft-ietf-httpbis-p3-payload-09</a></li> 824 <li>D.9.12 <a href="#changes.3.since.10">Since draft-ietf-httpbis-p3-payload-10</a></li> 825 <li>D.9.13 <a href="#changes.3.since.11">Since draft-ietf-httpbis-p3-payload-11</a></li> 826 <li>D.9.14 <a href="#changes.3.since.12">Since draft-ietf-httpbis-p3-payload-12</a></li> 827 <li>D.9.15 <a href="#changes.3.since.13">Since draft-ietf-httpbis-p3-payload-13</a></li> 828 <li>D.9.16 <a href="#changes.3.since.14">Since draft-ietf-httpbis-p3-payload-14</a></li> 829 <li>D.9.17 <a href="#changes.3.since.15">Since draft-ietf-httpbis-p3-payload-15</a></li> 830 <li>D.9.18 <a href="#changes.3.since.16">Since draft-ietf-httpbis-p3-payload-16</a></li> 831 <li>D.9.19 <a href="#changes.3.since.17">Since draft-ietf-httpbis-p3-payload-17</a></li> 832 <li>D.9.20 <a href="#changes.3.since.18">Since draft-ietf-httpbis-p3-payload-18</a></li> 833 <li>D.9.21 <a href="#changes.3.since.19">Since draft-ietf-httpbis-p3-payload-19</a></li> 837 834 </ul> 838 835 </li> … … 918 915 </p> 919 916 <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.1"></span> <a href="#methods" class="smpl">method</a> = <a href="#core.rules" class="smpl">token</a> 920 </pre><p id="rfc.section.2.p.3">The list of methods allowed by a resource can be specified in an Allow header field (<a href="#header.allow" id="rfc.xref.header.allow.1" title="Allow">Section 7. 1</a>). The status code of the response always notifies the client whether a method is currently allowed on a resource, since the917 </pre><p id="rfc.section.2.p.3">The list of methods allowed by a resource can be specified in an Allow header field (<a href="#header.allow" id="rfc.xref.header.allow.1" title="Allow">Section 7.5</a>). The status code of the response always notifies the client whether a method is currently allowed on a resource, since the 921 918 set of allowed methods can change dynamically. An origin server <em class="bcp14">SHOULD</em> respond with the status code 405 (Method Not Allowed) if the method is known by the origin server but not allowed for the 922 919 resource, and 501 (Not Implemented) if the method is unrecognized or not implemented by the origin server. The methods GET … … 998 995 but might be defined by future extensions to HTTP. Content negotiation <em class="bcp14">MAY</em> be used to select the appropriate response format. If no response body is included, the response <em class="bcp14">MUST</em> include a Content-Length field with a field-value of "0". 999 996 </p> 1000 <p id="rfc.section.2.3.1.p.7">The Max-Forwards header field <em class="bcp14">MAY</em> be used to target a specific proxy in the request chain (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section 7. 6</a>). If no Max-Forwards field is present in the request, then the forwarded request <em class="bcp14">MUST NOT</em> include a Max-Forwards field.997 <p id="rfc.section.2.3.1.p.7">The Max-Forwards header field <em class="bcp14">MAY</em> be used to target a specific proxy in the request chain (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section 7.14</a>). If no Max-Forwards field is present in the request, then the forwarded request <em class="bcp14">MUST NOT</em> include a Max-Forwards field. 1001 998 </p> 1002 999 <h3 id="rfc.section.2.3.2"><a href="#rfc.section.2.3.2">2.3.2</a> <a id="GET" href="#GET">GET</a></h3> … … 1056 1053 </p> 1057 1054 <p id="rfc.section.2.3.4.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be 201 (Created) and contain a representation which describes the status of the request and refers to the new resource, and 1058 a Location header field (see <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section 7. 5</a>).1059 </p> 1060 <p id="rfc.section.2.3.4.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header field (see <a href="#header.content-location" id="rfc.xref.header.content-location.1" title="Content-Location"> Appendix D.4.7</a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.1055 a Location header field (see <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section 7.13</a>). 1056 </p> 1057 <p id="rfc.section.2.3.4.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header field (see <a href="#header.content-location" id="rfc.xref.header.content-location.1" title="Content-Location">Section 7.8</a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests. 1061 1058 </p> 1062 1059 <p id="rfc.section.2.3.4.p.6">Note that POST caching is not widely implemented. However, the 303 (See Other) response can be used to direct the user agent … … 1146 1143 <div id="rfc.iref.m.7"></div> 1147 1144 <p id="rfc.section.2.3.7.p.1">The TRACE method requests a remote, application-layer loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the message body of a 200 (OK) response. The final recipient is either 1148 the origin server or the first proxy to receive a Max-Forwards value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section 7. 6</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message body.1145 the origin server or the first proxy to receive a Max-Forwards value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section 7.14</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message body. 1149 1146 </p> 1150 1147 <p id="rfc.section.2.3.7.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing … … 1221 1218 double quotes will likely cause unnecessary confusion. 1222 1219 </p> 1223 <p id="rfc.section.3.1.p.8">Many header fields use a format including (case-insensitively) named parameters (for instance, Content-Type, defined in <a href="#header.content-type" id="rfc.xref.header.content-type.1" title="Content-Type"> Appendix D.4.8</a>). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing1220 <p id="rfc.section.3.1.p.8">Many header fields use a format including (case-insensitively) named parameters (for instance, Content-Type, defined in <a href="#header.content-type" id="rfc.xref.header.content-type.1" title="Content-Type">Section 7.9</a>). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing 1224 1221 parser components. When allowing both forms, the meaning of a parameter value ought to be independent of the syntax used for 1225 1222 it (for an example, see the notes on parameter handling for media types in <a href="#media.types" title="Media Types">Section 6.5</a>). … … 1278 1275 <tr> 1279 1276 <td class="left">Accept</td> 1280 <td class="left"><a href="#header.accept" id="rfc.xref.header.accept.1" title="Accept"> Appendix D.4.1</a></td>1277 <td class="left"><a href="#header.accept" id="rfc.xref.header.accept.1" title="Accept">Section 7.1</a></td> 1281 1278 </tr> 1282 1279 <tr> 1283 1280 <td class="left">Accept-Charset</td> 1284 <td class="left"><a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset"> Appendix D.4.2</a></td>1281 <td class="left"><a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section 7.2</a></td> 1285 1282 </tr> 1286 1283 <tr> 1287 1284 <td class="left">Accept-Encoding</td> 1288 <td class="left"><a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.1" title="Accept-Encoding"> Appendix D.4.3</a></td>1285 <td class="left"><a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.1" title="Accept-Encoding">Section 7.3</a></td> 1289 1286 </tr> 1290 1287 <tr> 1291 1288 <td class="left">Accept-Language</td> 1292 <td class="left"><a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language"> Appendix D.4.4</a></td>1289 <td class="left"><a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section 7.4</a></td> 1293 1290 </tr> 1294 1291 <tr> … … 1298 1295 <tr> 1299 1296 <td class="left">Expect</td> 1300 <td class="left"><a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section 7. 3</a></td>1297 <td class="left"><a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section 7.11</a></td> 1301 1298 </tr> 1302 1299 <tr> 1303 1300 <td class="left">From</td> 1304 <td class="left"><a href="#header.from" id="rfc.xref.header.from.1" title="From">Section 7. 4</a></td>1301 <td class="left"><a href="#header.from" id="rfc.xref.header.from.1" title="From">Section 7.12</a></td> 1305 1302 </tr> 1306 1303 <tr> … … 1330 1327 <tr> 1331 1328 <td class="left">Max-Forwards</td> 1332 <td class="left"><a href="#header.max-forwards" id="rfc.xref.header.max-forwards.3" title="Max-Forwards">Section 7. 6</a></td>1329 <td class="left"><a href="#header.max-forwards" id="rfc.xref.header.max-forwards.3" title="Max-Forwards">Section 7.14</a></td> 1333 1330 </tr> 1334 1331 <tr> … … 1342 1339 <tr> 1343 1340 <td class="left">Referer</td> 1344 <td class="left"><a href="#header.referer" id="rfc.xref.header.referer.1" title="Referer">Section 7. 7</a></td>1341 <td class="left"><a href="#header.referer" id="rfc.xref.header.referer.1" title="Referer">Section 7.15</a></td> 1345 1342 </tr> 1346 1343 <tr> … … 1350 1347 <tr> 1351 1348 <td class="left">User-Agent</td> 1352 <td class="left"><a href="#header.user-agent" id="rfc.xref.header.user-agent.1" title="User-Agent">Section 7.1 0</a></td>1349 <td class="left"><a href="#header.user-agent" id="rfc.xref.header.user-agent.1" title="User-Agent">Section 7.18</a></td> 1353 1350 </tr> 1354 1351 </tbody> … … 1378 1375 <tr> 1379 1376 <td class="left">Allow</td> 1380 <td class="left"><a href="#header.allow" id="rfc.xref.header.allow.2" title="Allow">Section 7. 1</a></td>1377 <td class="left"><a href="#header.allow" id="rfc.xref.header.allow.2" title="Allow">Section 7.5</a></td> 1381 1378 </tr> 1382 1379 <tr> 1383 1380 <td class="left">Date</td> 1384 <td class="left"><a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section 7. 2</a></td>1381 <td class="left"><a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section 7.10</a></td> 1385 1382 </tr> 1386 1383 <tr> … … 1390 1387 <tr> 1391 1388 <td class="left">Location</td> 1392 <td class="left"><a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section 7. 5</a></td>1389 <td class="left"><a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section 7.13</a></td> 1393 1390 </tr> 1394 1391 <tr> … … 1398 1395 <tr> 1399 1396 <td class="left">Retry-After</td> 1400 <td class="left"><a href="#header.retry-after" id="rfc.xref.header.retry-after.1" title="Retry-After">Section 7. 8</a></td>1397 <td class="left"><a href="#header.retry-after" id="rfc.xref.header.retry-after.1" title="Retry-After">Section 7.16</a></td> 1401 1398 </tr> 1402 1399 <tr> 1403 1400 <td class="left">Server</td> 1404 <td class="left"><a href="#header.server" id="rfc.xref.header.server.1" title="Server">Section 7. 9</a></td>1401 <td class="left"><a href="#header.server" id="rfc.xref.header.server.1" title="Server">Section 7.17</a></td> 1405 1402 </tr> 1406 1403 <tr> … … 1434 1431 </ul> 1435 1432 <p id="rfc.section.4.p.4">For most status codes the response can carry a payload, in which case a Content-Type header field indicates the payload's 1436 media type (<a href="#header.content-type" id="rfc.xref.header.content-type.2" title="Content-Type"> Appendix D.4.8</a>).1433 media type (<a href="#header.content-type" id="rfc.xref.header.content-type.2" title="Content-Type">Section 7.9</a>). 1437 1434 </p> 1438 1435 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="overview.of.status.codes" href="#overview.of.status.codes">Overview of Status Codes</a></h2> … … 1830 1827 </p> 1831 1828 </div> 1832 <p id="rfc.section.4.5.p.4">A Location header field on a 3xx response indicates that a client <em class="bcp14">MAY</em> automatically redirect to the URI provided; see <a href="#header.location" id="rfc.xref.header.location.3" title="Location">Section 7. 5</a>.1829 <p id="rfc.section.4.5.p.4">A Location header field on a 3xx response indicates that a client <em class="bcp14">MAY</em> automatically redirect to the URI provided; see <a href="#header.location" id="rfc.xref.header.location.3" title="Location">Section 7.13</a>. 1833 1830 </p> 1834 1831 <p id="rfc.section.4.5.p.5">Note that for methods not known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section 2.1.1</a>, automatic redirection needs to done with care, since the redirect might change the conditions under which the request was … … 2046 2043 <div id="rfc.iref.s.31"></div> 2047 2044 <h3 id="rfc.section.4.6.14"><a href="#rfc.section.4.6.14">4.6.14</a> <a id="status.417" href="#status.417">417 Expectation Failed</a></h3> 2048 <p id="rfc.section.4.6.14.p.1">The expectation given in an Expect header field (see <a href="#header.expect" id="rfc.xref.header.expect.2" title="Expect">Section 7. 3</a>) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could2045 <p id="rfc.section.4.6.14.p.1">The expectation given in an Expect header field (see <a href="#header.expect" id="rfc.xref.header.expect.2" title="Expect">Section 7.11</a>) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could 2049 2046 not be met by the next-hop server. 2050 2047 </p> … … 2091 2088 <p id="rfc.section.4.7.4.p.1">The server is currently unable to handle the request due to a temporary overloading or maintenance of the server.</p> 2092 2089 <p id="rfc.section.4.7.4.p.2">The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the 2093 delay <em class="bcp14">MAY</em> be indicated in a Retry-After header field (<a href="#header.retry-after" id="rfc.xref.header.retry-after.2" title="Retry-After">Section 7. 8</a>). If no Retry-After is given, the client <em class="bcp14">SHOULD</em> handle the response as it would for a 500 response.2090 delay <em class="bcp14">MAY</em> be indicated in a Retry-After header field (<a href="#header.retry-after" id="rfc.xref.header.retry-after.2" title="Retry-After">Section 7.16</a>). If no Retry-After is given, the client <em class="bcp14">SHOULD</em> handle the response as it would for a 500 response. 2094 2091 </p> 2095 2092 <div class="note" id="rfc.section.4.7.4.p.3"> … … 2271 2268 </p> 2272 2269 <div id="rfc.figure.u.18"></div><pre class="inline"><span id="rfc.iref.g.22"></span> <a href="#content.codings" class="smpl">content-coding</a> = <a href="#core.rules" class="smpl">token</a> 2273 </pre><p id="rfc.section.6.4.p.3">All content-coding values are case-insensitive. HTTP/1.1 uses content-coding values in the Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding"> Appendix D.4.3</a>) and Content-Encoding (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.1" title="Content-Encoding">Appendix D.4.5</a>) header fields. Although the value describes the content-coding, what is more important is that it indicates what decoding2270 </pre><p id="rfc.section.6.4.p.3">All content-coding values are case-insensitive. HTTP/1.1 uses content-coding values in the Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section 7.3</a>) and Content-Encoding (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.1" title="Content-Encoding">Section 7.6</a>) header fields. Although the value describes the content-coding, what is more important is that it indicates what decoding 2274 2271 mechanism will be required to remove the encoding. 2275 2272 </p> … … 2308 2305 </p> 2309 2306 <h2 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a> <a id="media.types" href="#media.types">Media Types</a></h2> 2310 <p id="rfc.section.6.5.p.1">HTTP uses Internet Media Types <a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> in the Content-Type (<a href="#header.content-type" id="rfc.xref.header.content-type.3" title="Content-Type"> Appendix D.4.8</a>) and Accept (<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Appendix D.4.1</a>) header fields in order to provide open and extensible data typing and type negotiation.2307 <p id="rfc.section.6.5.p.1">HTTP uses Internet Media Types <a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> in the Content-Type (<a href="#header.content-type" id="rfc.xref.header.content-type.3" title="Content-Type">Section 7.9</a>) and Accept (<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section 7.1</a>) header fields in order to provide open and extensible data typing and type negotiation. 2311 2308 </p> 2312 2309 <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span><span id="rfc.iref.g.26"></span> <a href="#media.types" class="smpl">media-type</a> = <a href="#media.types" class="smpl">type</a> "/" <a href="#media.types" class="smpl">subtype</a> *( <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> <a href="#rule.parameter" class="smpl">parameter</a> ) … … 2377 2374 </p> 2378 2375 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1> 2379 <p id="rfc.section.7.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to request and response semantics.</p> 2376 <p id="rfc.section.7.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to request and response semantics and to the 2377 payload of messages. 2378 </p> 2380 2379 <div id="rfc.iref.a.1"></div> 2381 2380 <div id="rfc.iref.h.2"></div> 2382 <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a> <a id="header.allow" href="#header.allow">Allow</a></h2> 2383 <p id="rfc.section.7.1.p.1">The "Allow" header field lists the set of methods advertised as supported by the target resource. The purpose of this field 2381 <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a> <a id="header.accept" href="#header.accept">Accept</a></h2> 2382 <p id="rfc.section.7.1.p.1">The "Accept" header field can be used by user agents to specify response media types that are acceptable. Accept header fields 2383 can be used to indicate that the request is specifically limited to a small set of desired types, as in the case of a request 2384 for an in-line image. 2385 </p> 2386 <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.31"></span><span id="rfc.iref.g.32"></span><span id="rfc.iref.g.33"></span><span id="rfc.iref.g.34"></span> <a href="#header.accept" class="smpl">Accept</a> = #( <a href="#header.accept" class="smpl">media-range</a> [ <a href="#header.accept" class="smpl">accept-params</a> ] ) 2387 2388 <a href="#header.accept" class="smpl">media-range</a> = ( "*/*" 2389 / ( <a href="#media.types" class="smpl">type</a> "/" "*" ) 2390 / ( <a href="#media.types" class="smpl">type</a> "/" <a href="#media.types" class="smpl">subtype</a> ) 2391 ) *( <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> <a href="#rule.parameter" class="smpl">parameter</a> ) 2392 <a href="#header.accept" class="smpl">accept-params</a> = <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> "q=" <a href="#abnf.dependencies" class="smpl">qvalue</a> *( <a href="#header.accept" class="smpl">accept-ext</a> ) 2393 <a href="#header.accept" class="smpl">accept-ext</a> = <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> <a href="#core.rules" class="smpl">token</a> [ "=" <a href="#core.rules" class="smpl">word</a> ] 2394 </pre><p id="rfc.section.7.1.p.3">The asterisk "*" character is used to group media types into ranges, with "*/*" indicating all media types and "type/*" indicating 2395 all subtypes of that type. The media-range <em class="bcp14">MAY</em> include media type parameters that are applicable to that range. 2396 </p> 2397 <p id="rfc.section.7.1.p.4">Each media-range <em class="bcp14">MAY</em> be followed by one or more accept-params, beginning with the "q" parameter for indicating a relative quality factor. The first 2398 "q" parameter (if any) separates the media-range parameter(s) from the accept-params. Quality factors allow the user or user 2399 agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (<a href="p1-messaging.html#quality.values" title="Quality Values">Section 4.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.44"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The default value is q=1. 2400 </p> 2401 <div class="note" id="rfc.section.7.1.p.5"> 2402 <p> <b>Note:</b> Use of the "q" parameter name to separate media type parameters from Accept extension parameters is due to historical practice. 2403 Although this prevents any media type parameter named "q" from being used with a media range, such an event is believed to 2404 be unlikely given the lack of any "q" parameters in the IANA media type registry and the rare usage of any media type parameters 2405 in Accept. Future media types are discouraged from registering any parameter named "q". 2406 </p> 2407 </div> 2408 <p id="rfc.section.7.1.p.6">The example</p> 2409 <div id="rfc.figure.u.24"></div><pre class="text"> Accept: audio/*; q=0.2, audio/basic 2410 </pre><p id="rfc.section.7.1.p.8"> <em class="bcp14">SHOULD</em> be interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% mark-down in 2411 quality". 2412 </p> 2413 <p id="rfc.section.7.1.p.9">A request without any Accept header field implies that the user agent will accept any media type in response. If an Accept 2414 header field is present in a request and none of the available representations for the response have a media type that is 2415 listed as acceptable, the origin server <em class="bcp14">MAY</em> either honor the Accept header field by sending a 406 (Not Acceptable) response or disregard the Accept header field by treating 2416 the response as if it is not subject to content negotiation. 2417 </p> 2418 <p id="rfc.section.7.1.p.10">A more elaborate example is</p> 2419 <div id="rfc.figure.u.25"></div><pre class="text"> Accept: text/plain; q=0.5, text/html, 2420 text/x-dvi; q=0.8, text/x-c 2421 </pre><p id="rfc.section.7.1.p.12">Verbally, this would be interpreted as "text/html and text/x-c are the preferred media types, but if they do not exist, then 2422 send the text/x-dvi representation, and if that does not exist, send the text/plain representation". 2423 </p> 2424 <p id="rfc.section.7.1.p.13">Media ranges can be overridden by more specific media ranges or specific media types. If more than one media range applies 2425 to a given type, the most specific reference has precedence. For example, 2426 </p> 2427 <div id="rfc.figure.u.26"></div><pre class="text"> Accept: text/*, text/plain, text/plain;format=flowed, */* 2428 </pre><p id="rfc.section.7.1.p.15">have the following precedence: </p> 2429 <ol> 2430 <li>text/plain;format=flowed</li> 2431 <li>text/plain</li> 2432 <li>text/*</li> 2433 <li>*/*</li> 2434 </ol> 2435 <p id="rfc.section.7.1.p.16">The media type quality factor associated with a given type is determined by finding the media range with the highest precedence 2436 which matches that type. For example, 2437 </p> 2438 <div id="rfc.figure.u.27"></div><pre class="text"> Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, 2439 text/html;level=2;q=0.4, */*;q=0.5 2440 </pre><p id="rfc.section.7.1.p.18">would cause the following values to be associated:</p> 2441 <div id="rfc.table.u.4"> 2442 <table class="tt full left" cellpadding="3" cellspacing="0"> 2443 <thead> 2444 <tr> 2445 <th>Media Type</th> 2446 <th>Quality Value</th> 2447 </tr> 2448 </thead> 2449 <tbody> 2450 <tr> 2451 <td class="left">text/html;level=1</td> 2452 <td class="left">1</td> 2453 </tr> 2454 <tr> 2455 <td class="left">text/html</td> 2456 <td class="left">0.7</td> 2457 </tr> 2458 <tr> 2459 <td class="left">text/plain</td> 2460 <td class="left">0.3</td> 2461 </tr> 2462 <tr> 2463 <td class="left">image/jpeg</td> 2464 <td class="left">0.5</td> 2465 </tr> 2466 <tr> 2467 <td class="left">text/html;level=2</td> 2468 <td class="left">0.4</td> 2469 </tr> 2470 <tr> 2471 <td class="left">text/html;level=3</td> 2472 <td class="left">0.7</td> 2473 </tr> 2474 </tbody> 2475 </table> 2476 </div> 2477 <p id="rfc.section.7.1.p.19"> <b>Note:</b> A user agent might be provided with a default set of quality values for certain media ranges. However, unless the user agent 2478 is a closed system which cannot interact with other rendering agents, this default set ought to be configurable by the user. 2479 </p> 2480 <div id="rfc.iref.a.2"></div> 2481 <div id="rfc.iref.h.3"></div> 2482 <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a> <a id="header.accept-charset" href="#header.accept-charset">Accept-Charset</a></h2> 2483 <p id="rfc.section.7.2.p.1">The "Accept-Charset" header field can be used by user agents to indicate what character encodings are acceptable in a response 2484 payload. This field allows clients capable of understanding more comprehensive or special-purpose character encodings to signal 2485 that capability to a server which is capable of representing documents in those character encodings. 2486 </p> 2487 <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.35"></span> <a href="#header.accept-charset" class="smpl">Accept-Charset</a> = 1#( ( <a href="#rule.charset" class="smpl">charset</a> / "*" ) 2488 [ <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> "q=" <a href="#abnf.dependencies" class="smpl">qvalue</a> ] ) 2489 </pre><p id="rfc.section.7.2.p.3">Character encoding values (a.k.a., charsets) are described in <a href="#character.sets" title="Character Encodings (charset)">Section 6.3</a>. Each charset <em class="bcp14">MAY</em> be given an associated quality value which represents the user's preference for that charset. The default value is q=1. An 2490 example is 2491 </p> 2492 <div id="rfc.figure.u.29"></div><pre class="text"> Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 2493 </pre><p id="rfc.section.7.2.p.5">The special value "*", if present in the Accept-Charset field, matches every character encoding which is not mentioned elsewhere 2494 in the Accept-Charset field. If no "*" is present in an Accept-Charset field, then all character encodings not explicitly 2495 mentioned get a quality value of 0. 2496 </p> 2497 <p id="rfc.section.7.2.p.6">A request without any Accept-Charset header field implies that the user agent will accept any character encoding in response. 2498 If an Accept-Charset header field is present in a request and none of the available representations for the response have 2499 a character encoding that is listed as acceptable, the origin server <em class="bcp14">MAY</em> either honor the Accept-Charset header field by sending a 406 (Not Acceptable) response or disregard the Accept-Charset header 2500 field by treating the response as if it is not subject to content negotiation. 2501 </p> 2502 <div id="rfc.iref.a.3"></div> 2503 <div id="rfc.iref.h.4"></div> 2504 <h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a> <a id="header.accept-encoding" href="#header.accept-encoding">Accept-Encoding</a></h2> 2505 <p id="rfc.section.7.3.p.1">The "Accept-Encoding" header field can be used by user agents to indicate what response content-codings (<a href="#content.codings" title="Content Codings">Section 6.4</a>) are acceptable in the response. An "identity" token is used as a synonym for "no encoding" in order to communicate when 2506 no encoding is preferred. 2507 </p> 2508 <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.36"></span><span id="rfc.iref.g.37"></span> <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> = #( <a href="#header.accept-encoding" class="smpl">codings</a> [ <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> "q=" <a href="#abnf.dependencies" class="smpl">qvalue</a> ] ) 2509 <a href="#header.accept-encoding" class="smpl">codings</a> = <a href="#content.codings" class="smpl">content-coding</a> / "identity" / "*" 2510 </pre><p id="rfc.section.7.3.p.3">Each codings value <em class="bcp14">MAY</em> be given an associated quality value which represents the preference for that encoding. The default value is q=1. 2511 </p> 2512 <p id="rfc.section.7.3.p.4">For example,</p> 2513 <div id="rfc.figure.u.31"></div><pre class="text"> Accept-Encoding: compress, gzip 2514 Accept-Encoding: 2515 Accept-Encoding: * 2516 Accept-Encoding: compress;q=0.5, gzip;q=1.0 2517 Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 2518 </pre><p id="rfc.section.7.3.p.6">A server tests whether a content-coding for a given representation is acceptable, according to an Accept-Encoding field, using 2519 these rules: 2520 </p> 2521 <ol> 2522 <li>The special "*" symbol in an Accept-Encoding field matches any available content-coding not explicitly listed in the header 2523 field. 2524 </li> 2525 <li>If the representation has no content-coding, then it is acceptable by default unless specifically excluded by the Accept-Encoding 2526 field stating either "identity;q=0" or "*;q=0" without a more specific entry for "identity". 2527 </li> 2528 <li>If the representation's content-coding is one of the content-codings listed in the Accept-Encoding field, then it is acceptable 2529 unless it is accompanied by a qvalue of 0. (As defined in <a href="p1-messaging.html#quality.values" title="Quality Values">Section 4.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.45"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, a qvalue of 0 means "not acceptable".) 2530 </li> 2531 <li>If multiple content-codings are acceptable, then the acceptable content-coding with the highest non-zero qvalue is preferred.</li> 2532 </ol> 2533 <p id="rfc.section.7.3.p.7">An Accept-Encoding header field with a combined field-value that is empty implies that the user agent does not want any content-coding 2534 in response. If an Accept-Encoding header field is present in a request and none of the available representations for the 2535 response have a content-coding that is listed as acceptable, the origin server <em class="bcp14">SHOULD</em> send a response without any content-coding. 2536 </p> 2537 <p id="rfc.section.7.3.p.8">A request without an Accept-Encoding header field implies that the user agent will accept any content-coding in response, 2538 but a representation without content-coding is preferred for compatibility with the widest variety of user agents. 2539 </p> 2540 <div class="note" id="rfc.section.7.3.p.9"> 2541 <p> <b>Note:</b> Most HTTP/1.0 applications do not recognize or obey qvalues associated with content-codings. This means that qvalues will 2542 not work and are not permitted with x-gzip or x-compress. 2543 </p> 2544 </div> 2545 <div id="rfc.iref.a.4"></div> 2546 <div id="rfc.iref.h.5"></div> 2547 <h2 id="rfc.section.7.4"><a href="#rfc.section.7.4">7.4</a> <a id="header.accept-language" href="#header.accept-language">Accept-Language</a></h2> 2548 <p id="rfc.section.7.4.p.1">The "Accept-Language" header field can be used by user agents to indicate the set of natural languages that are preferred 2549 in the response. Language tags are defined in <a href="#language.tags" title="Language Tags">Section 6.6</a>. 2550 </p> 2551 <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span> <a href="#header.accept-language" class="smpl">Accept-Language</a> = 2552 1#( <a href="#header.accept-language" class="smpl">language-range</a> [ <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> "q=" <a href="#abnf.dependencies" class="smpl">qvalue</a> ] ) 2553 <a href="#header.accept-language" class="smpl">language-range</a> = 2554 <language-range, defined in <a href="#RFC4647" id="rfc.xref.RFC4647.1"><cite title="Matching of Language Tags">[RFC4647]</cite></a>, <a href="http://tools.ietf.org/html/rfc4647#section-2.1">Section 2.1</a>> 2555 </pre><p id="rfc.section.7.4.p.3">Each language-range can be given an associated quality value which represents an estimate of the user's preference for the 2556 languages specified by that range. The quality value defaults to "q=1". For example, 2557 </p> 2558 <div id="rfc.figure.u.33"></div><pre class="text"> Accept-Language: da, en-gb;q=0.8, en;q=0.7 2559 </pre><p id="rfc.section.7.4.p.5">would mean: "I prefer Danish, but will accept British English and other types of English". (see also <a href="http://tools.ietf.org/html/rfc4647#section-2.3">Section 2.3</a> of <a href="#RFC4647" id="rfc.xref.RFC4647.2"><cite title="Matching of Language Tags">[RFC4647]</cite></a>) 2560 </p> 2561 <p id="rfc.section.7.4.p.6">For matching, <a href="http://tools.ietf.org/html/rfc4647#section-3">Section 3</a> of <a href="#RFC4647" id="rfc.xref.RFC4647.3"><cite title="Matching of Language Tags">[RFC4647]</cite></a> defines several matching schemes. Implementations can offer the most appropriate matching scheme for their requirements. 2562 </p> 2563 <div class="note" id="rfc.section.7.4.p.7"> 2564 <p> <b>Note:</b> The "Basic Filtering" scheme (<a href="#RFC4647" id="rfc.xref.RFC4647.4"><cite title="Matching of Language Tags">[RFC4647]</cite></a>, <a href="http://tools.ietf.org/html/rfc4647#section-3.3.1">Section 3.3.1</a>) is identical to the matching scheme that was previously defined in <a href="http://tools.ietf.org/html/rfc2616#section-14.4">Section 14.4</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. 2565 </p> 2566 </div> 2567 <p id="rfc.section.7.4.p.8">It might be contrary to the privacy expectations of the user to send an Accept-Language header field with the complete linguistic 2568 preferences of the user in every request. For a discussion of this issue, see <a href="#privacy.issues.connected.to.accept.header.fields" title="Privacy Issues Connected to Accept Header Fields">Appendix D.5.1</a>. 2569 </p> 2570 <p id="rfc.section.7.4.p.9">As intelligibility is highly dependent on the individual user, it is recommended that client applications make the choice 2571 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. 2572 </p> 2573 <div class="note" id="rfc.section.7.4.p.10"> 2574 <p> <b>Note:</b> When making the choice of linguistic preference available to the user, we remind implementors of the fact that users are not 2575 familiar with the details of language matching as described above, and ought to be provided appropriate guidance. As an example, 2576 users might assume that on selecting "en-gb", they will be served any kind of English document if British English is not available. 2577 A user agent might suggest in such a case to add "en" to get the best matching behavior. 2578 </p> 2579 </div> 2580 <div id="rfc.iref.a.5"></div> 2581 <div id="rfc.iref.h.6"></div> 2582 <h2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a> <a id="header.allow" href="#header.allow">Allow</a></h2> 2583 <p id="rfc.section.7.5.p.1">The "Allow" header field lists the set of methods advertised as supported by the target resource. The purpose of this field 2384 2584 is strictly to inform the recipient of valid request methods associated with the resource. 2385 2585 </p> 2386 <div id="rfc.figure.u. 23"></div><pre class="inline"><span id="rfc.iref.g.31"></span> <a href="#header.allow" class="smpl">Allow</a> = #<a href="#methods" class="smpl">method</a>2387 </pre><p id="rfc.section.7. 1.p.3">Example of use:</p>2388 <div id="rfc.figure.u. 24"></div><pre class="text"> Allow: GET, HEAD, PUT2389 </pre><p id="rfc.section.7. 1.p.5">The actual set of allowed methods is defined by the origin server at the time of each request.</p>2390 <p id="rfc.section.7. 1.p.6">A proxy <em class="bcp14">MUST NOT</em> modify the Allow header field — it does not need to understand all the methods specified in order to handle them according2586 <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.40"></span> <a href="#header.allow" class="smpl">Allow</a> = #<a href="#methods" class="smpl">method</a> 2587 </pre><p id="rfc.section.7.5.p.3">Example of use:</p> 2588 <div id="rfc.figure.u.35"></div><pre class="text"> Allow: GET, HEAD, PUT 2589 </pre><p id="rfc.section.7.5.p.5">The actual set of allowed methods is defined by the origin server at the time of each request.</p> 2590 <p id="rfc.section.7.5.p.6">A proxy <em class="bcp14">MUST NOT</em> modify the Allow header field — it does not need to understand all the methods specified in order to handle them according 2391 2591 to the generic message handling rules. 2392 2592 </p> 2593 <div id="rfc.iref.c.7"></div> 2594 <div id="rfc.iref.h.7"></div> 2595 <h2 id="rfc.section.7.6"><a href="#rfc.section.7.6">7.6</a> <a id="header.content-encoding" href="#header.content-encoding">Content-Encoding</a></h2> 2596 <p id="rfc.section.7.6.p.1">The "Content-Encoding" header field indicates what content-codings have been applied to the representation beyond those inherent 2597 in the media type, and thus what decoding mechanisms have to be applied in order to obtain the media-type referenced by the 2598 Content-Type header field. Content-Encoding is primarily used to allow a representation to be compressed without losing the 2599 identity of its underlying media type. 2600 </p> 2601 <div id="rfc.figure.u.36"></div><pre class="inline"><span id="rfc.iref.g.41"></span> <a href="#header.content-encoding" class="smpl">Content-Encoding</a> = 1#<a href="#content.codings" class="smpl">content-coding</a> 2602 </pre><p id="rfc.section.7.6.p.3">Content codings are defined in <a href="#content.codings" title="Content Codings">Section 6.4</a>. An example of its use is 2603 </p> 2604 <div id="rfc.figure.u.37"></div><pre class="text"> Content-Encoding: gzip 2605 </pre><p id="rfc.section.7.6.p.5">The content-coding is a characteristic of the representation. Typically, the representation body is stored with this encoding 2606 and is only decoded before rendering or analogous usage. However, a transforming 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 2607 directive is present in the message. 2608 </p> 2609 <p id="rfc.section.7.6.p.6">If the media type includes an inherent encoding, such as a data format that is always compressed, then that encoding would 2610 not be restated as a Content-Encoding even if it happens to be the same algorithm as one of the content-codings. Such a content-coding 2611 would only be listed if, for some bizarre reason, it is applied a second time to form the representation. Likewise, an origin 2612 server might choose to publish the same payload data as multiple representations that differ only in whether the coding is 2613 defined as part of Content-Type or Content-Encoding, since some user agents will behave differently in their handling of each 2614 response (e.g., open a "Save as ..." dialog instead of automatic decompression and rendering of content). 2615 </p> 2616 <p id="rfc.section.7.6.p.7">A representation that has a content-coding applied to it <em class="bcp14">MUST</em> include a Content-Encoding header field (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.2" title="Content-Encoding">Section 7.6</a>) that lists the content-coding(s) applied. 2617 </p> 2618 <p id="rfc.section.7.6.p.8">If multiple encodings have been applied to a representation, 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 header fields not defined by this specification. 2619 </p> 2620 <p id="rfc.section.7.6.p.9">If the content-coding of a representation 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). 2621 </p> 2622 <div id="rfc.iref.c.8"></div> 2623 <div id="rfc.iref.h.8"></div> 2624 <h2 id="rfc.section.7.7"><a href="#rfc.section.7.7">7.7</a> <a id="header.content-language" href="#header.content-language">Content-Language</a></h2> 2625 <p id="rfc.section.7.7.p.1">The "Content-Language" header field describes the natural language(s) of the intended audience for the representation. Note 2626 that this might not be equivalent to all the languages used within the representation. 2627 </p> 2628 <div id="rfc.figure.u.38"></div><pre class="inline"><span id="rfc.iref.g.42"></span> <a href="#header.content-language" class="smpl">Content-Language</a> = 1#<a href="#language.tags" class="smpl">language-tag</a> 2629 </pre><p id="rfc.section.7.7.p.3">Language tags are defined in <a href="#language.tags" title="Language Tags">Section 6.6</a>. The primary purpose of Content-Language is to allow a user to identify and differentiate representations according to the 2630 user's own preferred language. Thus, if the body content is intended only for a Danish-literate audience, the appropriate 2631 field is 2632 </p> 2633 <div id="rfc.figure.u.39"></div><pre class="text"> Content-Language: da 2634 </pre><p id="rfc.section.7.7.p.5">If no Content-Language is specified, the default is that the content is intended for all language audiences. This might mean 2635 that the sender does not consider it to be specific to any natural language, or that the sender does not know for which language 2636 it is intended. 2637 </p> 2638 <p id="rfc.section.7.7.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 2639 simultaneously in the original Maori and English versions, would call for 2640 </p> 2641 <div id="rfc.figure.u.40"></div><pre class="text"> Content-Language: mi, en 2642 </pre><p id="rfc.section.7.7.p.8">However, just because multiple languages are present within a representation does not mean that it is intended for multiple 2643 linguistic audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin", which is clearly 2644 intended to be used by an English-literate audience. In this case, the Content-Language would properly only include "en". 2645 </p> 2646 <p id="rfc.section.7.7.p.9">Content-Language <em class="bcp14">MAY</em> be applied to any media type — it is not limited to textual documents. 2647 </p> 2648 <div id="rfc.iref.c.9"></div> 2649 <div id="rfc.iref.h.9"></div> 2650 <h2 id="rfc.section.7.8"><a href="#rfc.section.7.8">7.8</a> <a id="header.content-location" href="#header.content-location">Content-Location</a></h2> 2651 <p id="rfc.section.7.8.p.1">The "Content-Location" header field supplies a URI that can be used as a specific identifier for the representation in this 2652 message. In other words, if one were to perform a GET on this URI at the time of this message's generation, then a 200 response 2653 would contain the same representation that is enclosed as payload in this message. 2654 </p> 2655 <div id="rfc.figure.u.41"></div><pre class="inline"><span id="rfc.iref.g.43"></span> <a href="#header.content-location" class="smpl">Content-Location</a> = <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a> 2656 </pre><p id="rfc.section.7.8.p.3">The Content-Location value is not a replacement for the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.46"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME 2657 body parts in <a href="http://tools.ietf.org/html/rfc2557#section-4">Section 4</a> of <a href="#RFC2557" id="rfc.xref.RFC2557.1"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a>. However, its appearance in an HTTP message has some special implications for HTTP recipients. 2658 </p> 2659 <p id="rfc.section.7.8.p.4">If Content-Location is included in a response message and its value is the same as the effective request URI, then the response 2660 payload <em class="bcp14">SHOULD</em> be considered a current representation of that resource. For a GET or HEAD request, this is the same as the default semantics 2661 when no Content-Location is provided by the server. For a state-changing request like PUT or POST, it implies that the server's 2662 response contains the new representation of that resource, thereby distinguishing it from representations that might only 2663 report about the action (e.g., "It worked!"). This allows authoring applications to update their local copies without the 2664 need for a subsequent GET request. 2665 </p> 2666 <p id="rfc.section.7.8.p.5">If Content-Location is included in a response message and its value differs from the effective request URI, then the origin 2667 server is informing recipients that this representation has its own, presumably more specific, identifier. For a GET or HEAD 2668 request, this is an indication that the effective request URI identifies a resource that is subject to content negotiation 2669 and the selected representation for this response can also be found at the identified URI. For other methods, such a Content-Location 2670 indicates that this representation contains a report on the action's status and the same report is available (for future access 2671 with GET) at the given URI. For example, a purchase transaction made via a POST request might include a receipt document as 2672 the payload of the 200 response; the Content-Location value provides an identifier for retrieving a copy of that same receipt 2673 in the future. 2674 </p> 2675 <p id="rfc.section.7.8.p.6">If Content-Location is included in a request message, then it <em class="bcp14">MAY</em> be interpreted by the origin server as an indication of where the user agent originally obtained the content of the enclosed 2676 representation (prior to any subsequent modification of the content by that user agent). In other words, the user agent is 2677 providing the same representation metadata that it received with the original representation. However, such interpretation <em class="bcp14">MUST NOT</em> be used to alter the semantics of the method requested by the client. For example, if a client makes a PUT request on a negotiated 2678 resource and the origin server accepts that PUT (without redirection), then the new set of values for that resource is expected 2679 to be consistent with the one representation supplied in that PUT; the Content-Location cannot be used as a form of reverse 2680 content selection that identifies only one of the negotiated representations to be updated. If the user agent had wanted the 2681 latter semantics, it would have applied the PUT directly to the Content-Location URI. 2682 </p> 2683 <p id="rfc.section.7.8.p.7">A Content-Location field received in a request message is transitory information that <em class="bcp14">SHOULD NOT</em> be saved with other representation metadata for use in later responses. The Content-Location's value might be saved for use 2684 in other contexts, such as within source links or other metadata. 2685 </p> 2686 <p id="rfc.section.7.8.p.8">A cache cannot assume that a representation with a Content-Location different from the URI used to retrieve it can be used 2687 to respond to later requests on that Content-Location URI. 2688 </p> 2689 <p id="rfc.section.7.8.p.9">If the Content-Location value is a partial URI, the partial URI is interpreted relative to the effective request URI.</p> 2690 <div id="rfc.iref.c.10"></div> 2691 <div id="rfc.iref.h.10"></div> 2692 <h2 id="rfc.section.7.9"><a href="#rfc.section.7.9">7.9</a> <a id="header.content-type" href="#header.content-type">Content-Type</a></h2> 2693 <p id="rfc.section.7.9.p.1">The "Content-Type" header field indicates the media type of the representation. In the case of responses to the HEAD method, 2694 the media type is that which would have been sent had the request been a GET. 2695 </p> 2696 <div id="rfc.figure.u.42"></div><pre class="inline"><span id="rfc.iref.g.44"></span> <a href="#header.content-type" class="smpl">Content-Type</a> = <a href="#media.types" class="smpl">media-type</a> 2697 </pre><p id="rfc.section.7.9.p.3">Media types are defined in <a href="#media.types" title="Media Types">Section 6.5</a>. An example of the field is 2698 </p> 2699 <div id="rfc.figure.u.43"></div><pre class="text"> Content-Type: text/html; charset=ISO-8859-4 2700 </pre><p id="rfc.section.7.9.p.5">Further discussion of Content-Type is provided in <a href="#representation.data" title="Representation Data">Appendix D.2.2</a>. 2701 </p> 2393 2702 <div id="rfc.iref.d.3"></div> 2394 <div id="rfc.iref.h. 3"></div>2395 <h2 id="rfc.section.7. 2"><a href="#rfc.section.7.2">7.2</a> <a id="header.date" href="#header.date">Date</a></h2>2396 <p id="rfc.section.7. 2.p.1">The "Date" header field represents the date and time at which the message was originated, having the same semantics as the2703 <div id="rfc.iref.h.11"></div> 2704 <h2 id="rfc.section.7.10"><a href="#rfc.section.7.10">7.10</a> <a id="header.date" href="#header.date">Date</a></h2> 2705 <p id="rfc.section.7.10.p.1">The "Date" header field represents the date and time at which the message was originated, having the same semantics as the 2397 2706 Origination Date Field (orig-date) defined in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.1">Section 3.6.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.2"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as defined in <a href="#http.date" title="Date/Time Formats">Section 6.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format. 2398 2707 </p> 2399 <div id="rfc.figure.u. 25"></div><pre class="inline"><span id="rfc.iref.g.32"></span> <a href="#header.date" class="smpl">Date</a> = <a href="#http.date" class="smpl">HTTP-date</a>2400 </pre><p id="rfc.section.7. 2.p.3">An example is</p>2401 <div id="rfc.figure.u. 26"></div><pre class="text"> Date: Tue, 15 Nov 1994 08:12:31 GMT2402 </pre><p id="rfc.section.7. 2.p.5">Origin servers <em class="bcp14">MUST</em> include a Date header field in all responses, except in these cases:2708 <div id="rfc.figure.u.44"></div><pre class="inline"><span id="rfc.iref.g.45"></span> <a href="#header.date" class="smpl">Date</a> = <a href="#http.date" class="smpl">HTTP-date</a> 2709 </pre><p id="rfc.section.7.10.p.3">An example is</p> 2710 <div id="rfc.figure.u.45"></div><pre class="text"> Date: Tue, 15 Nov 1994 08:12:31 GMT 2711 </pre><p id="rfc.section.7.10.p.5">Origin servers <em class="bcp14">MUST</em> include a Date header field in all responses, except in these cases: 2403 2712 </p> 2404 2713 <ol> … … 2411 2720 </li> 2412 2721 </ol> 2413 <p id="rfc.section.7. 2.p.6">A received message that does not have a Date header field <em class="bcp14">MUST</em> be assigned one by the recipient if the message will be cached by that recipient.2414 </p> 2415 <p id="rfc.section.7. 2.p.7">Clients can use the Date header field as well; in order to keep request messages small, they are advised not to include it2722 <p id="rfc.section.7.10.p.6">A received message that does not have a Date header field <em class="bcp14">MUST</em> be assigned one by the recipient if the message will be cached by that recipient. 2723 </p> 2724 <p id="rfc.section.7.10.p.7">Clients can use the Date header field as well; in order to keep request messages small, they are advised not to include it 2416 2725 when it doesn't convey any useful information (as is usually the case for requests that do not contain a payload). 2417 2726 </p> 2418 <p id="rfc.section.7. 2.p.8">The HTTP-date sent in a Date header field <em class="bcp14">SHOULD NOT</em> represent a date and time subsequent to the generation of the message. It <em class="bcp14">SHOULD</em> represent the best available approximation of the date and time of message generation, unless the implementation has no means2727 <p id="rfc.section.7.10.p.8">The HTTP-date sent in a Date header field <em class="bcp14">SHOULD NOT</em> represent a date and time subsequent to the generation of the message. It <em class="bcp14">SHOULD</em> represent the best available approximation of the date and time of message generation, unless the implementation has no means 2419 2728 of generating a reasonably accurate date and time. In theory, the date ought to represent the moment just before the payload 2420 2729 is generated. In practice, the date can be generated at any time during the message origination without affecting its semantic … … 2422 2731 </p> 2423 2732 <div id="rfc.iref.e.1"></div> 2424 <div id="rfc.iref.h. 4"></div>2425 <h2 id="rfc.section.7. 3"><a href="#rfc.section.7.3">7.3</a> <a id="header.expect" href="#header.expect">Expect</a></h2>2426 <p id="rfc.section.7. 3.p.1">The "Expect" header field is used to indicate that particular server behaviors are required by the client.</p>2427 <div id="rfc.figure.u. 27"></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> <a href="#header.expect" class="smpl">Expect</a> = 1#<a href="#header.expect" class="smpl">expectation</a>2733 <div id="rfc.iref.h.12"></div> 2734 <h2 id="rfc.section.7.11"><a href="#rfc.section.7.11">7.11</a> <a id="header.expect" href="#header.expect">Expect</a></h2> 2735 <p id="rfc.section.7.11.p.1">The "Expect" header field is used to indicate that particular server behaviors are required by the client.</p> 2736 <div id="rfc.figure.u.46"></div><pre class="inline"><span id="rfc.iref.g.46"></span><span id="rfc.iref.g.47"></span><span id="rfc.iref.g.48"></span><span id="rfc.iref.g.49"></span><span id="rfc.iref.g.50"></span> <a href="#header.expect" class="smpl">Expect</a> = 1#<a href="#header.expect" class="smpl">expectation</a> 2428 2737 2429 2738 <a href="#header.expect" class="smpl">expectation</a> = <a href="#header.expect" class="smpl">expect-name</a> [ <a href="#core.rules" class="smpl">BWS</a> "=" <a href="#core.rules" class="smpl">BWS</a> <a href="#header.expect" class="smpl">expect-value</a> ] … … 2433 2742 <a href="#header.expect" class="smpl">expect-name</a> = <a href="#core.rules" class="smpl">token</a> 2434 2743 <a href="#header.expect" class="smpl">expect-value</a> = <a href="#core.rules" class="smpl">token</a> / <a href="#core.rules" class="smpl">quoted-string</a> 2435 </pre><p id="rfc.section.7. 3.p.3">If all received Expect header field(s) are syntactically valid but contain an expectation that the recipient does not understand2744 </pre><p id="rfc.section.7.11.p.3">If all received Expect header field(s) are syntactically valid but contain an expectation that the recipient does not understand 2436 2745 or cannot comply with, the recipient <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed) status code. A recipient of a syntactically invalid Expectation header field <em class="bcp14">MUST</em> respond with a 4xx status code other than 417. 2437 2746 </p> 2438 <p id="rfc.section.7. 3.p.4">The only expectation defined by this specification is:</p>2439 <p id="rfc.section.7. 3.p.5"><span id="rfc.iref.103"></span><span id="rfc.iref.e.2"></span> 100-continue2747 <p id="rfc.section.7.11.p.4">The only expectation defined by this specification is:</p> 2748 <p id="rfc.section.7.11.p.5"><span id="rfc.iref.132"></span><span id="rfc.iref.e.2"></span> 100-continue 2440 2749 </p> 2441 2750 <ul class="empty"> 2442 <li>The "100-continue" expectation is defined <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.4.3</a> of <a href="#Part1" id="rfc.xref.Part1.4 4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. It does not support any expect-params.2443 </li> 2444 </ul> 2445 <p id="rfc.section.7. 3.p.6">Comparison is case-insensitive for names (expect-name), and case-sensitive for values (expect-value).</p>2446 <p id="rfc.section.7. 3.p.7">The Expect mechanism is hop-by-hop: the above requirements apply to any server, including proxies. However, the Expect header2751 <li>The "100-continue" expectation is defined <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.4.3</a> of <a href="#Part1" id="rfc.xref.Part1.47"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. It does not support any expect-params. 2752 </li> 2753 </ul> 2754 <p id="rfc.section.7.11.p.6">Comparison is case-insensitive for names (expect-name), and case-sensitive for values (expect-value).</p> 2755 <p id="rfc.section.7.11.p.7">The Expect mechanism is hop-by-hop: the above requirements apply to any server, including proxies. However, the Expect header 2447 2756 field itself is end-to-end; it <em class="bcp14">MUST</em> be forwarded if the request is forwarded. 2448 2757 </p> 2449 <p id="rfc.section.7. 3.p.8">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header field.</p>2758 <p id="rfc.section.7.11.p.8">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header field.</p> 2450 2759 <div id="rfc.iref.f.1"></div> 2451 <div id="rfc.iref.h. 5"></div>2452 <h2 id="rfc.section.7. 4"><a href="#rfc.section.7.4">7.4</a> <a id="header.from" href="#header.from">From</a></h2>2453 <p id="rfc.section.7. 4.p.1">The "From" 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="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>:2454 </p> 2455 <div id="rfc.figure.u. 28"></div><pre class="inline"><span id="rfc.iref.g.38"></span> <a href="#header.from" class="smpl">From</a> = <a href="#header.from" class="smpl">mailbox</a>2760 <div id="rfc.iref.h.13"></div> 2761 <h2 id="rfc.section.7.12"><a href="#rfc.section.7.12">7.12</a> <a id="header.from" href="#header.from">From</a></h2> 2762 <p id="rfc.section.7.12.p.1">The "From" 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="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>: 2763 </p> 2764 <div id="rfc.figure.u.47"></div><pre class="inline"><span id="rfc.iref.g.51"></span> <a href="#header.from" class="smpl">From</a> = <a href="#header.from" class="smpl">mailbox</a> 2456 2765 2457 2766 <a href="#header.from" class="smpl">mailbox</a> = <mailbox, defined in <a href="#RFC5322" id="rfc.xref.RFC5322.4"><cite title="Internet Message Format">[RFC5322]</cite></a>, <a href="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a>> 2458 </pre><p id="rfc.section.7. 4.p.3">An example is:</p>2459 <div id="rfc.figure.u. 29"></div><pre class="text"> From: webmaster@example.org2460 </pre><p id="rfc.section.7. 4.p.5">This header field <em class="bcp14">MAY</em> be used for logging purposes and as a means for identifying the source of invalid or unwanted requests. It <em class="bcp14">SHOULD NOT</em> be used as an insecure form of access protection. The interpretation of this field is that the request is being performed2767 </pre><p id="rfc.section.7.12.p.3">An example is:</p> 2768 <div id="rfc.figure.u.48"></div><pre class="text"> From: webmaster@example.org 2769 </pre><p id="rfc.section.7.12.p.5">This header field <em class="bcp14">MAY</em> be used for logging purposes and as a means for identifying the source of invalid or unwanted requests. It <em class="bcp14">SHOULD NOT</em> be used as an insecure form of access protection. The interpretation of this field is that the request is being performed 2461 2770 on behalf of the person given, who accepts responsibility for the method performed. In particular, robot agents <em class="bcp14">SHOULD</em> include this header field so that the person responsible for running the robot can be contacted if problems occur on the receiving 2462 2771 end. 2463 2772 </p> 2464 <p id="rfc.section.7. 4.p.6">The Internet e-mail address in this field <em class="bcp14">MAY</em> be separate from the Internet host which issued the request. For example, when a request is passed through a proxy the original2773 <p id="rfc.section.7.12.p.6">The Internet e-mail address in this field <em class="bcp14">MAY</em> be separate from the Internet host which issued the request. For example, when a request is passed through a proxy the original 2465 2774 issuer's address <em class="bcp14">SHOULD</em> be used. 2466 2775 </p> 2467 <p id="rfc.section.7. 4.p.7">The client <em class="bcp14">SHOULD NOT</em> send the From header field without the user's approval, as it might conflict with the user's privacy interests or their site's2776 <p id="rfc.section.7.12.p.7">The client <em class="bcp14">SHOULD NOT</em> send the From header field without the user's approval, as it might conflict with the user's privacy interests or their site's 2468 2777 security policy. It is strongly recommended that the user be able to disable, enable, and modify the value of this field at 2469 2778 any time prior to a request. 2470 2779 </p> 2471 2780 <div id="rfc.iref.l.1"></div> 2472 <div id="rfc.iref.h. 6"></div>2473 <h2 id="rfc.section.7. 5"><a href="#rfc.section.7.5">7.5</a> <a id="header.location" href="#header.location">Location</a></h2>2474 <p id="rfc.section.7. 5.p.1">The "Location" header field <em class="bcp14">MAY</em> be sent in responses to refer to a specific resource in accordance with the semantics of the status code.2475 </p> 2476 <div id="rfc.figure.u. 30"></div><pre class="inline"><span id="rfc.iref.g.39"></span> <a href="#header.location" class="smpl">Location</a> = <a href="#abnf.dependencies" class="smpl">URI-reference</a>2477 </pre><p id="rfc.section.7. 5.p.3">For 201 (Created) responses, the Location is the URI of the new resource which was created by the request. For 3xx responses,2781 <div id="rfc.iref.h.14"></div> 2782 <h2 id="rfc.section.7.13"><a href="#rfc.section.7.13">7.13</a> <a id="header.location" href="#header.location">Location</a></h2> 2783 <p id="rfc.section.7.13.p.1">The "Location" header field <em class="bcp14">MAY</em> be sent in responses to refer to a specific resource in accordance with the semantics of the status code. 2784 </p> 2785 <div id="rfc.figure.u.49"></div><pre class="inline"><span id="rfc.iref.g.52"></span> <a href="#header.location" class="smpl">Location</a> = <a href="#abnf.dependencies" class="smpl">URI-reference</a> 2786 </pre><p id="rfc.section.7.13.p.3">For 201 (Created) responses, the Location is the URI of the new resource which was created by the request. For 3xx responses, 2478 2787 the location <em class="bcp14">SHOULD</em> indicate the server's preferred URI for automatic redirection to the resource. 2479 2788 </p> 2480 <p id="rfc.section.7. 5.p.4">The field value consists of a single URI-reference. When it has the form of a relative reference (<a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.2">Section 4.2</a>), the final value is computed by resolving it against the effective request URI (<a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-5">Section 5</a>). If the original URI, as navigated to by the user agent, did contain a fragment identifier, and the final value does not,2789 <p id="rfc.section.7.13.p.4">The field value consists of a single URI-reference. When it has the form of a relative reference (<a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.2">Section 4.2</a>), the final value is computed by resolving it against the effective request URI (<a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-5">Section 5</a>). If the original URI, as navigated to by the user agent, did contain a fragment identifier, and the final value does not, 2481 2790 then the original URI's fragment identifier is added to the final value. 2482 2791 </p> 2483 <div id="rfc.figure.u. 31"></div>2792 <div id="rfc.figure.u.50"></div> 2484 2793 <p>For example, the original URI "http://www.example.org/~tim", combined with a field value given as:</p> <pre class="text"> Location: /pub/WWW/People.html#tim 2485 2794 </pre> <p>would result in a final value of "http://www.example.org/pub/WWW/People.html#tim"</p> 2486 <div id="rfc.figure.u. 32"></div>2795 <div id="rfc.figure.u.51"></div> 2487 2796 <p>An original URI "http://www.example.org/index.html#larry", combined with a field value given as:</p> <pre class="text"> Location: http://www.example.net/index.html 2488 2797 </pre> <p>would result in a final value of "http://www.example.net/index.html#larry", preserving the original fragment identifier.</p> 2489 <div class="note" id="rfc.section.7. 5.p.7">2798 <div class="note" id="rfc.section.7.13.p.7"> 2490 2799 <p> <b>Note:</b> Some recipients attempt to recover from Location fields that are not valid URI references. This specification does not mandate 2491 2800 or define such processing, but does allow it (see <a href="#intro.conformance.and.error.handling" title="Conformance and Error Handling">Section 1.2</a>). 2492 2801 </p> 2493 2802 </div> 2494 <p id="rfc.section.7. 5.p.8">There are circumstances in which a fragment identifier in a Location URI would not be appropriate. For instance, when it appears2803 <p id="rfc.section.7.13.p.8">There are circumstances in which a fragment identifier in a Location URI would not be appropriate. For instance, when it appears 2495 2804 in a 201 Created response, where the Location header field specifies the URI for the entire created resource. 2496 2805 </p> 2497 <div class="note" id="rfc.section.7. 5.p.9">2498 <p> <b>Note:</b> The Content-Location header field (<a href="#header.content-location" id="rfc.xref.header.content-location.2" title="Content-Location"> Appendix D.4.7</a>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation.2806 <div class="note" id="rfc.section.7.13.p.9"> 2807 <p> <b>Note:</b> The Content-Location header field (<a href="#header.content-location" id="rfc.xref.header.content-location.2" title="Content-Location">Section 7.8</a>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation. 2499 2808 It is therefore possible for a response to contain header fields for both Location and Content-Location. 2500 2809 </p> 2501 2810 </div> 2502 2811 <div id="rfc.iref.m.9"></div> 2503 <div id="rfc.iref.h. 7"></div>2504 <h2 id="rfc.section.7. 6"><a href="#rfc.section.7.6">7.6</a> <a id="header.max-forwards" href="#header.max-forwards">Max-Forwards</a></h2>2505 <p id="rfc.section.7. 6.p.1">The "Max-Forwards" header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.1" title="TRACE">Section 2.3.7</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">Section 2.3.1</a>) methods to limit the number of times that the request is forwarded by proxies. This can be useful when the client is attempting2812 <div id="rfc.iref.h.15"></div> 2813 <h2 id="rfc.section.7.14"><a href="#rfc.section.7.14">7.14</a> <a id="header.max-forwards" href="#header.max-forwards">Max-Forwards</a></h2> 2814 <p id="rfc.section.7.14.p.1">The "Max-Forwards" header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.1" title="TRACE">Section 2.3.7</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">Section 2.3.1</a>) methods to limit the number of times that the request is forwarded by proxies. This can be useful when the client is attempting 2506 2815 to trace a request which appears to be failing or looping mid-chain. 2507 2816 </p> 2508 <div id="rfc.figure.u. 33"></div><pre class="inline"><span id="rfc.iref.g.40"></span> <a href="#header.max-forwards" class="smpl">Max-Forwards</a> = 1*<a href="#notation" class="smpl">DIGIT</a>2509 </pre><p id="rfc.section.7. 6.p.3">The Max-Forwards value is a decimal integer indicating the remaining number of times this request message can be forwarded.</p>2510 <p id="rfc.section.7. 6.p.4">Each recipient of a TRACE or OPTIONS request containing a Max-Forwards header field <em class="bcp14">MUST</em> check and update its value prior to forwarding the request. If the received value is zero (0), the recipient <em class="bcp14">MUST NOT</em> forward the request; instead, it <em class="bcp14">MUST</em> respond as the final recipient. If the received Max-Forwards value is greater than zero, then the forwarded message <em class="bcp14">MUST</em> contain an updated Max-Forwards field with a value decremented by one (1).2511 </p> 2512 <p id="rfc.section.7. 6.p.5">The Max-Forwards header field <em class="bcp14">MAY</em> be ignored for all other request methods.2817 <div id="rfc.figure.u.52"></div><pre class="inline"><span id="rfc.iref.g.53"></span> <a href="#header.max-forwards" class="smpl">Max-Forwards</a> = 1*<a href="#notation" class="smpl">DIGIT</a> 2818 </pre><p id="rfc.section.7.14.p.3">The Max-Forwards value is a decimal integer indicating the remaining number of times this request message can be forwarded.</p> 2819 <p id="rfc.section.7.14.p.4">Each recipient of a TRACE or OPTIONS request containing a Max-Forwards header field <em class="bcp14">MUST</em> check and update its value prior to forwarding the request. If the received value is zero (0), the recipient <em class="bcp14">MUST NOT</em> forward the request; instead, it <em class="bcp14">MUST</em> respond as the final recipient. If the received Max-Forwards value is greater than zero, then the forwarded message <em class="bcp14">MUST</em> contain an updated Max-Forwards field with a value decremented by one (1). 2820 </p> 2821 <p id="rfc.section.7.14.p.5">The Max-Forwards header field <em class="bcp14">MAY</em> be ignored for all other request methods. 2513 2822 </p> 2514 2823 <div id="rfc.iref.r.1"></div> 2515 <div id="rfc.iref.h. 8"></div>2516 <h2 id="rfc.section.7. 7"><a href="#rfc.section.7.7">7.7</a> <a id="header.referer" href="#header.referer">Referer</a></h2>2517 <p id="rfc.section.7. 7.p.1">The "Referer" [sic] header field allows the client to specify the URI of the resource from which the target URI was obtained2824 <div id="rfc.iref.h.16"></div> 2825 <h2 id="rfc.section.7.15"><a href="#rfc.section.7.15">7.15</a> <a id="header.referer" href="#header.referer">Referer</a></h2> 2826 <p id="rfc.section.7.15.p.1">The "Referer" [sic] header field allows the client to specify the URI of the resource from which the target URI was obtained 2518 2827 (the "referrer", although the header field is misspelled.). 2519 2828 </p> 2520 <p id="rfc.section.7. 7.p.2">The Referer header field allows servers to generate lists of back-links to resources for interest, logging, optimized caching,2829 <p id="rfc.section.7.15.p.2">The Referer header field allows servers to generate lists of back-links to resources for interest, logging, optimized caching, 2521 2830 etc. It also allows obsolete or mistyped links to be traced for maintenance. Some servers use Referer as a means of controlling 2522 2831 where they allow links from (so-called "deep linking"), but legitimate requests do not always contain a Referer header field. 2523 2832 </p> 2524 <p id="rfc.section.7. 7.p.3">If the target URI was obtained from a source that does not have its own URI (e.g., input from the user keyboard), the Referer2833 <p id="rfc.section.7.15.p.3">If the target URI was obtained from a source that does not have its own URI (e.g., input from the user keyboard), the Referer 2525 2834 field <em class="bcp14">MUST</em> either be sent with the value "about:blank", or not be sent at all. Note that this requirement does not apply to sources with 2526 2835 non-HTTP URIs (e.g., FTP). 2527 2836 </p> 2528 <div id="rfc.figure.u. 34"></div><pre class="inline"><span id="rfc.iref.g.41"></span> <a href="#header.referer" class="smpl">Referer</a> = <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a>2529 </pre><p id="rfc.section.7. 7.p.5">Example:</p>2530 <div id="rfc.figure.u. 35"></div><pre class="text"> Referer: http://www.example.org/hypertext/Overview.html2531 </pre><p id="rfc.section.7. 7.p.7">If the field value is a relative URI, it <em class="bcp14">SHOULD</em> be interpreted relative to the effective request URI. The URI <em class="bcp14">MUST NOT</em> include a fragment. See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section 9.2</a> for security considerations.2837 <div id="rfc.figure.u.53"></div><pre class="inline"><span id="rfc.iref.g.54"></span> <a href="#header.referer" class="smpl">Referer</a> = <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a> 2838 </pre><p id="rfc.section.7.15.p.5">Example:</p> 2839 <div id="rfc.figure.u.54"></div><pre class="text"> Referer: http://www.example.org/hypertext/Overview.html 2840 </pre><p id="rfc.section.7.15.p.7">If the field value is a relative URI, it <em class="bcp14">SHOULD</em> be interpreted relative to the effective request URI. The URI <em class="bcp14">MUST NOT</em> include a fragment. See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section 9.2</a> for security considerations. 2532 2841 </p> 2533 2842 <div id="rfc.iref.r.2"></div> 2534 <div id="rfc.iref.h. 9"></div>2535 <h2 id="rfc.section.7. 8"><a href="#rfc.section.7.8">7.8</a> <a id="header.retry-after" href="#header.retry-after">Retry-After</a></h2>2536 <p id="rfc.section.7. 8.p.1">The header "Retry-After" field can be used with a 503 (Service Unavailable) response to indicate how long the service is expected2843 <div id="rfc.iref.h.17"></div> 2844 <h2 id="rfc.section.7.16"><a href="#rfc.section.7.16">7.16</a> <a id="header.retry-after" href="#header.retry-after">Retry-After</a></h2> 2845 <p id="rfc.section.7.16.p.1">The header "Retry-After" field can be used with a 503 (Service Unavailable) response to indicate how long the service is expected 2537 2846 to be unavailable to the requesting client. This field <em class="bcp14">MAY</em> also be used with any 3xx (Redirection) response to indicate the minimum time the user-agent is asked to wait before issuing 2538 2847 the redirected request. 2539 2848 </p> 2540 <p id="rfc.section.7. 8.p.2">The value of this field can be either an HTTP-date or an integer number of seconds (in decimal) after the time of the response.</p>2541 <div id="rfc.figure.u. 36"></div><pre class="inline"><span id="rfc.iref.g.42"></span> <a href="#header.retry-after" class="smpl">Retry-After</a> = <a href="#http.date" class="smpl">HTTP-date</a> / <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>2849 <p id="rfc.section.7.16.p.2">The value of this field can be either an HTTP-date or an integer number of seconds (in decimal) after the time of the response.</p> 2850 <div id="rfc.figure.u.55"></div><pre class="inline"><span id="rfc.iref.g.55"></span> <a href="#header.retry-after" class="smpl">Retry-After</a> = <a href="#http.date" class="smpl">HTTP-date</a> / <a href="#rule.delta-seconds" class="smpl">delta-seconds</a> 2542 2851 </pre><div id="rule.delta-seconds"> 2543 <p id="rfc.section.7. 8.p.4"> Time spans are non-negative decimal integers, representing time in seconds.</p>2852 <p id="rfc.section.7.16.p.4"> Time spans are non-negative decimal integers, representing time in seconds.</p> 2544 2853 </div> 2545 <div id="rfc.figure.u. 37"></div><pre class="inline"><span id="rfc.iref.g.43"></span> <a href="#rule.delta-seconds" class="smpl">delta-seconds</a> = 1*<a href="#notation" class="smpl">DIGIT</a>2546 </pre><p id="rfc.section.7. 8.p.6">Two examples of its use are</p>2547 <div id="rfc.figure.u. 38"></div><pre class="text"> Retry-After: Fri, 31 Dec 1999 23:59:59 GMT2854 <div id="rfc.figure.u.56"></div><pre class="inline"><span id="rfc.iref.g.56"></span> <a href="#rule.delta-seconds" class="smpl">delta-seconds</a> = 1*<a href="#notation" class="smpl">DIGIT</a> 2855 </pre><p id="rfc.section.7.16.p.6">Two examples of its use are</p> 2856 <div id="rfc.figure.u.57"></div><pre class="text"> Retry-After: Fri, 31 Dec 1999 23:59:59 GMT 2548 2857 Retry-After: 120 2549 </pre><p id="rfc.section.7. 8.p.8">In the latter example, the delay is 2 minutes.</p>2858 </pre><p id="rfc.section.7.16.p.8">In the latter example, the delay is 2 minutes.</p> 2550 2859 <div id="rfc.iref.s.39"></div> 2551 <div id="rfc.iref.h.1 0"></div>2552 <h2 id="rfc.section.7. 9"><a href="#rfc.section.7.9">7.9</a> <a id="header.server" href="#header.server">Server</a></h2>2553 <p id="rfc.section.7. 9.p.1">The "Server" header field contains information about the software used by the origin server to handle the request.</p>2554 <p id="rfc.section.7. 9.p.2">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 6.2</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.45"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for2860 <div id="rfc.iref.h.18"></div> 2861 <h2 id="rfc.section.7.17"><a href="#rfc.section.7.17">7.17</a> <a id="header.server" href="#header.server">Server</a></h2> 2862 <p id="rfc.section.7.17.p.1">The "Server" header field contains information about the software used by the origin server to handle the request.</p> 2863 <p id="rfc.section.7.17.p.2">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 6.2</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.48"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for 2555 2864 identifying the application. 2556 2865 </p> 2557 <div id="rfc.figure.u. 39"></div><pre class="inline"><span id="rfc.iref.g.44"></span> <a href="#header.server" class="smpl">Server</a> = <a href="#product.tokens" class="smpl">product</a> *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#product.tokens" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) )2558 </pre><p id="rfc.section.7. 9.p.4">Example:</p>2559 <div id="rfc.figure.u. 40"></div><pre class="text"> Server: CERN/3.0 libwww/2.172560 </pre><p id="rfc.section.7. 9.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.46"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).2561 </p> 2562 <div class="note" id="rfc.section.7. 9.p.7">2866 <div id="rfc.figure.u.58"></div><pre class="inline"><span id="rfc.iref.g.57"></span> <a href="#header.server" class="smpl">Server</a> = <a href="#product.tokens" class="smpl">product</a> *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#product.tokens" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) ) 2867 </pre><p id="rfc.section.7.17.p.4">Example:</p> 2868 <div id="rfc.figure.u.59"></div><pre class="text"> Server: CERN/3.0 libwww/2.17 2869 </pre><p id="rfc.section.7.17.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.49"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 2870 </p> 2871 <div class="note" id="rfc.section.7.17.p.7"> 2563 2872 <p> <b>Note:</b> Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks 2564 2873 against software that is known to contain security holes. Server implementors are encouraged to make this field a configurable … … 2567 2876 </div> 2568 2877 <div id="rfc.iref.u.1"></div> 2569 <div id="rfc.iref.h.1 1"></div>2570 <h2 id="rfc.section.7.1 0"><a href="#rfc.section.7.10">7.10</a> <a id="header.user-agent" href="#header.user-agent">User-Agent</a></h2>2571 <p id="rfc.section.7.1 0.p.1">The "User-Agent" header field contains information about the user agent originating the request. User agents <em class="bcp14">SHOULD</em> include this field with requests.2572 </p> 2573 <p id="rfc.section.7.1 0.p.2">Typically, it is used for statistical purposes, the tracing of protocol violations, and tailoring responses to avoid particular2878 <div id="rfc.iref.h.19"></div> 2879 <h2 id="rfc.section.7.18"><a href="#rfc.section.7.18">7.18</a> <a id="header.user-agent" href="#header.user-agent">User-Agent</a></h2> 2880 <p id="rfc.section.7.18.p.1">The "User-Agent" header field contains information about the user agent originating the request. User agents <em class="bcp14">SHOULD</em> include this field with requests. 2881 </p> 2882 <p id="rfc.section.7.18.p.2">Typically, it is used for statistical purposes, the tracing of protocol violations, and tailoring responses to avoid particular 2574 2883 user agent limitations. 2575 2884 </p> 2576 <p id="rfc.section.7.1 0.p.3">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 6.2</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.47"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance2885 <p id="rfc.section.7.18.p.3">The field can contain multiple product tokens (<a href="#product.tokens" title="Product Tokens">Section 6.2</a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.50"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance 2577 2886 for identifying the application. 2578 2887 </p> 2579 <p id="rfc.section.7.1 0.p.4">Because this field is usually sent on every request a user agent makes, implementations are encouraged not to include needlessly2888 <p id="rfc.section.7.18.p.4">Because this field is usually sent on every request a user agent makes, implementations are encouraged not to include needlessly 2580 2889 fine-grained detail, and to limit (or even prohibit) the addition of subproducts by third parties. Overly long and detailed 2581 2890 User-Agent field values make requests larger and can also be used to identify ("fingerprint") the user against their wishes. 2582 2891 </p> 2583 <p id="rfc.section.7.1 0.p.5">Likewise, implementations are encouraged not to use the product tokens of other implementations in order to declare compatibility2892 <p id="rfc.section.7.18.p.5">Likewise, implementations are encouraged not to use the product tokens of other implementations in order to declare compatibility 2584 2893 with them, as this circumvents the purpose of the field. Finally, they are encouraged not to use comments to identify products; 2585 2894 doing so makes the field value more difficult to parse. 2586 2895 </p> 2587 <div id="rfc.figure.u. 41"></div><pre class="inline"><span id="rfc.iref.g.45"></span> <a href="#header.user-agent" class="smpl">User-Agent</a> = <a href="#product.tokens" class="smpl">product</a> *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#product.tokens" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) )2588 </pre><p id="rfc.section.7.1 0.p.7">Example:</p>2589 <div id="rfc.figure.u. 42"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b32896 <div id="rfc.figure.u.60"></div><pre class="inline"><span id="rfc.iref.g.58"></span> <a href="#header.user-agent" class="smpl">User-Agent</a> = <a href="#product.tokens" class="smpl">product</a> *( <a href="#core.rules" class="smpl">RWS</a> ( <a href="#product.tokens" class="smpl">product</a> / <a href="#abnf.dependencies" class="smpl">comment</a> ) ) 2897 </pre><p id="rfc.section.7.18.p.7">Example:</p> 2898 <div id="rfc.figure.u.61"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3 2590 2899 </pre><h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> 2591 2900 <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a> <a id="method.registration" href="#method.registration">Method Registry</a></h2> … … 2910 3219 <td class="left">http</td> 2911 3220 <td class="left">standard</td> 2912 <td class="left"> <a href="#header.accept" id="rfc.xref.header.accept.3" title="Accept"> Appendix D.4.1</a>3221 <td class="left"> <a href="#header.accept" id="rfc.xref.header.accept.3" title="Accept">Section 7.1</a> 2913 3222 </td> 2914 3223 </tr> … … 2917 3226 <td class="left">http</td> 2918 3227 <td class="left">standard</td> 2919 <td class="left"> <a href="#header.accept-charset" id="rfc.xref.header.accept-charset.2" title="Accept-Charset"> Appendix D.4.2</a>3228 <td class="left"> <a href="#header.accept-charset" id="rfc.xref.header.accept-charset.2" title="Accept-Charset">Section 7.2</a> 2920 3229 </td> 2921 3230 </tr> … … 2924 3233 <td class="left">http</td> 2925 3234 <td class="left">standard</td> 2926 <td class="left"> <a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.3" title="Accept-Encoding"> Appendix D.4.3</a>3235 <td class="left"> <a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.3" title="Accept-Encoding">Section 7.3</a> 2927 3236 </td> 2928 3237 </tr> … … 2931 3240 <td class="left">http</td> 2932 3241 <td class="left">standard</td> 2933 <td class="left"> <a href="#header.accept-language" id="rfc.xref.header.accept-language.2" title="Accept-Language"> Appendix D.4.4</a>3242 <td class="left"> <a href="#header.accept-language" id="rfc.xref.header.accept-language.2" title="Accept-Language">Section 7.4</a> 2934 3243 </td> 2935 3244 </tr> … … 2938 3247 <td class="left">http</td> 2939 3248 <td class="left">standard</td> 2940 <td class="left"> <a href="#header.allow" id="rfc.xref.header.allow.3" title="Allow">Section 7. 1</a>3249 <td class="left"> <a href="#header.allow" id="rfc.xref.header.allow.3" title="Allow">Section 7.5</a> 2941 3250 </td> 2942 3251 </tr> … … 2945 3254 <td class="left">http</td> 2946 3255 <td class="left">standard</td> 2947 <td class="left"> <a href="#header.content-encoding" id="rfc.xref.header.content-encoding. 2" title="Content-Encoding">Appendix D.4.5</a>3256 <td class="left"> <a href="#header.content-encoding" id="rfc.xref.header.content-encoding.3" title="Content-Encoding">Section 7.6</a> 2948 3257 </td> 2949 3258 </tr> … … 2952 3261 <td class="left">http</td> 2953 3262 <td class="left">standard</td> 2954 <td class="left"> <a href="#header.content-language" id="rfc.xref.header.content-language.1" title="Content-Language"> Appendix D.4.6</a>3263 <td class="left"> <a href="#header.content-language" id="rfc.xref.header.content-language.1" title="Content-Language">Section 7.7</a> 2955 3264 </td> 2956 3265 </tr> … … 2959 3268 <td class="left">http</td> 2960 3269 <td class="left">standard</td> 2961 <td class="left"> <a href="#header.content-location" id="rfc.xref.header.content-location.3" title="Content-Location"> Appendix D.4.7</a>3270 <td class="left"> <a href="#header.content-location" id="rfc.xref.header.content-location.3" title="Content-Location">Section 7.8</a> 2962 3271 </td> 2963 3272 </tr> … … 2966 3275 <td class="left">http</td> 2967 3276 <td class="left">standard</td> 2968 <td class="left"> <a href="#header.content-type" id="rfc.xref.header.content-type.4" title="Content-Type"> Appendix D.4.8</a>3277 <td class="left"> <a href="#header.content-type" id="rfc.xref.header.content-type.4" title="Content-Type">Section 7.9</a> 2969 3278 </td> 2970 3279 </tr> … … 2973 3282 <td class="left">http</td> 2974 3283 <td class="left">standard</td> 2975 <td class="left"> <a href="#header.date" id="rfc.xref.header.date.2" title="Date">Section 7. 2</a>3284 <td class="left"> <a href="#header.date" id="rfc.xref.header.date.2" title="Date">Section 7.10</a> 2976 3285 </td> 2977 3286 </tr> … … 2980 3289 <td class="left">http</td> 2981 3290 <td class="left">standard</td> 2982 <td class="left"> <a href="#header.expect" id="rfc.xref.header.expect.3" title="Expect">Section 7. 3</a>3291 <td class="left"> <a href="#header.expect" id="rfc.xref.header.expect.3" title="Expect">Section 7.11</a> 2983 3292 </td> 2984 3293 </tr> … … 2987 3296 <td class="left">http</td> 2988 3297 <td class="left">standard</td> 2989 <td class="left"> <a href="#header.from" id="rfc.xref.header.from.2" title="From">Section 7. 4</a>3298 <td class="left"> <a href="#header.from" id="rfc.xref.header.from.2" title="From">Section 7.12</a> 2990 3299 </td> 2991 3300 </tr> … … 2994 3303 <td class="left">http</td> 2995 3304 <td class="left">standard</td> 2996 <td class="left"> <a href="#header.location" id="rfc.xref.header.location.4" title="Location">Section 7. 5</a>3305 <td class="left"> <a href="#header.location" id="rfc.xref.header.location.4" title="Location">Section 7.13</a> 2997 3306 </td> 2998 3307 </tr> … … 3001 3310 <td class="left">http</td> 3002 3311 <td class="left">standard</td> 3003 <td class="left"> <a href="#mime-version" id="rfc.xref.mime-version.1" title="MIME-Version">Appendix D. 7.1</a>3312 <td class="left"> <a href="#mime-version" id="rfc.xref.mime-version.1" title="MIME-Version">Appendix D.6.1</a> 3004 3313 </td> 3005 3314 </tr> … … 3008 3317 <td class="left">http</td> 3009 3318 <td class="left">standard</td> 3010 <td class="left"> <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.4" title="Max-Forwards">Section 7. 6</a>3319 <td class="left"> <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.4" title="Max-Forwards">Section 7.14</a> 3011 3320 </td> 3012 3321 </tr> … … 3015 3324 <td class="left">http</td> 3016 3325 <td class="left">standard</td> 3017 <td class="left"> <a href="#header.referer" id="rfc.xref.header.referer.2" title="Referer">Section 7. 7</a>3326 <td class="left"> <a href="#header.referer" id="rfc.xref.header.referer.2" title="Referer">Section 7.15</a> 3018 3327 </td> 3019 3328 </tr> … … 3022 3331 <td class="left">http</td> 3023 3332 <td class="left">standard</td> 3024 <td class="left"> <a href="#header.retry-after" id="rfc.xref.header.retry-after.3" title="Retry-After">Section 7. 8</a>3333 <td class="left"> <a href="#header.retry-after" id="rfc.xref.header.retry-after.3" title="Retry-After">Section 7.16</a> 3025 3334 </td> 3026 3335 </tr> … … 3029 3338 <td class="left">http</td> 3030 3339 <td class="left">standard</td> 3031 <td class="left"> <a href="#header.server" id="rfc.xref.header.server.2" title="Server">Section 7. 9</a>3340 <td class="left"> <a href="#header.server" id="rfc.xref.header.server.2" title="Server">Section 7.17</a> 3032 3341 </td> 3033 3342 </tr> … … 3036 3345 <td class="left">http</td> 3037 3346 <td class="left">standard</td> 3038 <td class="left"> <a href="#header.user-agent" id="rfc.xref.header.user-agent.2" title="User-Agent">Section 7.1 0</a>3347 <td class="left"> <a href="#header.user-agent" id="rfc.xref.header.user-agent.2" title="User-Agent">Section 7.18</a> 3039 3348 </td> 3040 3349 </tr> … … 3071 3380 of From and Referer information. 3072 3381 </p> 3073 <p id="rfc.section.9.1.p.7">The User-Agent (<a href="#header.user-agent" id="rfc.xref.header.user-agent.3" title="User-Agent">Section 7.1 0</a>) or Server (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section 7.9</a>) header fields can sometimes be used to determine that a specific client or server has a particular security hole which might3382 <p id="rfc.section.9.1.p.7">The User-Agent (<a href="#header.user-agent" id="rfc.xref.header.user-agent.3" title="User-Agent">Section 7.18</a>) or Server (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section 7.17</a>) header fields can sometimes be used to determine that a specific client or server has a particular security hole which might 3074 3383 be exploited. Unfortunately, this same information is often used for other valuable purposes for which HTTP currently has 3075 3384 no better mechanism. … … 3107 3416 </p> 3108 3417 <h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a> <a id="acks" href="#acks">Acknowledgments</a></h1> 3109 <p id="rfc.section.10.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 9</a> of <a href="#Part1" id="rfc.xref.Part1. 48"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.3418 <p id="rfc.section.10.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 9</a> of <a href="#Part1" id="rfc.xref.Part1.51"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 3110 3419 </p> 3111 3420 <h1 id="rfc.references"><a id="rfc.section.11" href="#rfc.section.11">11.</a> References … … 3337 3646 </p> 3338 3647 <p id="rfc.section.A.p.11">Reclassify "Allow" as response header field, removing the option to specify it in a PUT request. Relax the server requirement 3339 on the contents of the Allow header field and remove requirement on clients to always trust the header field value. (<a href="#header.allow" id="rfc.xref.header.allow.4" title="Allow">Section 7. 1</a>)3648 on the contents of the Allow header field and remove requirement on clients to always trust the header field value. (<a href="#header.allow" id="rfc.xref.header.allow.4" title="Allow">Section 7.5</a>) 3340 3649 </p> 3341 3650 <p id="rfc.section.A.p.12">The ABNF for the Expect header field has been both fixed (allowing parameters for value-less expectations as well) and simplified 3342 (allowing trailing semicolons after "100-continue" when they were invalid before). (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section 7. 3</a>)3651 (allowing trailing semicolons after "100-continue" when they were invalid before). (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section 7.11</a>) 3343 3652 </p> 3344 3653 <p id="rfc.section.A.p.13">Correct syntax of Location header field to allow URI references (including relative references and fragments), as referred 3345 3654 symbol "absoluteURI" wasn't what was expected, and add some clarifications as to when use of fragments would not be appropriate. 3346 (<a href="#header.location" id="rfc.xref.header.location.5" title="Location">Section 7. 5</a>)3347 </p> 3348 <p id="rfc.section.A.p.14">Restrict Max-Forwards header field to OPTIONS and TRACE (previously, extension methods could have used it as well). (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.5" title="Max-Forwards">Section 7. 6</a>)3349 </p> 3350 <p id="rfc.section.A.p.15">Allow Referer field value of "about:blank" as alternative to not specifying it. (<a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section 7. 7</a>)3655 (<a href="#header.location" id="rfc.xref.header.location.5" title="Location">Section 7.13</a>) 3656 </p> 3657 <p id="rfc.section.A.p.14">Restrict Max-Forwards header field to OPTIONS and TRACE (previously, extension methods could have used it as well). (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.5" title="Max-Forwards">Section 7.14</a>) 3658 </p> 3659 <p id="rfc.section.A.p.15">Allow Referer field value of "about:blank" as alternative to not specifying it. (<a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section 7.15</a>) 3351 3660 </p> 3352 3661 <p id="rfc.section.A.p.16">In the description of the Server header field, the Via field was described as a SHOULD. The requirement was and is stated 3353 correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1. 49"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 7.9</a>)3662 correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.52"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 7.17</a>) 3354 3663 </p> 3355 3664 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 3356 <div id="rfc.figure.u. 43"></div> <pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [3665 <div id="rfc.figure.u.62"></div> <pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ 3357 3666 OWS media-range [ accept-params ] ] ) ] 3358 3667 <a href="#header.accept-charset" class="smpl">Accept-Charset</a> = *( "," OWS ) ( charset / "*" ) [ OWS ";" OWS "q=" … … 3501 3810 3502 3811 <a href="#preferred.date.format" class="smpl">year</a> = 4DIGIT 3503 </pre> <div id="rfc.figure.u. 44"></div>3812 </pre> <div id="rfc.figure.u.63"></div> 3504 3813 <p>ABNF diagnostics:</p><pre class="inline">; qvalue UNDEFINED 3505 3814 ; Accept defined but not used … … 3526 3835 <h2 id="rfc.section.C.1"><a href="#rfc.section.C.1">C.1</a> Since RFC 2616 3527 3836 </h2> 3528 <p id="rfc.section.C.1.p.1">Extracted relevant partitions from <a href="#RFC2616" id="rfc.xref.RFC2616. 3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.3837 <p id="rfc.section.C.1.p.1">Extracted relevant partitions from <a href="#RFC2616" id="rfc.xref.RFC2616.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. 3529 3838 </p> 3530 3839 <h2 id="rfc.section.C.2"><a href="#rfc.section.C.2">C.2</a> Since draft-ietf-httpbis-p2-semantics-00 … … 3862 4171 header fields". The following payload header fields are defined by HTTP/1.1: 3863 4172 </p> 3864 <div id="rfc.table.u. 4">4173 <div id="rfc.table.u.5"> 3865 4174 <table class="tt full left" cellpadding="3" cellspacing="0"> 3866 4175 <thead> … … 3873 4182 <tr> 3874 4183 <td class="left">Content-Length</td> 3875 <td class="left"><a href="p1-messaging.html#header.content-length" title="Content-Length">Section 3.3.2</a> of <a href="#Part1" id="rfc.xref.Part1.5 0"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>4184 <td class="left"><a href="p1-messaging.html#header.content-length" title="Content-Length">Section 3.3.2</a> of <a href="#Part1" id="rfc.xref.Part1.53"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td> 3876 4185 </tr> 3877 4186 <tr> … … 3883 4192 </div> 3884 4193 <h3 id="rfc.section.D.1.2"><a href="#rfc.section.D.1.2">D.1.2</a> <a id="payload.body" href="#payload.body">Payload Body</a></h3> 3885 <p id="rfc.section.D.1.2.p.1">A payload body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.5 1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The payload body is obtained from the message body by decoding any Transfer-Encoding that might have been applied to ensure4194 <p id="rfc.section.D.1.2.p.1">A payload body is only present in a message when a message body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.54"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The payload body is obtained from the message body by decoding any Transfer-Encoding that might have been applied to ensure 3886 4195 safe and proper transfer of the message. 3887 4196 </p> … … 3907 4216 </p> 3908 4217 <p id="rfc.section.D.2.1.p.2">The following header fields are defined as representation metadata:</p> 3909 <div id="rfc.table.u. 5">4218 <div id="rfc.table.u.6"> 3910 4219 <table class="tt full left" cellpadding="3" cellspacing="0"> 3911 4220 <thead> … … 3918 4227 <tr> 3919 4228 <td class="left">Content-Encoding</td> 3920 <td class="left"><a href="#header.content-encoding" id="rfc.xref.header.content-encoding. 3" title="Content-Encoding">Appendix D.4.5</a></td>4229 <td class="left"><a href="#header.content-encoding" id="rfc.xref.header.content-encoding.4" title="Content-Encoding">Section 7.6</a></td> 3921 4230 </tr> 3922 4231 <tr> 3923 4232 <td class="left">Content-Language</td> 3924 <td class="left"><a href="#header.content-language" id="rfc.xref.header.content-language.2" title="Content-Language"> Appendix D.4.6</a></td>4233 <td class="left"><a href="#header.content-language" id="rfc.xref.header.content-language.2" title="Content-Language">Section 7.7</a></td> 3925 4234 </tr> 3926 4235 <tr> 3927 4236 <td class="left">Content-Location</td> 3928 <td class="left"><a href="#header.content-location" id="rfc.xref.header.content-location.4" title="Content-Location"> Appendix D.4.7</a></td>4237 <td class="left"><a href="#header.content-location" id="rfc.xref.header.content-location.4" title="Content-Location">Section 7.8</a></td> 3929 4238 </tr> 3930 4239 <tr> 3931 4240 <td class="left">Content-Type</td> 3932 <td class="left"><a href="#header.content-type" id="rfc.xref.header.content-type.5" title="Content-Type"> Appendix D.4.8</a></td>4241 <td class="left"><a href="#header.content-type" id="rfc.xref.header.content-type.5" title="Content-Type">Section 7.9</a></td> 3933 4242 </tr> 3934 4243 <tr> … … 3943 4252 metadata: 3944 4253 </p> 3945 <div id="rfc.table.u. 6">4254 <div id="rfc.table.u.7"> 3946 4255 <table class="tt full left" cellpadding="3" cellspacing="0"> 3947 4256 <thead> … … 3971 4280 a two-layer, ordered encoding model: 3972 4281 </p> 3973 <div id="rfc.figure.u. 45"></div><pre class="text"> representation-data := Content-Encoding( Content-Type( bits ) )4282 <div id="rfc.figure.u.64"></div><pre class="text"> representation-data := Content-Encoding( Content-Type( bits ) ) 3974 4283 </pre><p id="rfc.section.D.2.2.p.4">Content-Type specifies the media type of the underlying data, which defines both the data format and how that data <em class="bcp14">SHOULD</em> be processed by the recipient (within the scope of the request method semantics). Any HTTP/1.1 message containing a payload 3975 4284 body <em class="bcp14">SHOULD</em> include a Content-Type header field defining the media type of the associated representation unless that metadata is unknown … … 4039 4348 that doesn't conform to them is better than sending a 406 (Not Acceptable) response. 4040 4349 </p> 4041 <p id="rfc.section.D.3.1.p.5">Many of the mechanisms for expressing preferences use quality values to declare relative preference. See <a href="p1-messaging.html#quality.values" title="Quality Values">Section 4.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.5 2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for more information.4350 <p id="rfc.section.D.3.1.p.5">Many of the mechanisms for expressing preferences use quality values to declare relative preference. See <a href="p1-messaging.html#quality.values" title="Quality Values">Section 4.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.55"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for more information. 4042 4351 </p> 4043 4352 <p id="rfc.section.D.3.1.p.6">HTTP/1.1 includes the following header fields for enabling server-driven negotiation through description of user agent capabilities 4044 and user preferences: Accept (<a href="#header.accept" id="rfc.xref.header.accept.4" title="Accept"> Appendix D.4.1</a>), Accept-Charset (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.3" title="Accept-Charset">Appendix D.4.2</a>), Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.4" title="Accept-Encoding">Appendix D.4.3</a>), Accept-Language (<a href="#header.accept-language" id="rfc.xref.header.accept-language.3" title="Accept-Language">Appendix D.4.4</a>), and User-Agent (<a href="#header.user-agent" id="rfc.xref.header.user-agent.4" title="User-Agent">Section 7.10</a>). However, an origin server is not limited to these dimensions and <em class="bcp14">MAY</em> vary the response based on any aspect of the request, including aspects of the connection (e.g., IP address) or information4353 and user preferences: Accept (<a href="#header.accept" id="rfc.xref.header.accept.4" title="Accept">Section 7.1</a>), Accept-Charset (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.3" title="Accept-Charset">Section 7.2</a>), Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.4" title="Accept-Encoding">Section 7.3</a>), Accept-Language (<a href="#header.accept-language" id="rfc.xref.header.accept-language.3" title="Accept-Language">Section 7.4</a>), and User-Agent (<a href="#header.user-agent" id="rfc.xref.header.user-agent.4" title="User-Agent">Section 7.18</a>). However, an origin server is not limited to these dimensions and <em class="bcp14">MAY</em> vary the response based on any aspect of the request, including aspects of the connection (e.g., IP address) or information 4045 4354 within extension header fields not defined by this specification. 4046 4355 </p> … … 4070 4379 when the server is unwilling or unable to provide a varying response using server-driven negotiation. 4071 4380 </p> 4072 <h2 id="rfc.section.D.4"><a href="#rfc.section.D.4">D.4</a> <a id="header.field.definitions3" href="#header.field.definitions3">Header Field Definitions</a></h2> 4073 <p id="rfc.section.D.4.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to the payload of messages.</p> 4074 <div id="rfc.iref.a.2"></div> 4075 <div id="rfc.iref.h.12"></div> 4076 <h3 id="rfc.section.D.4.1"><a href="#rfc.section.D.4.1">D.4.1</a> <a id="header.accept" href="#header.accept">Accept</a></h3> 4077 <p id="rfc.section.D.4.1.p.1">The "Accept" header field can be used by user agents to specify response media types that are acceptable. Accept header fields 4078 can be used to indicate that the request is specifically limited to a small set of desired types, as in the case of a request 4079 for an in-line image. 4080 </p> 4081 <div id="rfc.figure.u.46"></div><pre class="inline"><span id="rfc.iref.g.46"></span><span id="rfc.iref.g.47"></span><span id="rfc.iref.g.48"></span><span id="rfc.iref.g.49"></span> <a href="#header.accept" class="smpl">Accept</a> = #( <a href="#header.accept" class="smpl">media-range</a> [ <a href="#header.accept" class="smpl">accept-params</a> ] ) 4082 4083 <a href="#header.accept" class="smpl">media-range</a> = ( "*/*" 4084 / ( <a href="#media.types" class="smpl">type</a> "/" "*" ) 4085 / ( <a href="#media.types" class="smpl">type</a> "/" <a href="#media.types" class="smpl">subtype</a> ) 4086 ) *( <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> <a href="#rule.parameter" class="smpl">parameter</a> ) 4087 <a href="#header.accept" class="smpl">accept-params</a> = <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> "q=" <a href="#abnf.dependencies" class="smpl">qvalue</a> *( <a href="#header.accept" class="smpl">accept-ext</a> ) 4088 <a href="#header.accept" class="smpl">accept-ext</a> = <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> <a href="#core.rules" class="smpl">token</a> [ "=" <a href="#core.rules" class="smpl">word</a> ] 4089 </pre><p id="rfc.section.D.4.1.p.3">The asterisk "*" character is used to group media types into ranges, with "*/*" indicating all media types and "type/*" indicating 4090 all subtypes of that type. The media-range <em class="bcp14">MAY</em> include media type parameters that are applicable to that range. 4091 </p> 4092 <p id="rfc.section.D.4.1.p.4">Each media-range <em class="bcp14">MAY</em> be followed by one or more accept-params, beginning with the "q" parameter for indicating a relative quality factor. The first 4093 "q" parameter (if any) separates the media-range parameter(s) from the accept-params. Quality factors allow the user or user 4094 agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (<a href="p1-messaging.html#quality.values" title="Quality Values">Section 4.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.53"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The default value is q=1. 4095 </p> 4096 <div class="note" id="rfc.section.D.4.1.p.5"> 4097 <p> <b>Note:</b> Use of the "q" parameter name to separate media type parameters from Accept extension parameters is due to historical practice. 4098 Although this prevents any media type parameter named "q" from being used with a media range, such an event is believed to 4099 be unlikely given the lack of any "q" parameters in the IANA media type registry and the rare usage of any media type parameters 4100 in Accept. Future media types are discouraged from registering any parameter named "q". 4101 </p> 4102 </div> 4103 <p id="rfc.section.D.4.1.p.6">The example</p> 4104 <div id="rfc.figure.u.47"></div><pre class="text"> Accept: audio/*; q=0.2, audio/basic 4105 </pre><p id="rfc.section.D.4.1.p.8"> <em class="bcp14">SHOULD</em> be interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% mark-down in 4106 quality". 4107 </p> 4108 <p id="rfc.section.D.4.1.p.9">A request without any Accept header field implies that the user agent will accept any media type in response. If an Accept 4109 header field is present in a request and none of the available representations for the response have a media type that is 4110 listed as acceptable, the origin server <em class="bcp14">MAY</em> either honor the Accept header field by sending a 406 (Not Acceptable) response or disregard the Accept header field by treating 4111 the response as if it is not subject to content negotiation. 4112 </p> 4113 <p id="rfc.section.D.4.1.p.10">A more elaborate example is</p> 4114 <div id="rfc.figure.u.48"></div><pre class="text"> Accept: text/plain; q=0.5, text/html, 4115 text/x-dvi; q=0.8, text/x-c 4116 </pre><p id="rfc.section.D.4.1.p.12">Verbally, this would be interpreted as "text/html and text/x-c are the preferred media types, but if they do not exist, then 4117 send the text/x-dvi representation, and if that does not exist, send the text/plain representation". 4118 </p> 4119 <p id="rfc.section.D.4.1.p.13">Media ranges can be overridden by more specific media ranges or specific media types. If more than one media range applies 4120 to a given type, the most specific reference has precedence. For example, 4121 </p> 4122 <div id="rfc.figure.u.49"></div><pre class="text"> Accept: text/*, text/plain, text/plain;format=flowed, */* 4123 </pre><p id="rfc.section.D.4.1.p.15">have the following precedence: </p> 4124 <ol> 4125 <li>text/plain;format=flowed</li> 4126 <li>text/plain</li> 4127 <li>text/*</li> 4128 <li>*/*</li> 4129 </ol> 4130 <p id="rfc.section.D.4.1.p.16">The media type quality factor associated with a given type is determined by finding the media range with the highest precedence 4131 which matches that type. For example, 4132 </p> 4133 <div id="rfc.figure.u.50"></div><pre class="text"> Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, 4134 text/html;level=2;q=0.4, */*;q=0.5 4135 </pre><p id="rfc.section.D.4.1.p.18">would cause the following values to be associated:</p> 4136 <div id="rfc.table.u.7"> 4137 <table class="tt full left" cellpadding="3" cellspacing="0"> 4138 <thead> 4139 <tr> 4140 <th>Media Type</th> 4141 <th>Quality Value</th> 4142 </tr> 4143 </thead> 4144 <tbody> 4145 <tr> 4146 <td class="left">text/html;level=1</td> 4147 <td class="left">1</td> 4148 </tr> 4149 <tr> 4150 <td class="left">text/html</td> 4151 <td class="left">0.7</td> 4152 </tr> 4153 <tr> 4154 <td class="left">text/plain</td> 4155 <td class="left">0.3</td> 4156 </tr> 4157 <tr> 4158 <td class="left">image/jpeg</td> 4159 <td class="left">0.5</td> 4160 </tr> 4161 <tr> 4162 <td class="left">text/html;level=2</td> 4163 <td class="left">0.4</td> 4164 </tr> 4165 <tr> 4166 <td class="left">text/html;level=3</td> 4167 <td class="left">0.7</td> 4168 </tr> 4169 </tbody> 4170 </table> 4171 </div> 4172 <p id="rfc.section.D.4.1.p.19"> <b>Note:</b> A user agent might be provided with a default set of quality values for certain media ranges. However, unless the user agent 4173 is a closed system which cannot interact with other rendering agents, this default set ought to be configurable by the user. 4174 </p> 4175 <div id="rfc.iref.a.3"></div> 4176 <div id="rfc.iref.h.13"></div> 4177 <h3 id="rfc.section.D.4.2"><a href="#rfc.section.D.4.2">D.4.2</a> <a id="header.accept-charset" href="#header.accept-charset">Accept-Charset</a></h3> 4178 <p id="rfc.section.D.4.2.p.1">The "Accept-Charset" header field can be used by user agents to indicate what character encodings are acceptable in a response 4179 payload. This field allows clients capable of understanding more comprehensive or special-purpose character encodings to signal 4180 that capability to a server which is capable of representing documents in those character encodings. 4181 </p> 4182 <div id="rfc.figure.u.51"></div><pre class="inline"><span id="rfc.iref.g.50"></span> <a href="#header.accept-charset" class="smpl">Accept-Charset</a> = 1#( ( <a href="#rule.charset" class="smpl">charset</a> / "*" ) 4183 [ <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> "q=" <a href="#abnf.dependencies" class="smpl">qvalue</a> ] ) 4184 </pre><p id="rfc.section.D.4.2.p.3">Character encoding values (a.k.a., charsets) are described in <a href="#character.sets" title="Character Encodings (charset)">Section 6.3</a>. Each charset <em class="bcp14">MAY</em> be given an associated quality value which represents the user's preference for that charset. The default value is q=1. An 4185 example is 4186 </p> 4187 <div id="rfc.figure.u.52"></div><pre class="text"> Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 4188 </pre><p id="rfc.section.D.4.2.p.5">The special value "*", if present in the Accept-Charset field, matches every character encoding which is not mentioned elsewhere 4189 in the Accept-Charset field. If no "*" is present in an Accept-Charset field, then all character encodings not explicitly 4190 mentioned get a quality value of 0. 4191 </p> 4192 <p id="rfc.section.D.4.2.p.6">A request without any Accept-Charset header field implies that the user agent will accept any character encoding in response. 4193 If an Accept-Charset header field is present in a request and none of the available representations for the response have 4194 a character encoding that is listed as acceptable, the origin server <em class="bcp14">MAY</em> either honor the Accept-Charset header field by sending a 406 (Not Acceptable) response or disregard the Accept-Charset header 4195 field by treating the response as if it is not subject to content negotiation. 4196 </p> 4197 <div id="rfc.iref.a.4"></div> 4198 <div id="rfc.iref.h.14"></div> 4199 <h3 id="rfc.section.D.4.3"><a href="#rfc.section.D.4.3">D.4.3</a> <a id="header.accept-encoding" href="#header.accept-encoding">Accept-Encoding</a></h3> 4200 <p id="rfc.section.D.4.3.p.1">The "Accept-Encoding" header field can be used by user agents to indicate what response content-codings (<a href="#content.codings" title="Content Codings">Section 6.4</a>) are acceptable in the response. An "identity" token is used as a synonym for "no encoding" in order to communicate when 4201 no encoding is preferred. 4202 </p> 4203 <div id="rfc.figure.u.53"></div><pre class="inline"><span id="rfc.iref.g.51"></span><span id="rfc.iref.g.52"></span> <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> = #( <a href="#header.accept-encoding" class="smpl">codings</a> [ <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> "q=" <a href="#abnf.dependencies" class="smpl">qvalue</a> ] ) 4204 <a href="#header.accept-encoding" class="smpl">codings</a> = <a href="#content.codings" class="smpl">content-coding</a> / "identity" / "*" 4205 </pre><p id="rfc.section.D.4.3.p.3">Each codings value <em class="bcp14">MAY</em> be given an associated quality value which represents the preference for that encoding. The default value is q=1. 4206 </p> 4207 <p id="rfc.section.D.4.3.p.4">For example,</p> 4208 <div id="rfc.figure.u.54"></div><pre class="text"> Accept-Encoding: compress, gzip 4209 Accept-Encoding: 4210 Accept-Encoding: * 4211 Accept-Encoding: compress;q=0.5, gzip;q=1.0 4212 Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 4213 </pre><p id="rfc.section.D.4.3.p.6">A server tests whether a content-coding for a given representation is acceptable, according to an Accept-Encoding field, using 4214 these rules: 4215 </p> 4216 <ol> 4217 <li>The special "*" symbol in an Accept-Encoding field matches any available content-coding not explicitly listed in the header 4218 field. 4219 </li> 4220 <li>If the representation has no content-coding, then it is acceptable by default unless specifically excluded by the Accept-Encoding 4221 field stating either "identity;q=0" or "*;q=0" without a more specific entry for "identity". 4222 </li> 4223 <li>If the representation's content-coding is one of the content-codings listed in the Accept-Encoding field, then it is acceptable 4224 unless it is accompanied by a qvalue of 0. (As defined in <a href="p1-messaging.html#quality.values" title="Quality Values">Section 4.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.54"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, a qvalue of 0 means "not acceptable".) 4225 </li> 4226 <li>If multiple content-codings are acceptable, then the acceptable content-coding with the highest non-zero qvalue is preferred.</li> 4227 </ol> 4228 <p id="rfc.section.D.4.3.p.7">An Accept-Encoding header field with a combined field-value that is empty implies that the user agent does not want any content-coding 4229 in response. If an Accept-Encoding header field is present in a request and none of the available representations for the 4230 response have a content-coding that is listed as acceptable, the origin server <em class="bcp14">SHOULD</em> send a response without any content-coding. 4231 </p> 4232 <p id="rfc.section.D.4.3.p.8">A request without an Accept-Encoding header field implies that the user agent will accept any content-coding in response, 4233 but a representation without content-coding is preferred for compatibility with the widest variety of user agents. 4234 </p> 4235 <div class="note" id="rfc.section.D.4.3.p.9"> 4236 <p> <b>Note:</b> Most HTTP/1.0 applications do not recognize or obey qvalues associated with content-codings. This means that qvalues will 4237 not work and are not permitted with x-gzip or x-compress. 4238 </p> 4239 </div> 4240 <div id="rfc.iref.a.5"></div> 4241 <div id="rfc.iref.h.15"></div> 4242 <h3 id="rfc.section.D.4.4"><a href="#rfc.section.D.4.4">D.4.4</a> <a id="header.accept-language" href="#header.accept-language">Accept-Language</a></h3> 4243 <p id="rfc.section.D.4.4.p.1">The "Accept-Language" header field can be used by user agents to indicate the set of natural languages that are preferred 4244 in the response. Language tags are defined in <a href="#language.tags" title="Language Tags">Section 6.6</a>. 4245 </p> 4246 <div id="rfc.figure.u.55"></div><pre class="inline"><span id="rfc.iref.g.53"></span><span id="rfc.iref.g.54"></span> <a href="#header.accept-language" class="smpl">Accept-Language</a> = 4247 1#( <a href="#header.accept-language" class="smpl">language-range</a> [ <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> "q=" <a href="#abnf.dependencies" class="smpl">qvalue</a> ] ) 4248 <a href="#header.accept-language" class="smpl">language-range</a> = 4249 <language-range, defined in <a href="#RFC4647" id="rfc.xref.RFC4647.1"><cite title="Matching of Language Tags">[RFC4647]</cite></a>, <a href="http://tools.ietf.org/html/rfc4647#section-2.1">Section 2.1</a>> 4250 </pre><p id="rfc.section.D.4.4.p.3">Each language-range can be given an associated quality value which represents an estimate of the user's preference for the 4251 languages specified by that range. The quality value defaults to "q=1". For example, 4252 </p> 4253 <div id="rfc.figure.u.56"></div><pre class="text"> Accept-Language: da, en-gb;q=0.8, en;q=0.7 4254 </pre><p id="rfc.section.D.4.4.p.5">would mean: "I prefer Danish, but will accept British English and other types of English". (see also <a href="http://tools.ietf.org/html/rfc4647#section-2.3">Section 2.3</a> of <a href="#RFC4647" id="rfc.xref.RFC4647.2"><cite title="Matching of Language Tags">[RFC4647]</cite></a>) 4255 </p> 4256 <p id="rfc.section.D.4.4.p.6">For matching, <a href="http://tools.ietf.org/html/rfc4647#section-3">Section 3</a> of <a href="#RFC4647" id="rfc.xref.RFC4647.3"><cite title="Matching of Language Tags">[RFC4647]</cite></a> defines several matching schemes. Implementations can offer the most appropriate matching scheme for their requirements. 4257 </p> 4258 <div class="note" id="rfc.section.D.4.4.p.7"> 4259 <p> <b>Note:</b> The "Basic Filtering" scheme (<a href="#RFC4647" id="rfc.xref.RFC4647.4"><cite title="Matching of Language Tags">[RFC4647]</cite></a>, <a href="http://tools.ietf.org/html/rfc4647#section-3.3.1">Section 3.3.1</a>) is identical to the matching scheme that was previously defined in <a href="http://tools.ietf.org/html/rfc2616#section-14.4">Section 14.4</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. 4260 </p> 4261 </div> 4262 <p id="rfc.section.D.4.4.p.8">It might be contrary to the privacy expectations of the user to send an Accept-Language header field with the complete linguistic 4263 preferences of the user in every request. For a discussion of this issue, see <a href="#privacy.issues.connected.to.accept.header.fields" title="Privacy Issues Connected to Accept Header Fields">Appendix D.6.1</a>. 4264 </p> 4265 <p id="rfc.section.D.4.4.p.9">As intelligibility is highly dependent on the individual user, it is recommended that client applications make the choice 4266 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. 4267 </p> 4268 <div class="note" id="rfc.section.D.4.4.p.10"> 4269 <p> <b>Note:</b> When making the choice of linguistic preference available to the user, we remind implementors of the fact that users are not 4270 familiar with the details of language matching as described above, and ought to be provided appropriate guidance. As an example, 4271 users might assume that on selecting "en-gb", they will be served any kind of English document if British English is not available. 4272 A user agent might suggest in such a case to add "en" to get the best matching behavior. 4273 </p> 4274 </div> 4275 <div id="rfc.iref.c.7"></div> 4276 <div id="rfc.iref.h.16"></div> 4277 <h3 id="rfc.section.D.4.5"><a href="#rfc.section.D.4.5">D.4.5</a> <a id="header.content-encoding" href="#header.content-encoding">Content-Encoding</a></h3> 4278 <p id="rfc.section.D.4.5.p.1">The "Content-Encoding" header field indicates what content-codings have been applied to the representation beyond those inherent 4279 in the media type, and thus what decoding mechanisms have to be applied in order to obtain the media-type referenced by the 4280 Content-Type header field. Content-Encoding is primarily used to allow a representation to be compressed without losing the 4281 identity of its underlying media type. 4282 </p> 4283 <div id="rfc.figure.u.57"></div><pre class="inline"><span id="rfc.iref.g.55"></span> <a href="#header.content-encoding" class="smpl">Content-Encoding</a> = 1#<a href="#content.codings" class="smpl">content-coding</a> 4284 </pre><p id="rfc.section.D.4.5.p.3">Content codings are defined in <a href="#content.codings" title="Content Codings">Section 6.4</a>. An example of its use is 4285 </p> 4286 <div id="rfc.figure.u.58"></div><pre class="text"> Content-Encoding: gzip 4287 </pre><p id="rfc.section.D.4.5.p.5">The content-coding is a characteristic of the representation. Typically, the representation body is stored with this encoding 4288 and is only decoded before rendering or analogous usage. However, a transforming 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 4289 directive is present in the message. 4290 </p> 4291 <p id="rfc.section.D.4.5.p.6">If the media type includes an inherent encoding, such as a data format that is always compressed, then that encoding would 4292 not be restated as a Content-Encoding even if it happens to be the same algorithm as one of the content-codings. Such a content-coding 4293 would only be listed if, for some bizarre reason, it is applied a second time to form the representation. Likewise, an origin 4294 server might choose to publish the same payload data as multiple representations that differ only in whether the coding is 4295 defined as part of Content-Type or Content-Encoding, since some user agents will behave differently in their handling of each 4296 response (e.g., open a "Save as ..." dialog instead of automatic decompression and rendering of content). 4297 </p> 4298 <p id="rfc.section.D.4.5.p.7">A representation that has a content-coding applied to it <em class="bcp14">MUST</em> include a Content-Encoding header field (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.4" title="Content-Encoding">Appendix D.4.5</a>) that lists the content-coding(s) applied. 4299 </p> 4300 <p id="rfc.section.D.4.5.p.8">If multiple encodings have been applied to a representation, 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 header fields not defined by this specification. 4301 </p> 4302 <p id="rfc.section.D.4.5.p.9">If the content-coding of a representation 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). 4303 </p> 4304 <div id="rfc.iref.c.8"></div> 4305 <div id="rfc.iref.h.17"></div> 4306 <h3 id="rfc.section.D.4.6"><a href="#rfc.section.D.4.6">D.4.6</a> <a id="header.content-language" href="#header.content-language">Content-Language</a></h3> 4307 <p id="rfc.section.D.4.6.p.1">The "Content-Language" header field describes the natural language(s) of the intended audience for the representation. Note 4308 that this might not be equivalent to all the languages used within the representation. 4309 </p> 4310 <div id="rfc.figure.u.59"></div><pre class="inline"><span id="rfc.iref.g.56"></span> <a href="#header.content-language" class="smpl">Content-Language</a> = 1#<a href="#language.tags" class="smpl">language-tag</a> 4311 </pre><p id="rfc.section.D.4.6.p.3">Language tags are defined in <a href="#language.tags" title="Language Tags">Section 6.6</a>. The primary purpose of Content-Language is to allow a user to identify and differentiate representations according to the 4312 user's own preferred language. Thus, if the body content is intended only for a Danish-literate audience, the appropriate 4313 field is 4314 </p> 4315 <div id="rfc.figure.u.60"></div><pre class="text"> Content-Language: da 4316 </pre><p id="rfc.section.D.4.6.p.5">If no Content-Language is specified, the default is that the content is intended for all language audiences. This might mean 4317 that the sender does not consider it to be specific to any natural language, or that the sender does not know for which language 4318 it is intended. 4319 </p> 4320 <p id="rfc.section.D.4.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 4321 simultaneously in the original Maori and English versions, would call for 4322 </p> 4323 <div id="rfc.figure.u.61"></div><pre class="text"> Content-Language: mi, en 4324 </pre><p id="rfc.section.D.4.6.p.8">However, just because multiple languages are present within a representation does not mean that it is intended for multiple 4325 linguistic audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin", which is clearly 4326 intended to be used by an English-literate audience. In this case, the Content-Language would properly only include "en". 4327 </p> 4328 <p id="rfc.section.D.4.6.p.9">Content-Language <em class="bcp14">MAY</em> be applied to any media type — it is not limited to textual documents. 4329 </p> 4330 <div id="rfc.iref.c.9"></div> 4331 <div id="rfc.iref.h.18"></div> 4332 <h3 id="rfc.section.D.4.7"><a href="#rfc.section.D.4.7">D.4.7</a> <a id="header.content-location" href="#header.content-location">Content-Location</a></h3> 4333 <p id="rfc.section.D.4.7.p.1">The "Content-Location" header field supplies a URI that can be used as a specific identifier for the representation in this 4334 message. In other words, if one were to perform a GET on this URI at the time of this message's generation, then a 200 response 4335 would contain the same representation that is enclosed as payload in this message. 4336 </p> 4337 <div id="rfc.figure.u.62"></div><pre class="inline"><span id="rfc.iref.g.57"></span> <a href="#header.content-location" class="smpl">Content-Location</a> = <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a> 4338 </pre><p id="rfc.section.D.4.7.p.3">The Content-Location value is not a replacement for the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.55"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME 4339 body parts in <a href="http://tools.ietf.org/html/rfc2557#section-4">Section 4</a> of <a href="#RFC2557" id="rfc.xref.RFC2557.1"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a>. However, its appearance in an HTTP message has some special implications for HTTP recipients. 4340 </p> 4341 <p id="rfc.section.D.4.7.p.4">If Content-Location is included in a response message and its value is the same as the effective request URI, then the response 4342 payload <em class="bcp14">SHOULD</em> be considered a current representation of that resource. For a GET or HEAD request, this is the same as the default semantics 4343 when no Content-Location is provided by the server. For a state-changing request like PUT or POST, it implies that the server's 4344 response contains the new representation of that resource, thereby distinguishing it from representations that might only 4345 report about the action (e.g., "It worked!"). This allows authoring applications to update their local copies without the 4346 need for a subsequent GET request. 4347 </p> 4348 <p id="rfc.section.D.4.7.p.5">If Content-Location is included in a response message and its value differs from the effective request URI, then the origin 4349 server is informing recipients that this representation has its own, presumably more specific, identifier. For a GET or HEAD 4350 request, this is an indication that the effective request URI identifies a resource that is subject to content negotiation 4351 and the selected representation for this response can also be found at the identified URI. For other methods, such a Content-Location 4352 indicates that this representation contains a report on the action's status and the same report is available (for future access 4353 with GET) at the given URI. For example, a purchase transaction made via a POST request might include a receipt document as 4354 the payload of the 200 response; the Content-Location value provides an identifier for retrieving a copy of that same receipt 4355 in the future. 4356 </p> 4357 <p id="rfc.section.D.4.7.p.6">If Content-Location is included in a request message, then it <em class="bcp14">MAY</em> be interpreted by the origin server as an indication of where the user agent originally obtained the content of the enclosed 4358 representation (prior to any subsequent modification of the content by that user agent). In other words, the user agent is 4359 providing the same representation metadata that it received with the original representation. However, such interpretation <em class="bcp14">MUST NOT</em> be used to alter the semantics of the method requested by the client. For example, if a client makes a PUT request on a negotiated 4360 resource and the origin server accepts that PUT (without redirection), then the new set of values for that resource is expected 4361 to be consistent with the one representation supplied in that PUT; the Content-Location cannot be used as a form of reverse 4362 content selection that identifies only one of the negotiated representations to be updated. If the user agent had wanted the 4363 latter semantics, it would have applied the PUT directly to the Content-Location URI. 4364 </p> 4365 <p id="rfc.section.D.4.7.p.7">A Content-Location field received in a request message is transitory information that <em class="bcp14">SHOULD NOT</em> be saved with other representation metadata for use in later responses. The Content-Location's value might be saved for use 4366 in other contexts, such as within source links or other metadata. 4367 </p> 4368 <p id="rfc.section.D.4.7.p.8">A cache cannot assume that a representation with a Content-Location different from the URI used to retrieve it can be used 4369 to respond to later requests on that Content-Location URI. 4370 </p> 4371 <p id="rfc.section.D.4.7.p.9">If the Content-Location value is a partial URI, the partial URI is interpreted relative to the effective request URI.</p> 4372 <div id="rfc.iref.c.10"></div> 4373 <div id="rfc.iref.h.19"></div> 4374 <h3 id="rfc.section.D.4.8"><a href="#rfc.section.D.4.8">D.4.8</a> <a id="header.content-type" href="#header.content-type">Content-Type</a></h3> 4375 <p id="rfc.section.D.4.8.p.1">The "Content-Type" header field indicates the media type of the representation. In the case of responses to the HEAD method, 4376 the media type is that which would have been sent had the request been a GET. 4377 </p> 4378 <div id="rfc.figure.u.63"></div><pre class="inline"><span id="rfc.iref.g.58"></span> <a href="#header.content-type" class="smpl">Content-Type</a> = <a href="#media.types" class="smpl">media-type</a> 4379 </pre><p id="rfc.section.D.4.8.p.3">Media types are defined in <a href="#media.types" title="Media Types">Section 6.5</a>. An example of the field is 4380 </p> 4381 <div id="rfc.figure.u.64"></div><pre class="text"> Content-Type: text/html; charset=ISO-8859-4 4382 </pre><p id="rfc.section.D.4.8.p.5">Further discussion of Content-Type is provided in <a href="#representation.data" title="Representation Data">Appendix D.2.2</a>. 4383 </p> 4384 <h2 id="rfc.section.D.5"><a href="#rfc.section.D.5">D.5</a> <a id="IANA.considerations3" href="#IANA.considerations3">IANA Considerations</a></h2> 4385 <h3 id="rfc.section.D.5.1"><a href="#rfc.section.D.5.1">D.5.1</a> <a id="content.coding.registration" href="#content.coding.registration">Content Coding Registry</a></h3> 4386 <p id="rfc.section.D.5.1.p.1">The registration procedure for HTTP Content Codings is now defined by <a href="#content.coding.registry" title="Content Coding Registry">Section 6.4.1</a> of this document. 4387 </p> 4388 <p id="rfc.section.D.5.1.p.2">The HTTP Content Codings Registry located at <<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>> shall be updated with the registration below: 4381 <h2 id="rfc.section.D.4"><a href="#rfc.section.D.4">D.4</a> <a id="IANA.considerations3" href="#IANA.considerations3">IANA Considerations</a></h2> 4382 <h3 id="rfc.section.D.4.1"><a href="#rfc.section.D.4.1">D.4.1</a> <a id="content.coding.registration" href="#content.coding.registration">Content Coding Registry</a></h3> 4383 <p id="rfc.section.D.4.1.p.1">The registration procedure for HTTP Content Codings is now defined by <a href="#content.coding.registry" title="Content Coding Registry">Section 6.4.1</a> of this document. 4384 </p> 4385 <p id="rfc.section.D.4.1.p.2">The HTTP Content Codings Registry located at <<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>> shall be updated with the registration below: 4389 4386 </p> 4390 4387 <div id="rfc.table.4"> … … 4421 4418 <td class="left">identity</td> 4422 4419 <td class="left">reserved (synonym for "no encoding" in Accept-Encoding header field)</td> 4423 <td class="left"> <a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.5" title="Accept-Encoding"> Appendix D.4.3</a>4420 <td class="left"> <a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.5" title="Accept-Encoding">Section 7.3</a> 4424 4421 </td> 4425 4422 </tr> … … 4427 4424 </table> 4428 4425 </div> 4429 <h2 id="rfc.section.D. 6"><a href="#rfc.section.D.6">D.6</a> <a id="security.considerations3" href="#security.considerations3">Security Considerations</a></h2>4430 <p id="rfc.section.D. 6.p.1">This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.14426 <h2 id="rfc.section.D.5"><a href="#rfc.section.D.5">D.5</a> <a id="security.considerations3" href="#security.considerations3">Security Considerations</a></h2> 4427 <p id="rfc.section.D.5.p.1">This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.1 4431 4428 as described by this document. The discussion does not include definitive solutions to the problems revealed, though it does 4432 4429 make some suggestions for reducing security risks. 4433 4430 </p> 4434 <h3 id="rfc.section.D. 6.1"><a href="#rfc.section.D.6.1">D.6.1</a> <a id="privacy.issues.connected.to.accept.header.fields" href="#privacy.issues.connected.to.accept.header.fields">Privacy Issues Connected to Accept Header Fields</a></h3>4435 <p id="rfc.section.D. 6.1.p.1">Accept header fields can reveal information about the user to all servers which are accessed. The Accept-Language header field4431 <h3 id="rfc.section.D.5.1"><a href="#rfc.section.D.5.1">D.5.1</a> <a id="privacy.issues.connected.to.accept.header.fields" href="#privacy.issues.connected.to.accept.header.fields">Privacy Issues Connected to Accept Header Fields</a></h3> 4432 <p id="rfc.section.D.5.1.p.1">Accept header fields can reveal information about the user to all servers which are accessed. The Accept-Language header field 4436 4433 in particular can reveal information the user would consider to be of a private nature, because the understanding of particular 4437 4434 languages is often strongly correlated to the membership of a particular ethnic group. User agents which offer the option … … 4439 4436 configuration process include a message which makes the user aware of the loss of privacy involved. 4440 4437 </p> 4441 <p id="rfc.section.D. 6.1.p.2">An approach that limits the loss of privacy would be for a user agent to omit the sending of Accept-Language header fields4438 <p id="rfc.section.D.5.1.p.2">An approach that limits the loss of privacy would be for a user agent to omit the sending of Accept-Language header fields 4442 4439 by default, and to ask the user whether or not to start sending Accept-Language header fields to a server if it detects, by 4443 4440 looking for any Vary header fields generated by the server, that such sending could improve the quality of service. 4444 4441 </p> 4445 <p id="rfc.section.D. 6.1.p.3">Elaborate user-customized accept header fields sent in every request, in particular if these include quality values, can be4442 <p id="rfc.section.D.5.1.p.3">Elaborate user-customized accept header fields sent in every request, in particular if these include quality values, can be 4446 4443 used by servers as relatively reliable and long-lived user identifiers. Such user identifiers would allow content providers 4447 4444 to do click-trail tracking, and would allow collaborating content providers to match cross-server click-trails or form submissions … … 4451 4448 filter the accept header fields 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. 4452 4449 </p> 4453 <h2 id="rfc.section.D. 7"><a href="#rfc.section.D.7">D.7</a> <a id="differences.between.http.and.mime" href="#differences.between.http.and.mime">Differences between HTTP and MIME</a></h2>4454 <p id="rfc.section.D. 7.p.1">HTTP/1.1 uses many of the constructs defined for Internet Mail (<a href="#RFC5322" id="rfc.xref.RFC5322.5"><cite title="Internet Message Format">[RFC5322]</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 a message body to be transmitted in an open variety of representations and with extensible mechanisms. However,4450 <h2 id="rfc.section.D.6"><a href="#rfc.section.D.6">D.6</a> <a id="differences.between.http.and.mime" href="#differences.between.http.and.mime">Differences between HTTP and MIME</a></h2> 4451 <p id="rfc.section.D.6.p.1">HTTP/1.1 uses many of the constructs defined for Internet Mail (<a href="#RFC5322" id="rfc.xref.RFC5322.5"><cite title="Internet Message Format">[RFC5322]</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 a message body to be transmitted in an open variety of representations and with extensible mechanisms. However, 4455 4452 RFC 2045 discusses mail, and HTTP has a few features that are different from those described in MIME. These differences were 4456 4453 carefully chosen to optimize performance over binary connections, to allow greater freedom in the use of new media types, 4457 4454 to make date comparisons easier, and to acknowledge the practice of some early HTTP servers and clients. 4458 4455 </p> 4459 <p id="rfc.section.D. 7.p.2">This appendix describes specific areas where HTTP differs from MIME. 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 environments4456 <p id="rfc.section.D.6.p.2">This appendix describes specific areas where HTTP differs from MIME. 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 4460 4457 to HTTP also need to be aware of the differences because some conversions might be required. 4461 4458 </p> 4462 4459 <div id="rfc.iref.m.10"></div> 4463 4460 <div id="rfc.iref.h.20"></div> 4464 <h3 id="rfc.section.D. 7.1"><a href="#rfc.section.D.7.1">D.7.1</a> <a id="mime-version" href="#mime-version">MIME-Version</a></h3>4465 <p id="rfc.section.D. 7.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 header field to indicate what version of the MIME protocol was used to construct the message.4461 <h3 id="rfc.section.D.6.1"><a href="#rfc.section.D.6.1">D.6.1</a> <a id="mime-version" href="#mime-version">MIME-Version</a></h3> 4462 <p id="rfc.section.D.6.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 header field to indicate what version of the MIME protocol was used to construct the message. 4466 4463 Use of the MIME-Version header field indicates that the message is in full conformance with the MIME protocol (as defined 4467 4464 in <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 conformance (where possible) when exporting HTTP messages to strict … … 4469 4466 </p> 4470 4467 <div id="rfc.figure.u.65"></div><pre class="inline"><span id="rfc.iref.g.59"></span> <a href="#mime-version" class="smpl">MIME-Version</a> = 1*<a href="#notation" class="smpl">DIGIT</a> "." 1*<a href="#notation" class="smpl">DIGIT</a> 4471 </pre><p id="rfc.section.D. 7.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 this4468 </pre><p id="rfc.section.D.6.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 4472 4469 document and not the MIME specification. 4473 4470 </p> 4474 <h3 id="rfc.section.D. 7.2"><a href="#rfc.section.D.7.2">D.7.2</a> <a id="conversion.to.canonical.form" href="#conversion.to.canonical.form">Conversion to Canonical Form</a></h3>4475 <p id="rfc.section.D. 7.2.p.1">MIME requires that an Internet mail body-part be converted to canonical form prior to being transferred, as described in <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 6.5.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.4"><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 line4471 <h3 id="rfc.section.D.6.2"><a href="#rfc.section.D.6.2">D.6.2</a> <a id="conversion.to.canonical.form" href="#conversion.to.canonical.form">Conversion to Canonical Form</a></h3> 4472 <p id="rfc.section.D.6.2.p.1">MIME requires that an Internet mail body-part be converted to canonical form prior to being transferred, as described in <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 6.5.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.4"><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 4476 4473 break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a line break within text content when a message is transmitted 4477 4474 over HTTP. 4478 4475 </p> 4479 <p id="rfc.section.D. 7.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 6.5.1</a> of this document to the RFC 2049 canonical form of CRLF. Note, however, that this might be complicated by the presence of4476 <p id="rfc.section.D.6.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 6.5.1</a> of this document to the RFC 2049 canonical form of CRLF. Note, however, that this might be complicated by the presence of 4480 4477 a Content-Encoding and by the fact that HTTP allows the use of some character encodings which do not use octets 13 and 10 4481 4478 to represent CR and LF, respectively, as is the case for some multi-byte character encodings. 4482 4479 </p> 4483 <p id="rfc.section.D. 7.2.p.3">Conversion will break any cryptographic checksums applied to the original content unless the original content is already in4480 <p id="rfc.section.D.6.2.p.3">Conversion will break any cryptographic checksums applied to the original content unless the original content is already in 4484 4481 canonical form. Therefore, the canonical form is recommended for any content that uses such checksums in HTTP. 4485 4482 </p> 4486 <h3 id="rfc.section.D. 7.3"><a href="#rfc.section.D.7.3">D.7.3</a> <a id="conversion.of.date.formats" href="#conversion.of.date.formats">Conversion of Date Formats</a></h3>4487 <p id="rfc.section.D. 7.3.p.1">HTTP/1.1 uses a restricted set of date formats (<a href="#http.date" title="Date/Time Formats">Section 6.1</a>) to simplify the process of date comparison. Proxies and gateways from other protocols <em class="bcp14">SHOULD</em> ensure that any Date header field present in a message conforms to one of the HTTP/1.1 formats and rewrite the date if necessary.4488 </p> 4489 <h3 id="rfc.section.D. 7.4"><a href="#rfc.section.D.7.4">D.7.4</a> <a id="introduction.of.content-encoding" href="#introduction.of.content-encoding">Introduction of Content-Encoding</a></h3>4490 <p id="rfc.section.D. 7.4.p.1">MIME does not include any concept equivalent to HTTP/1.1's Content-Encoding header field. Since this acts as a modifier on4483 <h3 id="rfc.section.D.6.3"><a href="#rfc.section.D.6.3">D.6.3</a> <a id="conversion.of.date.formats" href="#conversion.of.date.formats">Conversion of Date Formats</a></h3> 4484 <p id="rfc.section.D.6.3.p.1">HTTP/1.1 uses a restricted set of date formats (<a href="#http.date" title="Date/Time Formats">Section 6.1</a>) to simplify the process of date comparison. Proxies and gateways from other protocols <em class="bcp14">SHOULD</em> ensure that any Date header field present in a message conforms to one of the HTTP/1.1 formats and rewrite the date if necessary. 4485 </p> 4486 <h3 id="rfc.section.D.6.4"><a href="#rfc.section.D.6.4">D.6.4</a> <a id="introduction.of.content-encoding" href="#introduction.of.content-encoding">Introduction of Content-Encoding</a></h3> 4487 <p id="rfc.section.D.6.4.p.1">MIME does not include any concept equivalent to HTTP/1.1's Content-Encoding header field. Since this acts as a modifier on 4491 4488 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 representation before forwarding the message. (Some 4492 4489 experimental applications of Content-Type for Internet mail have used a media-type parameter of ";conversions=<content-coding>" … … 4495 4492 <div id="rfc.iref.c.11"></div> 4496 4493 <div id="rfc.iref.h.21"></div> 4497 <h3 id="rfc.section.D. 7.5"><a href="#rfc.section.D.7.5">D.7.5</a> <a id="no.content-transfer-encoding" href="#no.content-transfer-encoding">No Content-Transfer-Encoding</a></h3>4498 <p id="rfc.section.D. 7.5.p.1">HTTP does not use the Content-Transfer-Encoding field of MIME. 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.4499 </p> 4500 <p id="rfc.section.D. 7.5.p.2">Proxies and gateways from HTTP to MIME-compliant protocols are responsible for ensuring that the message is in the correct4494 <h3 id="rfc.section.D.6.5"><a href="#rfc.section.D.6.5">D.6.5</a> <a id="no.content-transfer-encoding" href="#no.content-transfer-encoding">No Content-Transfer-Encoding</a></h3> 4495 <p id="rfc.section.D.6.5.p.1">HTTP does not use the Content-Transfer-Encoding field of MIME. 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. 4496 </p> 4497 <p id="rfc.section.D.6.5.p.2">Proxies and gateways from HTTP to MIME-compliant protocols are responsible for ensuring that the message is in the correct 4501 4498 format and encoding for safe transport on that protocol, where "safe transport" is defined by the limitations of the protocol 4502 4499 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 4503 4500 the destination protocol. 4504 4501 </p> 4505 <h3 id="rfc.section.D. 7.6"><a href="#rfc.section.D.7.6">D.7.6</a> <a id="introduction.of.transfer-encoding" href="#introduction.of.transfer-encoding">Introduction of Transfer-Encoding</a></h3>4506 <p id="rfc.section.D. 7.6.p.1">HTTP/1.1 introduces the Transfer-Encoding header field (<a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 3.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.59"><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.4507 </p> 4508 <h3 id="rfc.section.D. 7.7"><a href="#rfc.section.D.7.7">D.7.7</a> <a id="mhtml.line.length" href="#mhtml.line.length">MHTML and Line Length Limitations</a></h3>4509 <p id="rfc.section.D. 7.7.p.1">HTTP implementations which share code with MHTML <a href="#RFC2557" id="rfc.xref.RFC2557.2"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a> implementations need to be aware of MIME line length limitations. Since HTTP does not have this limitation, HTTP does not4502 <h3 id="rfc.section.D.6.6"><a href="#rfc.section.D.6.6">D.6.6</a> <a id="introduction.of.transfer-encoding" href="#introduction.of.transfer-encoding">Introduction of Transfer-Encoding</a></h3> 4503 <p id="rfc.section.D.6.6.p.1">HTTP/1.1 introduces the Transfer-Encoding header field (<a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 3.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.59"><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. 4504 </p> 4505 <h3 id="rfc.section.D.6.7"><a href="#rfc.section.D.6.7">D.6.7</a> <a id="mhtml.line.length" href="#mhtml.line.length">MHTML and Line Length Limitations</a></h3> 4506 <p id="rfc.section.D.6.7.p.1">HTTP implementations which share code with MHTML <a href="#RFC2557" id="rfc.xref.RFC2557.2"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a> implementations need to be aware of MIME line length limitations. Since HTTP does not have this limitation, HTTP does not 4510 4507 fold long lines. MHTML messages being transported by HTTP follow all conventions of MHTML, including line length limitations 4511 4508 and folding, canonicalization, etc., since HTTP transports all message-bodies as payload (see <a href="#multipart.types" title="Multipart Types">Section 6.5.2</a>) and does not interpret the content or any MIME header lines that might be contained therein. 4512 4509 </p> 4513 <h2 id="rfc.section.D. 8"><a href="#rfc.section.D.8">D.8</a> <a id="additional.features" href="#additional.features">Additional Features</a></h2>4514 <p id="rfc.section.D. 8.p.1"> <a href="#RFC1945" id="rfc.xref.RFC1945.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a> and <a href="#RFC2068" id="rfc.xref.RFC2068.3"><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.14510 <h2 id="rfc.section.D.7"><a href="#rfc.section.D.7">D.7</a> <a id="additional.features" href="#additional.features">Additional Features</a></h2> 4511 <p id="rfc.section.D.7.p.1"> <a href="#RFC1945" id="rfc.xref.RFC1945.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a> and <a href="#RFC2068" id="rfc.xref.RFC2068.3"><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 4515 4512 applications. Implementors are advised to be aware of these features, but cannot rely upon their presence in, or interoperability 4516 4513 with, other HTTP/1.1 applications. Some of these describe proposed experimental features, and some describe features that 4517 4514 experimental deployment found lacking that are now addressed in the base HTTP/1.1 specification. 4518 4515 </p> 4519 <p id="rfc.section.D. 8.p.2">A number of other header fields, such as Content-Disposition and Title, from SMTP and MIME are also often implemented (see <a href="#RFC6266" id="rfc.xref.RFC6266.1"><cite title="Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)">[RFC6266]</cite></a> and <a href="#RFC2076" id="rfc.xref.RFC2076.1"><cite title="Common Internet Message Headers">[RFC2076]</cite></a>).4520 </p> 4521 <h2 id="rfc.section.D. 9"><a href="#rfc.section.D.9">D.9</a> <a id="changes.from.rfc.2616-3" href="#changes.from.rfc.2616-3">Changes from RFC 2616</a></h2>4522 <p id="rfc.section.D. 9.p.1">Clarify contexts that charset is used in. (<a href="#character.sets" title="Character Encodings (charset)">Section 6.3</a>)4523 </p> 4524 <p id="rfc.section.D. 9.p.2">Registration of Content Codings now requires IETF Review (<a href="#content.coding.registry" title="Content Coding Registry">Section 6.4.1</a>)4525 </p> 4526 <p id="rfc.section.D. 9.p.3">Remove the default character encoding for text media types; the default now is whatever the media type definition says. (<a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section 6.5.1</a>)4527 </p> 4528 <p id="rfc.section.D. 9.p.4">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section 7</a>)4529 </p> 4530 <p id="rfc.section.D. 9.p.5">Remove definition of Content-MD5 header field because it was inconsistently implemented with respect to partial responses,4516 <p id="rfc.section.D.7.p.2">A number of other header fields, such as Content-Disposition and Title, from SMTP and MIME are also often implemented (see <a href="#RFC6266" id="rfc.xref.RFC6266.1"><cite title="Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)">[RFC6266]</cite></a> and <a href="#RFC2076" id="rfc.xref.RFC2076.1"><cite title="Common Internet Message Headers">[RFC2076]</cite></a>). 4517 </p> 4518 <h2 id="rfc.section.D.8"><a href="#rfc.section.D.8">D.8</a> <a id="changes.from.rfc.2616-3" href="#changes.from.rfc.2616-3">Changes from RFC 2616</a></h2> 4519 <p id="rfc.section.D.8.p.1">Clarify contexts that charset is used in. (<a href="#character.sets" title="Character Encodings (charset)">Section 6.3</a>) 4520 </p> 4521 <p id="rfc.section.D.8.p.2">Registration of Content Codings now requires IETF Review (<a href="#content.coding.registry" title="Content Coding Registry">Section 6.4.1</a>) 4522 </p> 4523 <p id="rfc.section.D.8.p.3">Remove the default character encoding for text media types; the default now is whatever the media type definition says. (<a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section 6.5.1</a>) 4524 </p> 4525 <p id="rfc.section.D.8.p.4">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section 7</a>) 4526 </p> 4527 <p id="rfc.section.D.8.p.5">Remove definition of Content-MD5 header field because it was inconsistently implemented with respect to partial responses, 4531 4528 and also because of known deficiencies in the hash algorithm itself (see <a href="#RFC6151" id="rfc.xref.RFC6151.1"><cite title="Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms">[RFC6151]</cite></a> for details). (<a href="#header.field.definitions" title="Header Field Definitions">Section 7</a>) 4532 4529 </p> 4533 <p id="rfc.section.D. 9.p.6">Remove ISO-8859-1 special-casing in Accept-Charset. (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.4" title="Accept-Charset">Appendix D.4.2</a>)4534 </p> 4535 <p id="rfc.section.D. 9.p.7">Remove base URI setting semantics for Content-Location due to poor implementation support, which was caused by too many broken4530 <p id="rfc.section.D.8.p.6">Remove ISO-8859-1 special-casing in Accept-Charset. (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.4" title="Accept-Charset">Section 7.2</a>) 4531 </p> 4532 <p id="rfc.section.D.8.p.7">Remove base URI setting semantics for Content-Location due to poor implementation support, which was caused by too many broken 4536 4533 servers emitting bogus Content-Location header fields, and also the potentially undesirable effect of potentially breaking 4537 relative links in content-negotiated resources. (<a href="#header.content-location" id="rfc.xref.header.content-location.5" title="Content-Location"> Appendix D.4.7</a>)4538 </p> 4539 <p id="rfc.section.D. 9.p.8">Remove reference to non-existant identity transfer-coding value tokens. (<a href="#no.content-transfer-encoding" id="rfc.xref.no.content-transfer-encoding.1" title="No Content-Transfer-Encoding">Appendix D.7.5</a>)4540 </p> 4541 <p id="rfc.section.D. 9.p.9">Remove discussion of Content-Disposition header field, it is now defined by <a href="#RFC6266" id="rfc.xref.RFC6266.2"><cite title="Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)">[RFC6266]</cite></a>. (<a href="#additional.features" title="Additional Features">Appendix D.8</a>)4542 </p> 4543 <h2 id="rfc.section.D. 10"><a href="#rfc.section.D.10">D.10</a> <a id="change.log3" href="#change.log3">Change Log (to be removed by RFC Editor before publication)</a></h2>4544 <h3 id="rfc.section.D. 10.1"><a href="#rfc.section.D.10.1">D.10.1</a> Since RFC 26164534 relative links in content-negotiated resources. (<a href="#header.content-location" id="rfc.xref.header.content-location.5" title="Content-Location">Section 7.8</a>) 4535 </p> 4536 <p id="rfc.section.D.8.p.8">Remove reference to non-existant identity transfer-coding value tokens. (<a href="#no.content-transfer-encoding" id="rfc.xref.no.content-transfer-encoding.1" title="No Content-Transfer-Encoding">Appendix D.6.5</a>) 4537 </p> 4538 <p id="rfc.section.D.8.p.9">Remove discussion of Content-Disposition header field, it is now defined by <a href="#RFC6266" id="rfc.xref.RFC6266.2"><cite title="Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)">[RFC6266]</cite></a>. (<a href="#additional.features" title="Additional Features">Appendix D.7</a>) 4539 </p> 4540 <h2 id="rfc.section.D.9"><a href="#rfc.section.D.9">D.9</a> <a id="change.log3" href="#change.log3">Change Log (to be removed by RFC Editor before publication)</a></h2> 4541 <h3 id="rfc.section.D.9.1"><a href="#rfc.section.D.9.1">D.9.1</a> Since RFC 2616 4545 4542 </h3> 4546 <p id="rfc.section.D. 10.1.p.1">Extracted relevant partitions from <a href="#RFC2616" id="rfc.xref.RFC2616.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.4547 </p> 4548 <h3 id="rfc.section.D. 10.2"><a href="#rfc.section.D.10.2">D.10.2</a> Since draft-ietf-httpbis-p3-payload-004543 <p id="rfc.section.D.9.1.p.1">Extracted relevant partitions from <a href="#RFC2616" id="rfc.xref.RFC2616.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. 4544 </p> 4545 <h3 id="rfc.section.D.9.2"><a href="#rfc.section.D.9.2">D.9.2</a> Since draft-ietf-httpbis-p3-payload-00 4549 4546 </h3> 4550 <p id="rfc.section.D. 10.2.p.1">Closed issues: </p>4547 <p id="rfc.section.D.9.2.p.1">Closed issues: </p> 4551 4548 <ul> 4552 4549 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/8">http://tools.ietf.org/wg/httpbis/trac/ticket/8</a>>: "Media Type Registrations" (<<a href="http://purl.org/NET/http-errata#media-reg">http://purl.org/NET/http-errata#media-reg</a>>) … … 4573 4570 </li> 4574 4571 </ul> 4575 <h3 id="rfc.section.D. 10.3"><a href="#rfc.section.D.10.3">D.10.3</a> Since draft-ietf-httpbis-p3-payload-014572 <h3 id="rfc.section.D.9.3"><a href="#rfc.section.D.9.3">D.9.3</a> Since draft-ietf-httpbis-p3-payload-01 4576 4573 </h3> 4577 <p id="rfc.section.D. 10.3.p.1">Ongoing work on ABNF conversion (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>>):4574 <p id="rfc.section.D.9.3.p.1">Ongoing work on ABNF conversion (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>>): 4578 4575 </p> 4579 4576 <ul> 4580 4577 <li>Add explicit references to BNF syntax and rules imported from other parts of the specification.</li> 4581 4578 </ul> 4582 <h3 id="rfc.section.D. 10.4"><a href="#rfc.section.D.10.4">D.10.4</a> <a id="changes.3.since.02" href="#changes.3.since.02">Since draft-ietf-httpbis-p3-payload-02</a></h3>4583 <p id="rfc.section.D. 10.4.p.1">Closed issues: </p>4579 <h3 id="rfc.section.D.9.4"><a href="#rfc.section.D.9.4">D.9.4</a> <a id="changes.3.since.02" href="#changes.3.since.02">Since draft-ietf-httpbis-p3-payload-02</a></h3> 4580 <p id="rfc.section.D.9.4.p.1">Closed issues: </p> 4584 4581 <ul> 4585 4582 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/67">http://tools.ietf.org/wg/httpbis/trac/ticket/67</a>>: "Quoting Charsets" … … 4590 4587 </li> 4591 4588 </ul> 4592 <p id="rfc.section.D. 10.4.p.2">Ongoing work on IANA Message Header Field Registration (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>>):4589 <p id="rfc.section.D.9.4.p.2">Ongoing work on IANA Message Header Field Registration (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>>): 4593 4590 </p> 4594 4591 <ul> 4595 4592 <li>Reference RFC 3984, and update header field registrations for headers defined in this document.</li> 4596 4593 </ul> 4597 <h3 id="rfc.section.D. 10.5"><a href="#rfc.section.D.10.5">D.10.5</a> <a id="changes.3.since.03" href="#changes.3.since.03">Since draft-ietf-httpbis-p3-payload-03</a></h3>4598 <p id="rfc.section.D. 10.5.p.1">Closed issues: </p>4594 <h3 id="rfc.section.D.9.5"><a href="#rfc.section.D.9.5">D.9.5</a> <a id="changes.3.since.03" href="#changes.3.since.03">Since draft-ietf-httpbis-p3-payload-03</a></h3> 4595 <p id="rfc.section.D.9.5.p.1">Closed issues: </p> 4599 4596 <ul> 4600 4597 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/67">http://tools.ietf.org/wg/httpbis/trac/ticket/67</a>>: "Quoting Charsets" … … 4605 4602 </li> 4606 4603 </ul> 4607 <p id="rfc.section.D. 10.5.p.2">Other changes: </p>4604 <p id="rfc.section.D.9.5.p.2">Other changes: </p> 4608 4605 <ul> 4609 4606 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/68">http://tools.ietf.org/wg/httpbis/trac/ticket/68</a>>: "Encoding References Normative" — rephrase the annotation and reference BCP97. 4610 4607 </li> 4611 4608 </ul> 4612 <h3 id="rfc.section.D. 10.6"><a href="#rfc.section.D.10.6">D.10.6</a> <a id="changes.3.since.04" href="#changes.3.since.04">Since draft-ietf-httpbis-p3-payload-04</a></h3>4613 <p id="rfc.section.D. 10.6.p.1">Closed issues: </p>4609 <h3 id="rfc.section.D.9.6"><a href="#rfc.section.D.9.6">D.9.6</a> <a id="changes.3.since.04" href="#changes.3.since.04">Since draft-ietf-httpbis-p3-payload-04</a></h3> 4610 <p id="rfc.section.D.9.6.p.1">Closed issues: </p> 4614 4611 <ul> 4615 4612 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/132">http://tools.ietf.org/wg/httpbis/trac/ticket/132</a>>: "RFC 2822 is updated by RFC 5322" 4616 4613 </li> 4617 4614 </ul> 4618 <p id="rfc.section.D. 10.6.p.2">Ongoing work on ABNF conversion (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>>):4615 <p id="rfc.section.D.9.6.p.2">Ongoing work on ABNF conversion (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>>): 4619 4616 </p> 4620 4617 <ul> … … 4623 4620 <li>Rewrite ABNFs to spell out whitespace rules, factor out header field value format definitions.</li> 4624 4621 </ul> 4625 <h3 id="rfc.section.D. 10.7"><a href="#rfc.section.D.10.7">D.10.7</a> <a id="changes.3.since.05" href="#changes.3.since.05">Since draft-ietf-httpbis-p3-payload-05</a></h3>4626 <p id="rfc.section.D. 10.7.p.1">Closed issues: </p>4622 <h3 id="rfc.section.D.9.7"><a href="#rfc.section.D.9.7">D.9.7</a> <a id="changes.3.since.05" href="#changes.3.since.05">Since draft-ietf-httpbis-p3-payload-05</a></h3> 4623 <p id="rfc.section.D.9.7.p.1">Closed issues: </p> 4627 4624 <ul> 4628 4625 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/118">http://tools.ietf.org/wg/httpbis/trac/ticket/118</a>>: "Join "Differences Between HTTP Entities and RFC 2045 Entities"?" 4629 4626 </li> 4630 4627 </ul> 4631 <p id="rfc.section.D. 10.7.p.2">Final work on ABNF conversion (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>>):4628 <p id="rfc.section.D.9.7.p.2">Final work on ABNF conversion (<<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>>): 4632 4629 </p> 4633 4630 <ul> 4634 4631 <li>Add appendix containing collected and expanded ABNF, reorganize ABNF introduction.</li> 4635 4632 </ul> 4636 <p id="rfc.section.D. 10.7.p.3">Other changes: </p>4633 <p id="rfc.section.D.9.7.p.3">Other changes: </p> 4637 4634 <ul> 4638 4635 <li>Move definition of quality values into Part 1.</li> 4639 4636 </ul> 4640 <h3 id="rfc.section.D. 10.8"><a href="#rfc.section.D.10.8">D.10.8</a> <a id="changes.3.since.06" href="#changes.3.since.06">Since draft-ietf-httpbis-p3-payload-06</a></h3>4641 <p id="rfc.section.D. 10.8.p.1">Closed issues: </p>4637 <h3 id="rfc.section.D.9.8"><a href="#rfc.section.D.9.8">D.9.8</a> <a id="changes.3.since.06" href="#changes.3.since.06">Since draft-ietf-httpbis-p3-payload-06</a></h3> 4638 <p id="rfc.section.D.9.8.p.1">Closed issues: </p> 4642 4639 <ul> 4643 4640 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/80">http://tools.ietf.org/wg/httpbis/trac/ticket/80</a>>: "Content-Location isn't special" … … 4646 4643 </li> 4647 4644 </ul> 4648 <h3 id="rfc.section.D. 10.9"><a href="#rfc.section.D.10.9">D.10.9</a> <a id="changes.3.since.07" href="#changes.3.since.07">Since draft-ietf-httpbis-p3-payload-07</a></h3>4649 <p id="rfc.section.D. 10.9.p.1">Closed issues: </p>4645 <h3 id="rfc.section.D.9.9"><a href="#rfc.section.D.9.9">D.9.9</a> <a id="changes.3.since.07" href="#changes.3.since.07">Since draft-ietf-httpbis-p3-payload-07</a></h3> 4646 <p id="rfc.section.D.9.9.p.1">Closed issues: </p> 4650 4647 <ul> 4651 4648 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/13">http://tools.ietf.org/wg/httpbis/trac/ticket/13</a>>: "Updated reference for language tags" … … 4662 4659 </li> 4663 4660 </ul> 4664 <p id="rfc.section.D. 10.9.p.2">Partly resolved issues: </p>4661 <p id="rfc.section.D.9.9.p.2">Partly resolved issues: </p> 4665 4662 <ul> 4666 4663 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/148">http://tools.ietf.org/wg/httpbis/trac/ticket/148</a>>: "update IANA requirements wrt Transfer-Coding values" (add the IANA Considerations subsection) … … 4669 4666 </li> 4670 4667 </ul> 4671 <h3 id="rfc.section.D. 10.10"><a href="#rfc.section.D.10.10">D.10.10</a> <a id="changes.3.since.08" href="#changes.3.since.08">Since draft-ietf-httpbis-p3-payload-08</a></h3>4672 <p id="rfc.section.D. 10.10.p.1">Closed issues: </p>4668 <h3 id="rfc.section.D.9.10"><a href="#rfc.section.D.9.10">D.9.10</a> <a id="changes.3.since.08" href="#changes.3.since.08">Since draft-ietf-httpbis-p3-payload-08</a></h3> 4669 <p id="rfc.section.D.9.10.p.1">Closed issues: </p> 4673 4670 <ul> 4674 4671 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/81">http://tools.ietf.org/wg/httpbis/trac/ticket/81</a>>: "Content Negotiation for media types" … … 4677 4674 </li> 4678 4675 </ul> 4679 <h3 id="rfc.section.D. 10.11"><a href="#rfc.section.D.10.11">D.10.11</a> <a id="changes.3.since.09" href="#changes.3.since.09">Since draft-ietf-httpbis-p3-payload-09</a></h3>4680 <p id="rfc.section.D. 10.11.p.1">Closed issues: </p>4676 <h3 id="rfc.section.D.9.11"><a href="#rfc.section.D.9.11">D.9.11</a> <a id="changes.3.since.09" href="#changes.3.since.09">Since draft-ietf-httpbis-p3-payload-09</a></h3> 4677 <p id="rfc.section.D.9.11.p.1">Closed issues: </p> 4681 4678 <ul> 4682 4679 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/122">http://tools.ietf.org/wg/httpbis/trac/ticket/122</a>>: "MIME-Version not listed in P1, general header fields" … … 4689 4686 </li> 4690 4687 </ul> 4691 <p id="rfc.section.D. 10.11.p.2">Partly resolved issues: </p>4688 <p id="rfc.section.D.9.11.p.2">Partly resolved issues: </p> 4692 4689 <ul> 4693 4690 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/196">http://tools.ietf.org/wg/httpbis/trac/ticket/196</a>>: "Term for the requested resource's URI" 4694 4691 </li> 4695 4692 </ul> 4696 <h3 id="rfc.section.D. 10.12"><a href="#rfc.section.D.10.12">D.10.12</a> <a id="changes.3.since.10" href="#changes.3.since.10">Since draft-ietf-httpbis-p3-payload-10</a></h3>4697 <p id="rfc.section.D. 10.12.p.1">Closed issues: </p>4693 <h3 id="rfc.section.D.9.12"><a href="#rfc.section.D.9.12">D.9.12</a> <a id="changes.3.since.10" href="#changes.3.since.10">Since draft-ietf-httpbis-p3-payload-10</a></h3> 4694 <p id="rfc.section.D.9.12.p.1">Closed issues: </p> 4698 4695 <ul> 4699 4696 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/69">http://tools.ietf.org/wg/httpbis/trac/ticket/69</a>>: "Clarify 'Requested Variant'" … … 4714 4711 </li> 4715 4712 </ul> 4716 <p id="rfc.section.D. 10.12.p.2">Partly resolved issues: </p>4713 <p id="rfc.section.D.9.12.p.2">Partly resolved issues: </p> 4717 4714 <ul> 4718 4715 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/178">http://tools.ietf.org/wg/httpbis/trac/ticket/178</a>>: "Content-MD5 and partial responses" 4719 4716 </li> 4720 4717 </ul> 4721 <h3 id="rfc.section.D. 10.13"><a href="#rfc.section.D.10.13">D.10.13</a> <a id="changes.3.since.11" href="#changes.3.since.11">Since draft-ietf-httpbis-p3-payload-11</a></h3>4722 <p id="rfc.section.D. 10.13.p.1">Closed issues: </p>4718 <h3 id="rfc.section.D.9.13"><a href="#rfc.section.D.9.13">D.9.13</a> <a id="changes.3.since.11" href="#changes.3.since.11">Since draft-ietf-httpbis-p3-payload-11</a></h3> 4719 <p id="rfc.section.D.9.13.p.1">Closed issues: </p> 4723 4720 <ul> 4724 4721 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/123">http://tools.ietf.org/wg/httpbis/trac/ticket/123</a>>: "Factor out Content-Disposition" 4725 4722 </li> 4726 4723 </ul> 4727 <h3 id="rfc.section.D. 10.14"><a href="#rfc.section.D.10.14">D.10.14</a> <a id="changes.3.since.12" href="#changes.3.since.12">Since draft-ietf-httpbis-p3-payload-12</a></h3>4728 <p id="rfc.section.D. 10.14.p.1">Closed issues: </p>4724 <h3 id="rfc.section.D.9.14"><a href="#rfc.section.D.9.14">D.9.14</a> <a id="changes.3.since.12" href="#changes.3.since.12">Since draft-ietf-httpbis-p3-payload-12</a></h3> 4725 <p id="rfc.section.D.9.14.p.1">Closed issues: </p> 4729 4726 <ul> 4730 4727 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/224">http://tools.ietf.org/wg/httpbis/trac/ticket/224</a>>: "Header Classification" … … 4735 4732 </li> 4736 4733 </ul> 4737 <h3 id="rfc.section.D. 10.15"><a href="#rfc.section.D.10.15">D.10.15</a> <a id="changes.3.since.13" href="#changes.3.since.13">Since draft-ietf-httpbis-p3-payload-13</a></h3>4738 <p id="rfc.section.D. 10.15.p.1">Closed issues: </p>4734 <h3 id="rfc.section.D.9.15"><a href="#rfc.section.D.9.15">D.9.15</a> <a id="changes.3.since.13" href="#changes.3.since.13">Since draft-ietf-httpbis-p3-payload-13</a></h3> 4735 <p id="rfc.section.D.9.15.p.1">Closed issues: </p> 4739 4736 <ul> 4740 4737 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/20">http://tools.ietf.org/wg/httpbis/trac/ticket/20</a>>: "Default charsets for text media types" … … 4747 4744 </li> 4748 4745 </ul> 4749 <h3 id="rfc.section.D. 10.16"><a href="#rfc.section.D.10.16">D.10.16</a> <a id="changes.3.since.14" href="#changes.3.since.14">Since draft-ietf-httpbis-p3-payload-14</a></h3>4750 <p id="rfc.section.D. 10.16.p.1">None.</p>4751 <h3 id="rfc.section.D. 10.17"><a href="#rfc.section.D.10.17">D.10.17</a> <a id="changes.3.since.15" href="#changes.3.since.15">Since draft-ietf-httpbis-p3-payload-15</a></h3>4752 <p id="rfc.section.D. 10.17.p.1">Closed issues: </p>4746 <h3 id="rfc.section.D.9.16"><a href="#rfc.section.D.9.16">D.9.16</a> <a id="changes.3.since.14" href="#changes.3.since.14">Since draft-ietf-httpbis-p3-payload-14</a></h3> 4747 <p id="rfc.section.D.9.16.p.1">None.</p> 4748 <h3 id="rfc.section.D.9.17"><a href="#rfc.section.D.9.17">D.9.17</a> <a id="changes.3.since.15" href="#changes.3.since.15">Since draft-ietf-httpbis-p3-payload-15</a></h3> 4749 <p id="rfc.section.D.9.17.p.1">Closed issues: </p> 4753 4750 <ul> 4754 4751 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/285">http://tools.ietf.org/wg/httpbis/trac/ticket/285</a>>: "Strength of requirements on Accept re: 406" 4755 4752 </li> 4756 4753 </ul> 4757 <h3 id="rfc.section.D. 10.18"><a href="#rfc.section.D.10.18">D.10.18</a> <a id="changes.3.since.16" href="#changes.3.since.16">Since draft-ietf-httpbis-p3-payload-16</a></h3>4758 <p id="rfc.section.D. 10.18.p.1">Closed issues: </p>4754 <h3 id="rfc.section.D.9.18"><a href="#rfc.section.D.9.18">D.9.18</a> <a id="changes.3.since.16" href="#changes.3.since.16">Since draft-ietf-httpbis-p3-payload-16</a></h3> 4755 <p id="rfc.section.D.9.18.p.1">Closed issues: </p> 4759 4756 <ul> 4760 4757 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/186">http://tools.ietf.org/wg/httpbis/trac/ticket/186</a>>: "Document HTTP's error-handling philosophy" 4761 4758 </li> 4762 4759 </ul> 4763 <h3 id="rfc.section.D. 10.19"><a href="#rfc.section.D.10.19">D.10.19</a> <a id="changes.3.since.17" href="#changes.3.since.17">Since draft-ietf-httpbis-p3-payload-17</a></h3>4764 <p id="rfc.section.D. 10.19.p.1">Closed issues: </p>4760 <h3 id="rfc.section.D.9.19"><a href="#rfc.section.D.9.19">D.9.19</a> <a id="changes.3.since.17" href="#changes.3.since.17">Since draft-ietf-httpbis-p3-payload-17</a></h3> 4761 <p id="rfc.section.D.9.19.p.1">Closed issues: </p> 4765 4762 <ul> 4766 4763 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/323">http://tools.ietf.org/wg/httpbis/trac/ticket/323</a>>: "intended maturity level vs normative references" 4767 4764 </li> 4768 4765 </ul> 4769 <h3 id="rfc.section.D. 10.20"><a href="#rfc.section.D.10.20">D.10.20</a> <a id="changes.3.since.18" href="#changes.3.since.18">Since draft-ietf-httpbis-p3-payload-18</a></h3>4770 <p id="rfc.section.D. 10.20.p.1">Closed issues: </p>4766 <h3 id="rfc.section.D.9.20"><a href="#rfc.section.D.9.20">D.9.20</a> <a id="changes.3.since.18" href="#changes.3.since.18">Since draft-ietf-httpbis-p3-payload-18</a></h3> 4767 <p id="rfc.section.D.9.20.p.1">Closed issues: </p> 4771 4768 <ul> 4772 4769 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/330">http://tools.ietf.org/wg/httpbis/trac/ticket/330</a>>: "is ETag a representation header field?" … … 4777 4774 </li> 4778 4775 </ul> 4779 <h3 id="rfc.section.D. 10.21"><a href="#rfc.section.D.10.21">D.10.21</a> <a id="changes.3.since.19" href="#changes.3.since.19">Since draft-ietf-httpbis-p3-payload-19</a></h3>4780 <p id="rfc.section.D. 10.21.p.1">None yet.</p>4776 <h3 id="rfc.section.D.9.21"><a href="#rfc.section.D.9.21">D.9.21</a> <a id="changes.3.since.19" href="#changes.3.since.19">Since draft-ietf-httpbis-p3-payload-19</a></h3> 4777 <p id="rfc.section.D.9.21.p.1">None yet.</p> 4781 4778 <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> 4782 4779 <p class="noprint"><a href="#rfc.index.1">1</a> <a href="#rfc.index.2">2</a> <a href="#rfc.index.3">3</a> <a href="#rfc.index.4">4</a> <a href="#rfc.index.5">5</a> <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.E">E</a> <a href="#rfc.index.F">F</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.M">M</a> <a href="#rfc.index.O">O</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.T">T</a> <a href="#rfc.index.U">U</a> … … 4786 4783 <li><a id="rfc.index.1" href="#rfc.index.1"><b>1</b></a><ul> 4787 4784 <li>100 Continue (status code) <a href="#rfc.xref.status.100.1">4.1</a>, <a href="#rfc.iref.21"><b>4.3.1</b></a>, <a href="#rfc.xref.status.100.2">8.2</a></li> 4788 <li>100-continue (expect value) <a href="#rfc.iref.1 03"><b>7.3</b></a></li>4785 <li>100-continue (expect value) <a href="#rfc.iref.132"><b>7.11</b></a></li> 4789 4786 <li>101 Switching Protocols (status code) <a href="#rfc.xref.status.101.1">4.1</a>, <a href="#rfc.iref.22"><b>4.3.2</b></a>, <a href="#rfc.xref.status.101.2">8.2</a></li> 4790 4787 </ul> … … 4837 4834 </li> 4838 4835 <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul> 4839 <li>Accept header field <a href="#rfc.xref.header.accept.1">3.2</a>, <a href="#rfc.xref.header.accept.2">6.5</a>, <a href="#rfc. xref.header.accept.3">8.3</a>, <a href="#rfc.xref.header.accept.4">D.3.1</a>, <a href="#rfc.iref.a.2"><b>D.4.1</b></a></li>4840 <li>Accept-Charset header field <a href="#rfc.xref.header.accept-charset.1">3.2</a>, <a href="#rfc. xref.header.accept-charset.2">8.3</a>, <a href="#rfc.xref.header.accept-charset.3">D.3.1</a>, <a href="#rfc.iref.a.3"><b>D.4.2</b></a>, <a href="#rfc.xref.header.accept-charset.4">D.9</a></li>4841 <li>Accept-Encoding header field <a href="#rfc.xref.header.accept-encoding.1">3.2</a>, <a href="#rfc.xref.header.accept-encoding.2">6.4</a>, <a href="#rfc. xref.header.accept-encoding.3">8.3</a>, <a href="#rfc.xref.header.accept-encoding.4">D.3.1</a>, <a href="#rfc.iref.a.4"><b>D.4.3</b></a>, <a href="#rfc.xref.header.accept-encoding.5">D.5.1</a></li>4842 <li>Accept-Language header field <a href="#rfc.xref.header.accept-language.1">3.2</a>, <a href="#rfc. xref.header.accept-language.2">8.3</a>, <a href="#rfc.xref.header.accept-language.3">D.3.1</a>, <a href="#rfc.iref.a.5"><b>D.4.4</b></a></li>4843 <li>Allow header field <a href="#rfc.xref.header.allow.1">2</a>, <a href="#rfc.xref.header.allow.2">3.3</a>, <a href="#rfc.iref.a. 1"><b>7.1</b></a>, <a href="#rfc.xref.header.allow.3">8.3</a>, <a href="#rfc.xref.header.allow.4">A</a></li>4836 <li>Accept header field <a href="#rfc.xref.header.accept.1">3.2</a>, <a href="#rfc.xref.header.accept.2">6.5</a>, <a href="#rfc.iref.a.1"><b>7.1</b></a>, <a href="#rfc.xref.header.accept.3">8.3</a>, <a href="#rfc.xref.header.accept.4">D.3.1</a></li> 4837 <li>Accept-Charset header field <a href="#rfc.xref.header.accept-charset.1">3.2</a>, <a href="#rfc.iref.a.2"><b>7.2</b></a>, <a href="#rfc.xref.header.accept-charset.2">8.3</a>, <a href="#rfc.xref.header.accept-charset.3">D.3.1</a>, <a href="#rfc.xref.header.accept-charset.4">D.8</a></li> 4838 <li>Accept-Encoding header field <a href="#rfc.xref.header.accept-encoding.1">3.2</a>, <a href="#rfc.xref.header.accept-encoding.2">6.4</a>, <a href="#rfc.iref.a.3"><b>7.3</b></a>, <a href="#rfc.xref.header.accept-encoding.3">8.3</a>, <a href="#rfc.xref.header.accept-encoding.4">D.3.1</a>, <a href="#rfc.xref.header.accept-encoding.5">D.4.1</a></li> 4839 <li>Accept-Language header field <a href="#rfc.xref.header.accept-language.1">3.2</a>, <a href="#rfc.iref.a.4"><b>7.4</b></a>, <a href="#rfc.xref.header.accept-language.2">8.3</a>, <a href="#rfc.xref.header.accept-language.3">D.3.1</a></li> 4840 <li>Allow header field <a href="#rfc.xref.header.allow.1">2</a>, <a href="#rfc.xref.header.allow.2">3.3</a>, <a href="#rfc.iref.a.5"><b>7.5</b></a>, <a href="#rfc.xref.header.allow.3">8.3</a>, <a href="#rfc.xref.header.allow.4">A</a></li> 4844 4841 </ul> 4845 4842 </li> … … 4855 4852 <li>CONNECT method <a href="#rfc.iref.c.2"><b>2.3.8</b></a>, <a href="#rfc.xref.CONNECT.1">8.1</a>, <a href="#rfc.xref.CONNECT.2">A</a></li> 4856 4853 <li>content negotiation <a href="#rfc.iref.c.1">1.1</a></li> 4857 <li>Content-Encoding header field <a href="#rfc.xref.header.content-encoding.1">6.4</a>, <a href="#rfc. xref.header.content-encoding.2">8.3</a>, <a href="#rfc.xref.header.content-encoding.3">D.2.1</a>, <a href="#rfc.iref.c.7"><b>D.4.5</b></a>, <a href="#rfc.xref.header.content-encoding.4">D.4.5</a></li>4858 <li>Content-Language header field <a href="#rfc. xref.header.content-language.1">8.3</a>, <a href="#rfc.xref.header.content-language.2">D.2.1</a>, <a href="#rfc.iref.c.8"><b>D.4.6</b></a></li>4859 <li>Content-Location header field <a href="#rfc.xref.header.content-location.1">2.3.4</a>, <a href="#rfc. xref.header.content-location.2">7.5</a>, <a href="#rfc.xref.header.content-location.3">8.3</a>, <a href="#rfc.xref.header.content-location.4">D.2.1</a>, <a href="#rfc.iref.c.9"><b>D.4.7</b></a>, <a href="#rfc.xref.header.content-location.5">D.9</a></li>4860 <li>Content-Transfer-Encoding header field <a href="#rfc.iref.c.11">D. 7.5</a>, <a href="#rfc.xref.no.content-transfer-encoding.1">D.9</a></li>4861 <li>Content-Type header field <a href="#rfc.xref.header.content-type.1">3.1</a>, <a href="#rfc.xref.header.content-type.2">4</a>, <a href="#rfc.xref.header.content-type.3">6.5</a>, <a href="#rfc. xref.header.content-type.4">8.3</a>, <a href="#rfc.xref.header.content-type.5">D.2.1</a>, <a href="#rfc.iref.c.10"><b>D.4.8</b></a></li>4854 <li>Content-Encoding header field <a href="#rfc.xref.header.content-encoding.1">6.4</a>, <a href="#rfc.iref.c.7"><b>7.6</b></a>, <a href="#rfc.xref.header.content-encoding.2">7.6</a>, <a href="#rfc.xref.header.content-encoding.3">8.3</a>, <a href="#rfc.xref.header.content-encoding.4">D.2.1</a></li> 4855 <li>Content-Language header field <a href="#rfc.iref.c.8"><b>7.7</b></a>, <a href="#rfc.xref.header.content-language.1">8.3</a>, <a href="#rfc.xref.header.content-language.2">D.2.1</a></li> 4856 <li>Content-Location header field <a href="#rfc.xref.header.content-location.1">2.3.4</a>, <a href="#rfc.iref.c.9"><b>7.8</b></a>, <a href="#rfc.xref.header.content-location.2">7.13</a>, <a href="#rfc.xref.header.content-location.3">8.3</a>, <a href="#rfc.xref.header.content-location.4">D.2.1</a>, <a href="#rfc.xref.header.content-location.5">D.8</a></li> 4857 <li>Content-Transfer-Encoding header field <a href="#rfc.iref.c.11">D.6.5</a>, <a href="#rfc.xref.no.content-transfer-encoding.1">D.8</a></li> 4858 <li>Content-Type header field <a href="#rfc.xref.header.content-type.1">3.1</a>, <a href="#rfc.xref.header.content-type.2">4</a>, <a href="#rfc.xref.header.content-type.3">6.5</a>, <a href="#rfc.iref.c.10"><b>7.9</b></a>, <a href="#rfc.xref.header.content-type.4">8.3</a>, <a href="#rfc.xref.header.content-type.5">D.2.1</a></li> 4862 4859 </ul> 4863 4860 </li> 4864 4861 <li><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul> 4865 <li>Date header field <a href="#rfc.xref.header.date.1">3.3</a>, <a href="#rfc.iref.d.3"><b>7. 2</b></a>, <a href="#rfc.xref.header.date.2">8.3</a></li>4862 <li>Date header field <a href="#rfc.xref.header.date.1">3.3</a>, <a href="#rfc.iref.d.3"><b>7.10</b></a>, <a href="#rfc.xref.header.date.2">8.3</a></li> 4866 4863 <li>deflate (Coding Format) <a href="#rfc.iref.d.2">6.4</a></li> 4867 4864 <li>DELETE method <a href="#rfc.iref.d.1"><b>2.3.6</b></a>, <a href="#rfc.xref.DELETE.1">8.1</a></li> … … 4870 4867 </li> 4871 4868 <li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul> 4872 <li>Expect header field <a href="#rfc.xref.header.expect.1">3.2</a>, <a href="#rfc.xref.header.expect.2">4.6.14</a>, <a href="#rfc.iref.e.1"><b>7. 3</b></a>, <a href="#rfc.xref.header.expect.3">8.3</a>, <a href="#rfc.xref.header.expect.4">A</a></li>4869 <li>Expect header field <a href="#rfc.xref.header.expect.1">3.2</a>, <a href="#rfc.xref.header.expect.2">4.6.14</a>, <a href="#rfc.iref.e.1"><b>7.11</b></a>, <a href="#rfc.xref.header.expect.3">8.3</a>, <a href="#rfc.xref.header.expect.4">A</a></li> 4873 4870 <li>Expect Values 4874 4871 <ul> 4875 <li>100-continue <a href="#rfc.iref.e.2"><b>7. 3</b></a></li>4872 <li>100-continue <a href="#rfc.iref.e.2"><b>7.11</b></a></li> 4876 4873 </ul> 4877 4874 </li> … … 4879 4876 </li> 4880 4877 <li><a id="rfc.index.F" href="#rfc.index.F"><b>F</b></a><ul> 4881 <li>From header field <a href="#rfc.xref.header.from.1">3.2</a>, <a href="#rfc.iref.f.1"><b>7. 4</b></a>, <a href="#rfc.xref.header.from.2">8.3</a></li>4878 <li>From header field <a href="#rfc.xref.header.from.1">3.2</a>, <a href="#rfc.iref.f.1"><b>7.12</b></a>, <a href="#rfc.xref.header.from.2">8.3</a></li> 4882 4879 </ul> 4883 4880 </li> … … 4886 4883 <li><tt>Grammar</tt> 4887 4884 <ul> 4888 <li><tt>Accept</tt> <a href="#rfc.iref.g. 46"><b>D.4.1</b></a></li>4889 <li><tt>Accept-Charset</tt> <a href="#rfc.iref.g. 50"><b>D.4.2</b></a></li>4890 <li><tt>Accept-Encoding</tt> <a href="#rfc.iref.g. 51"><b>D.4.3</b></a></li>4891 <li><tt>accept-ext</tt> <a href="#rfc.iref.g. 49"><b>D.4.1</b></a></li>4892 <li><tt>Accept-Language</tt> <a href="#rfc.iref.g. 53"><b>D.4.4</b></a></li>4893 <li><tt>accept-params</tt> <a href="#rfc.iref.g. 48"><b>D.4.1</b></a></li>4894 <li><tt>Allow</tt> <a href="#rfc.iref.g. 31"><b>7.1</b></a></li>4885 <li><tt>Accept</tt> <a href="#rfc.iref.g.31"><b>7.1</b></a></li> 4886 <li><tt>Accept-Charset</tt> <a href="#rfc.iref.g.35"><b>7.2</b></a></li> 4887 <li><tt>Accept-Encoding</tt> <a href="#rfc.iref.g.36"><b>7.3</b></a></li> 4888 <li><tt>accept-ext</tt> <a href="#rfc.iref.g.34"><b>7.1</b></a></li> 4889 <li><tt>Accept-Language</tt> <a href="#rfc.iref.g.38"><b>7.4</b></a></li> 4890 <li><tt>accept-params</tt> <a href="#rfc.iref.g.33"><b>7.1</b></a></li> 4891 <li><tt>Allow</tt> <a href="#rfc.iref.g.40"><b>7.5</b></a></li> 4895 4892 <li><tt>asctime-date</tt> <a href="#rfc.iref.g.18"><b>6.1</b></a></li> 4896 4893 <li><tt>attribute</tt> <a href="#rfc.iref.g.28"><b>6.5</b></a></li> 4897 4894 <li><tt>charset</tt> <a href="#rfc.iref.g.21"><b>6.3</b></a></li> 4898 <li><tt>codings</tt> <a href="#rfc.iref.g. 52"><b>D.4.3</b></a></li>4895 <li><tt>codings</tt> <a href="#rfc.iref.g.37"><b>7.3</b></a></li> 4899 4896 <li><tt>content-coding</tt> <a href="#rfc.iref.g.22"><b>6.4</b></a></li> 4900 <li><tt>Content-Encoding</tt> <a href="#rfc.iref.g. 55"><b>D.4.5</b></a></li>4901 <li><tt>Content-Language</tt> <a href="#rfc.iref.g. 56"><b>D.4.6</b></a></li>4902 <li><tt>Content-Location</tt> <a href="#rfc.iref.g. 57"><b>D.4.7</b></a></li>4903 <li><tt>Content-Type</tt> <a href="#rfc.iref.g. 58"><b>D.4.8</b></a></li>4904 <li><tt>Date</tt> <a href="#rfc.iref.g. 32"><b>7.2</b></a></li>4897 <li><tt>Content-Encoding</tt> <a href="#rfc.iref.g.41"><b>7.6</b></a></li> 4898 <li><tt>Content-Language</tt> <a href="#rfc.iref.g.42"><b>7.7</b></a></li> 4899 <li><tt>Content-Location</tt> <a href="#rfc.iref.g.43"><b>7.8</b></a></li> 4900 <li><tt>Content-Type</tt> <a href="#rfc.iref.g.44"><b>7.9</b></a></li> 4901 <li><tt>Date</tt> <a href="#rfc.iref.g.45"><b>7.10</b></a></li> 4905 4902 <li><tt>date1</tt> <a href="#rfc.iref.g.5"><b>6.1</b></a></li> 4906 4903 <li><tt>day</tt> <a href="#rfc.iref.g.12"><b>6.1</b></a></li> 4907 4904 <li><tt>day-name</tt> <a href="#rfc.iref.g.10"><b>6.1</b></a></li> 4908 4905 <li><tt>day-name-l</tt> <a href="#rfc.iref.g.11"><b>6.1</b></a></li> 4909 <li><tt>delta-seconds</tt> <a href="#rfc.iref.g. 43"><b>7.8</b></a></li>4910 <li><tt>Expect</tt> <a href="#rfc.iref.g. 33"><b>7.3</b></a></li>4911 <li><tt>expect-name</tt> <a href="#rfc.iref.g. 37"><b>7.3</b></a></li>4912 <li><tt>expect-param</tt> <a href="#rfc.iref.g. 35"><b>7.3</b></a></li>4913 <li><tt>expect-value</tt> <a href="#rfc.iref.g. 36"><b>7.3</b></a></li>4914 <li><tt>expectation</tt> <a href="#rfc.iref.g. 34"><b>7.3</b></a></li>4915 <li><tt>From</tt> <a href="#rfc.iref.g. 38"><b>7.4</b></a></li>4906 <li><tt>delta-seconds</tt> <a href="#rfc.iref.g.56"><b>7.16</b></a></li> 4907 <li><tt>Expect</tt> <a href="#rfc.iref.g.46"><b>7.11</b></a></li> 4908 <li><tt>expect-name</tt> <a href="#rfc.iref.g.50"><b>7.11</b></a></li> 4909 <li><tt>expect-param</tt> <a href="#rfc.iref.g.48"><b>7.11</b></a></li> 4910 <li><tt>expect-value</tt> <a href="#rfc.iref.g.49"><b>7.11</b></a></li> 4911 <li><tt>expectation</tt> <a href="#rfc.iref.g.47"><b>7.11</b></a></li> 4912 <li><tt>From</tt> <a href="#rfc.iref.g.51"><b>7.12</b></a></li> 4916 4913 <li><tt>GMT</tt> <a href="#rfc.iref.g.15"><b>6.1</b></a></li> 4917 4914 <li><tt>hour</tt> <a href="#rfc.iref.g.7"><b>6.1</b></a></li> 4918 4915 <li><tt>HTTP-date</tt> <a href="#rfc.iref.g.3"><b>6.1</b></a></li> 4919 <li><tt>language-range</tt> <a href="#rfc.iref.g. 54"><b>D.4.4</b></a></li>4916 <li><tt>language-range</tt> <a href="#rfc.iref.g.39"><b>7.4</b></a></li> 4920 4917 <li><tt>language-tag</tt> <a href="#rfc.iref.g.30"><b>6.6</b></a></li> 4921 <li><tt>Location</tt> <a href="#rfc.iref.g. 39"><b>7.5</b></a></li>4922 <li><tt>Max-Forwards</tt> <a href="#rfc.iref.g. 40"><b>7.6</b></a></li>4923 <li><tt>media-range</tt> <a href="#rfc.iref.g. 47"><b>D.4.1</b></a></li>4918 <li><tt>Location</tt> <a href="#rfc.iref.g.52"><b>7.13</b></a></li> 4919 <li><tt>Max-Forwards</tt> <a href="#rfc.iref.g.53"><b>7.14</b></a></li> 4920 <li><tt>media-range</tt> <a href="#rfc.iref.g.32"><b>7.1</b></a></li> 4924 4921 <li><tt>media-type</tt> <a href="#rfc.iref.g.24"><b>6.5</b></a></li> 4925 4922 <li><tt>method</tt> <a href="#rfc.iref.g.1"><b>2</b></a></li> 4926 <li><tt>MIME-Version</tt> <a href="#rfc.iref.g.59"><b>D. 7.1</b></a></li>4923 <li><tt>MIME-Version</tt> <a href="#rfc.iref.g.59"><b>D.6.1</b></a></li> 4927 4924 <li><tt>minute</tt> <a href="#rfc.iref.g.8"><b>6.1</b></a></li> 4928 4925 <li><tt>month</tt> <a href="#rfc.iref.g.13"><b>6.1</b></a></li> … … 4931 4928 <li><tt>product</tt> <a href="#rfc.iref.g.19"><b>6.2</b></a></li> 4932 4929 <li><tt>product-version</tt> <a href="#rfc.iref.g.20"><b>6.2</b></a></li> 4933 <li><tt>Referer</tt> <a href="#rfc.iref.g. 41"><b>7.7</b></a></li>4934 <li><tt>Retry-After</tt> <a href="#rfc.iref.g. 42"><b>7.8</b></a></li>4930 <li><tt>Referer</tt> <a href="#rfc.iref.g.54"><b>7.15</b></a></li> 4931 <li><tt>Retry-After</tt> <a href="#rfc.iref.g.55"><b>7.16</b></a></li> 4935 4932 <li><tt>rfc1123-date</tt> <a href="#rfc.iref.g.4"><b>6.1</b></a></li> 4936 4933 <li><tt>rfc850-date</tt> <a href="#rfc.iref.g.17"><b>6.1</b></a></li> 4937 4934 <li><tt>second</tt> <a href="#rfc.iref.g.9"><b>6.1</b></a></li> 4938 <li><tt>Server</tt> <a href="#rfc.iref.g. 44"><b>7.9</b></a></li>4935 <li><tt>Server</tt> <a href="#rfc.iref.g.57"><b>7.17</b></a></li> 4939 4936 <li><tt>subtype</tt> <a href="#rfc.iref.g.26"><b>6.5</b></a></li> 4940 4937 <li><tt>time-of-day</tt> <a href="#rfc.iref.g.6"><b>6.1</b></a></li> 4941 4938 <li><tt>type</tt> <a href="#rfc.iref.g.25"><b>6.5</b></a></li> 4942 <li><tt>User-Agent</tt> <a href="#rfc.iref.g. 45"><b>7.10</b></a></li>4939 <li><tt>User-Agent</tt> <a href="#rfc.iref.g.58"><b>7.18</b></a></li> 4943 4940 <li><tt>value</tt> <a href="#rfc.iref.g.29"><b>6.5</b></a></li> 4944 4941 <li><tt>year</tt> <a href="#rfc.iref.g.14"><b>6.1</b></a></li> … … 4952 4949 <li>Header Fields 4953 4950 <ul> 4954 <li>Accept <a href="#rfc.xref.header.accept.1">3.2</a>, <a href="#rfc.xref.header.accept.2">6.5</a>, <a href="#rfc. xref.header.accept.3">8.3</a>, <a href="#rfc.xref.header.accept.4">D.3.1</a>, <a href="#rfc.iref.h.12"><b>D.4.1</b></a></li>4955 <li>Accept-Charset <a href="#rfc.xref.header.accept-charset.1">3.2</a>, <a href="#rfc. xref.header.accept-charset.2">8.3</a>, <a href="#rfc.xref.header.accept-charset.3">D.3.1</a>, <a href="#rfc.iref.h.13"><b>D.4.2</b></a>, <a href="#rfc.xref.header.accept-charset.4">D.9</a></li>4956 <li>Accept-Encoding <a href="#rfc.xref.header.accept-encoding.1">3.2</a>, <a href="#rfc.xref.header.accept-encoding.2">6.4</a>, <a href="#rfc. xref.header.accept-encoding.3">8.3</a>, <a href="#rfc.xref.header.accept-encoding.4">D.3.1</a>, <a href="#rfc.iref.h.14"><b>D.4.3</b></a>, <a href="#rfc.xref.header.accept-encoding.5">D.5.1</a></li>4957 <li>Accept-Language <a href="#rfc.xref.header.accept-language.1">3.2</a>, <a href="#rfc. xref.header.accept-language.2">8.3</a>, <a href="#rfc.xref.header.accept-language.3">D.3.1</a>, <a href="#rfc.iref.h.15"><b>D.4.4</b></a></li>4958 <li>Allow <a href="#rfc.xref.header.allow.1">2</a>, <a href="#rfc.xref.header.allow.2">3.3</a>, <a href="#rfc.iref.h. 2"><b>7.1</b></a>, <a href="#rfc.xref.header.allow.3">8.3</a>, <a href="#rfc.xref.header.allow.4">A</a></li>4959 <li>Content-Encoding <a href="#rfc.xref.header.content-encoding.1">6.4</a>, <a href="#rfc. xref.header.content-encoding.2">8.3</a>, <a href="#rfc.xref.header.content-encoding.3">D.2.1</a>, <a href="#rfc.iref.h.16"><b>D.4.5</b></a>, <a href="#rfc.xref.header.content-encoding.4">D.4.5</a></li>4960 <li>Content-Language <a href="#rfc. xref.header.content-language.1">8.3</a>, <a href="#rfc.xref.header.content-language.2">D.2.1</a>, <a href="#rfc.iref.h.17"><b>D.4.6</b></a></li>4961 <li>Content-Location <a href="#rfc.xref.header.content-location.1">2.3.4</a>, <a href="#rfc. xref.header.content-location.2">7.5</a>, <a href="#rfc.xref.header.content-location.3">8.3</a>, <a href="#rfc.xref.header.content-location.4">D.2.1</a>, <a href="#rfc.iref.h.18"><b>D.4.7</b></a>, <a href="#rfc.xref.header.content-location.5">D.9</a></li>4962 <li>Content-Transfer-Encoding <a href="#rfc.iref.h.21">D. 7.5</a>, <a href="#rfc.xref.no.content-transfer-encoding.1">D.9</a></li>4963 <li>Content-Type <a href="#rfc.xref.header.content-type.1">3.1</a>, <a href="#rfc.xref.header.content-type.2">4</a>, <a href="#rfc.xref.header.content-type.3">6.5</a>, <a href="#rfc. xref.header.content-type.4">8.3</a>, <a href="#rfc.xref.header.content-type.5">D.2.1</a>, <a href="#rfc.iref.h.19"><b>D.4.8</b></a></li>4964 <li>Date <a href="#rfc.xref.header.date.1">3.3</a>, <a href="#rfc.iref.h. 3"><b>7.2</b></a>, <a href="#rfc.xref.header.date.2">8.3</a></li>4965 <li>Expect <a href="#rfc.xref.header.expect.1">3.2</a>, <a href="#rfc.xref.header.expect.2">4.6.14</a>, <a href="#rfc.iref.h. 4"><b>7.3</b></a>, <a href="#rfc.xref.header.expect.3">8.3</a>, <a href="#rfc.xref.header.expect.4">A</a></li>4966 <li>From <a href="#rfc.xref.header.from.1">3.2</a>, <a href="#rfc.iref.h. 5"><b>7.4</b></a>, <a href="#rfc.xref.header.from.2">8.3</a></li>4967 <li>Location <a href="#rfc.xref.header.location.1">2.3.4</a>, <a href="#rfc.xref.header.location.2">3.3</a>, <a href="#rfc.xref.header.location.3">4.5</a>, <a href="#rfc.iref.h. 6"><b>7.5</b></a>, <a href="#rfc.xref.header.location.4">8.3</a>, <a href="#rfc.xref.header.location.5">A</a></li>4968 <li>Max-Forwards <a href="#rfc.xref.header.max-forwards.1">2.3.1</a>, <a href="#rfc.xref.header.max-forwards.2">2.3.7</a>, <a href="#rfc.xref.header.max-forwards.3">3.2</a>, <a href="#rfc.iref.h. 7"><b>7.6</b></a>, <a href="#rfc.xref.header.max-forwards.4">8.3</a>, <a href="#rfc.xref.header.max-forwards.5">A</a></li>4969 <li>MIME-Version <a href="#rfc.xref.mime-version.1">8.3</a>, <a href="#rfc.iref.h.20"><b>D. 7.1</b></a></li>4970 <li>Referer <a href="#rfc.xref.header.referer.1">3.2</a>, <a href="#rfc.iref.h. 8"><b>7.7</b></a>, <a href="#rfc.xref.header.referer.2">8.3</a>, <a href="#rfc.xref.header.referer.3">A</a></li>4971 <li>Retry-After <a href="#rfc.xref.header.retry-after.1">3.3</a>, <a href="#rfc.xref.header.retry-after.2">4.7.4</a>, <a href="#rfc.iref.h. 9"><b>7.8</b></a>, <a href="#rfc.xref.header.retry-after.3">8.3</a></li>4972 <li>Server <a href="#rfc.xref.header.server.1">3.3</a>, <a href="#rfc.iref.h.1 0"><b>7.9</b></a>, <a href="#rfc.xref.header.server.2">8.3</a>, <a href="#rfc.xref.header.server.3">9.1</a>, <a href="#rfc.xref.header.server.4">A</a></li>4973 <li>User-Agent <a href="#rfc.xref.header.user-agent.1">3.2</a>, <a href="#rfc.iref.h.1 1"><b>7.10</b></a>, <a href="#rfc.xref.header.user-agent.2">8.3</a>, <a href="#rfc.xref.header.user-agent.3">9.1</a>, <a href="#rfc.xref.header.user-agent.4">D.3.1</a></li>4951 <li>Accept <a href="#rfc.xref.header.accept.1">3.2</a>, <a href="#rfc.xref.header.accept.2">6.5</a>, <a href="#rfc.iref.h.2"><b>7.1</b></a>, <a href="#rfc.xref.header.accept.3">8.3</a>, <a href="#rfc.xref.header.accept.4">D.3.1</a></li> 4952 <li>Accept-Charset <a href="#rfc.xref.header.accept-charset.1">3.2</a>, <a href="#rfc.iref.h.3"><b>7.2</b></a>, <a href="#rfc.xref.header.accept-charset.2">8.3</a>, <a href="#rfc.xref.header.accept-charset.3">D.3.1</a>, <a href="#rfc.xref.header.accept-charset.4">D.8</a></li> 4953 <li>Accept-Encoding <a href="#rfc.xref.header.accept-encoding.1">3.2</a>, <a href="#rfc.xref.header.accept-encoding.2">6.4</a>, <a href="#rfc.iref.h.4"><b>7.3</b></a>, <a href="#rfc.xref.header.accept-encoding.3">8.3</a>, <a href="#rfc.xref.header.accept-encoding.4">D.3.1</a>, <a href="#rfc.xref.header.accept-encoding.5">D.4.1</a></li> 4954 <li>Accept-Language <a href="#rfc.xref.header.accept-language.1">3.2</a>, <a href="#rfc.iref.h.5"><b>7.4</b></a>, <a href="#rfc.xref.header.accept-language.2">8.3</a>, <a href="#rfc.xref.header.accept-language.3">D.3.1</a></li> 4955 <li>Allow <a href="#rfc.xref.header.allow.1">2</a>, <a href="#rfc.xref.header.allow.2">3.3</a>, <a href="#rfc.iref.h.6"><b>7.5</b></a>, <a href="#rfc.xref.header.allow.3">8.3</a>, <a href="#rfc.xref.header.allow.4">A</a></li> 4956 <li>Content-Encoding <a href="#rfc.xref.header.content-encoding.1">6.4</a>, <a href="#rfc.iref.h.7"><b>7.6</b></a>, <a href="#rfc.xref.header.content-encoding.2">7.6</a>, <a href="#rfc.xref.header.content-encoding.3">8.3</a>, <a href="#rfc.xref.header.content-encoding.4">D.2.1</a></li> 4957 <li>Content-Language <a href="#rfc.iref.h.8"><b>7.7</b></a>, <a href="#rfc.xref.header.content-language.1">8.3</a>, <a href="#rfc.xref.header.content-language.2">D.2.1</a></li> 4958 <li>Content-Location <a href="#rfc.xref.header.content-location.1">2.3.4</a>, <a href="#rfc.iref.h.9"><b>7.8</b></a>, <a href="#rfc.xref.header.content-location.2">7.13</a>, <a href="#rfc.xref.header.content-location.3">8.3</a>, <a href="#rfc.xref.header.content-location.4">D.2.1</a>, <a href="#rfc.xref.header.content-location.5">D.8</a></li> 4959 <li>Content-Transfer-Encoding <a href="#rfc.iref.h.21">D.6.5</a>, <a href="#rfc.xref.no.content-transfer-encoding.1">D.8</a></li> 4960 <li>Content-Type <a href="#rfc.xref.header.content-type.1">3.1</a>, <a href="#rfc.xref.header.content-type.2">4</a>, <a href="#rfc.xref.header.content-type.3">6.5</a>, <a href="#rfc.iref.h.10"><b>7.9</b></a>, <a href="#rfc.xref.header.content-type.4">8.3</a>, <a href="#rfc.xref.header.content-type.5">D.2.1</a></li> 4961 <li>Date <a href="#rfc.xref.header.date.1">3.3</a>, <a href="#rfc.iref.h.11"><b>7.10</b></a>, <a href="#rfc.xref.header.date.2">8.3</a></li> 4962 <li>Expect <a href="#rfc.xref.header.expect.1">3.2</a>, <a href="#rfc.xref.header.expect.2">4.6.14</a>, <a href="#rfc.iref.h.12"><b>7.11</b></a>, <a href="#rfc.xref.header.expect.3">8.3</a>, <a href="#rfc.xref.header.expect.4">A</a></li> 4963 <li>From <a href="#rfc.xref.header.from.1">3.2</a>, <a href="#rfc.iref.h.13"><b>7.12</b></a>, <a href="#rfc.xref.header.from.2">8.3</a></li> 4964 <li>Location <a href="#rfc.xref.header.location.1">2.3.4</a>, <a href="#rfc.xref.header.location.2">3.3</a>, <a href="#rfc.xref.header.location.3">4.5</a>, <a href="#rfc.iref.h.14"><b>7.13</b></a>, <a href="#rfc.xref.header.location.4">8.3</a>, <a href="#rfc.xref.header.location.5">A</a></li> 4965 <li>Max-Forwards <a href="#rfc.xref.header.max-forwards.1">2.3.1</a>, <a href="#rfc.xref.header.max-forwards.2">2.3.7</a>, <a href="#rfc.xref.header.max-forwards.3">3.2</a>, <a href="#rfc.iref.h.15"><b>7.14</b></a>, <a href="#rfc.xref.header.max-forwards.4">8.3</a>, <a href="#rfc.xref.header.max-forwards.5">A</a></li> 4966 <li>MIME-Version <a href="#rfc.xref.mime-version.1">8.3</a>, <a href="#rfc.iref.h.20"><b>D.6.1</b></a></li> 4967 <li>Referer <a href="#rfc.xref.header.referer.1">3.2</a>, <a href="#rfc.iref.h.16"><b>7.15</b></a>, <a href="#rfc.xref.header.referer.2">8.3</a>, <a href="#rfc.xref.header.referer.3">A</a></li> 4968 <li>Retry-After <a href="#rfc.xref.header.retry-after.1">3.3</a>, <a href="#rfc.xref.header.retry-after.2">4.7.4</a>, <a href="#rfc.iref.h.17"><b>7.16</b></a>, <a href="#rfc.xref.header.retry-after.3">8.3</a></li> 4969 <li>Server <a href="#rfc.xref.header.server.1">3.3</a>, <a href="#rfc.iref.h.18"><b>7.17</b></a>, <a href="#rfc.xref.header.server.2">8.3</a>, <a href="#rfc.xref.header.server.3">9.1</a>, <a href="#rfc.xref.header.server.4">A</a></li> 4970 <li>User-Agent <a href="#rfc.xref.header.user-agent.1">3.2</a>, <a href="#rfc.iref.h.19"><b>7.18</b></a>, <a href="#rfc.xref.header.user-agent.2">8.3</a>, <a href="#rfc.xref.header.user-agent.3">9.1</a>, <a href="#rfc.xref.header.user-agent.4">D.3.1</a></li> 4974 4971 </ul> 4975 4972 </li> … … 4981 4978 </li> 4982 4979 <li><a id="rfc.index.L" href="#rfc.index.L"><b>L</b></a><ul> 4983 <li>Location header field <a href="#rfc.xref.header.location.1">2.3.4</a>, <a href="#rfc.xref.header.location.2">3.3</a>, <a href="#rfc.xref.header.location.3">4.5</a>, <a href="#rfc.iref.l.1"><b>7. 5</b></a>, <a href="#rfc.xref.header.location.4">8.3</a>, <a href="#rfc.xref.header.location.5">A</a></li>4980 <li>Location header field <a href="#rfc.xref.header.location.1">2.3.4</a>, <a href="#rfc.xref.header.location.2">3.3</a>, <a href="#rfc.xref.header.location.3">4.5</a>, <a href="#rfc.iref.l.1"><b>7.13</b></a>, <a href="#rfc.xref.header.location.4">8.3</a>, <a href="#rfc.xref.header.location.5">A</a></li> 4984 4981 </ul> 4985 4982 </li> 4986 4983 <li><a id="rfc.index.M" href="#rfc.index.M"><b>M</b></a><ul> 4987 <li>Max-Forwards header field <a href="#rfc.xref.header.max-forwards.1">2.3.1</a>, <a href="#rfc.xref.header.max-forwards.2">2.3.7</a>, <a href="#rfc.xref.header.max-forwards.3">3.2</a>, <a href="#rfc.iref.m.9"><b>7. 6</b></a>, <a href="#rfc.xref.header.max-forwards.4">8.3</a>, <a href="#rfc.xref.header.max-forwards.5">A</a></li>4984 <li>Max-Forwards header field <a href="#rfc.xref.header.max-forwards.1">2.3.1</a>, <a href="#rfc.xref.header.max-forwards.2">2.3.7</a>, <a href="#rfc.xref.header.max-forwards.3">3.2</a>, <a href="#rfc.iref.m.9"><b>7.14</b></a>, <a href="#rfc.xref.header.max-forwards.4">8.3</a>, <a href="#rfc.xref.header.max-forwards.5">A</a></li> 4988 4985 <li>Methods 4989 4986 <ul> … … 4992 4989 <li>GET <a href="#rfc.iref.m.2"><b>2.3.2</b></a>, <a href="#rfc.xref.GET.1">8.1</a></li> 4993 4990 <li>HEAD <a href="#rfc.iref.m.3"><b>2.3.3</b></a>, <a href="#rfc.xref.HEAD.1">8.1</a></li> 4994 <li>OPTIONS <a href="#rfc.iref.m.1"><b>2.3.1</b></a>, <a href="#rfc.xref.OPTIONS.1">7. 6</a>, <a href="#rfc.xref.OPTIONS.2">8.1</a></li>4991 <li>OPTIONS <a href="#rfc.iref.m.1"><b>2.3.1</b></a>, <a href="#rfc.xref.OPTIONS.1">7.14</a>, <a href="#rfc.xref.OPTIONS.2">8.1</a></li> 4995 4992 <li>POST <a href="#rfc.iref.m.4"><b>2.3.4</b></a>, <a href="#rfc.xref.POST.1">8.1</a>, <a href="#rfc.xref.POST.2">A</a></li> 4996 4993 <li>PUT <a href="#rfc.iref.m.5"><b>2.3.5</b></a>, <a href="#rfc.xref.PUT.1">8.1</a>, <a href="#rfc.xref.PUT.2">A</a></li> 4997 <li>TRACE <a href="#rfc.iref.m.7"><b>2.3.7</b></a>, <a href="#rfc.xref.TRACE.1">7. 6</a>, <a href="#rfc.xref.TRACE.2">8.1</a>, <a href="#rfc.xref.TRACE.3">9.1</a></li>4994 <li>TRACE <a href="#rfc.iref.m.7"><b>2.3.7</b></a>, <a href="#rfc.xref.TRACE.1">7.14</a>, <a href="#rfc.xref.TRACE.2">8.1</a>, <a href="#rfc.xref.TRACE.3">9.1</a></li> 4998 4995 </ul> 4999 4996 </li> 5000 <li>MIME-Version header field <a href="#rfc.xref.mime-version.1">8.3</a>, <a href="#rfc.iref.m.10"><b>D. 7.1</b></a></li>4997 <li>MIME-Version header field <a href="#rfc.xref.mime-version.1">8.3</a>, <a href="#rfc.iref.m.10"><b>D.6.1</b></a></li> 5001 4998 </ul> 5002 4999 </li> 5003 5000 <li><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul> 5004 <li>OPTIONS method <a href="#rfc.iref.o.1"><b>2.3.1</b></a>, <a href="#rfc.xref.OPTIONS.1">7. 6</a>, <a href="#rfc.xref.OPTIONS.2">8.1</a></li>5001 <li>OPTIONS method <a href="#rfc.iref.o.1"><b>2.3.1</b></a>, <a href="#rfc.xref.OPTIONS.1">7.14</a>, <a href="#rfc.xref.OPTIONS.2">8.1</a></li> 5005 5002 </ul> 5006 5003 </li> 5007 5004 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 5008 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">1.3</a>, <a href="#rfc.xref.Part1.4">1.3.1</a>, <a href="#rfc.xref.Part1.5">1.3.1</a>, <a href="#rfc.xref.Part1.6">1.3.1</a>, <a href="#rfc.xref.Part1.7">1.3.1</a>, <a href="#rfc.xref.Part1.8">1.3.1</a>, <a href="#rfc.xref.Part1.9">1.3.1</a>, <a href="#rfc.xref.Part1.10">1.3.1</a>, <a href="#rfc.xref.Part1.11">1.3.1</a>, <a href="#rfc.xref.Part1.12">1.3.2</a>, <a href="#rfc.xref.Part1.13">1.3.2</a>, <a href="#rfc.xref.Part1.14">1.3.2</a>, <a href="#rfc.xref.Part1.15">1.3.2</a>, <a href="#rfc.xref.Part1.16">2</a>, <a href="#rfc.xref.Part1.17">2.2.1</a>, <a href="#rfc.xref.Part1.18">2.3.1</a>, <a href="#rfc.xref.Part1.19">2.3.7</a>, <a href="#rfc.xref.Part1.20">2.3.7</a>, <a href="#rfc.xref.Part1.21">2.3.8</a>, <a href="#rfc.xref.Part1.22">3</a>, <a href="#rfc.xref.Part1.23">3.1</a>, <a href="#rfc.xref.Part1.24">3.1</a>, <a href="#rfc.xref.Part1.25">3.1</a>, <a href="#rfc.xref.Part1.26">3.1</a>, <a href="#rfc.xref.Part1.27">3.1</a>, <a href="#rfc.xref.Part1.28">3.2</a>, <a href="#rfc.xref.Part1.29">3.2</a>, <a href="#rfc.xref.Part1.30">3.3</a>, <a href="#rfc.xref.Part1.31">4.3.1</a>, <a href="#rfc.xref.Part1.32">4.3.2</a>, <a href="#rfc.xref.Part1.33">4.4.4</a>, <a href="#rfc.xref.Part1.34">4.4.6</a>, <a href="#rfc.xref.Part1.35">4.6.15</a>, <a href="#rfc.xref.Part1.36">4.7.6</a>, <a href="#rfc.xref.Part1.37">5</a>, <a href="#rfc.xref.Part1.38">5.1</a>, <a href="#rfc.xref.Part1.39">6.4</a>, <a href="#rfc.xref.Part1.40">6.4</a>, <a href="#rfc.xref.Part1.41">6.4</a>, <a href="#rfc.xref.Part1.42">6.4.1</a>, <a href="#rfc.xref.Part1.43">6.4.1</a>, <a href="#rfc.xref.Part1.44">7. 3</a>, <a href="#rfc.xref.Part1.45">7.9</a>, <a href="#rfc.xref.Part1.46">7.9</a>, <a href="#rfc.xref.Part1.47">7.10</a>, <a href="#rfc.xref.Part1.48">10</a>, <a href="#Part1"><b>11.1</b></a>, <a href="#rfc.xref.Part1.49">A</a>, <a href="#rfc.xref.Part1.50">D.1.1</a>, <a href="#rfc.xref.Part1.51">D.1.2</a>, <a href="#rfc.xref.Part1.52">D.3.1</a>, <a href="#rfc.xref.Part1.53">D.4.1</a>, <a href="#rfc.xref.Part1.54">D.4.3</a>, <a href="#rfc.xref.Part1.55">D.4.7</a>, <a href="#rfc.xref.Part1.56">D.5.1</a>, <a href="#rfc.xref.Part1.57">D.5.1</a>, <a href="#rfc.xref.Part1.58">D.5.1</a>, <a href="#rfc.xref.Part1.59">D.7.6</a><ul>5005 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">1.3</a>, <a href="#rfc.xref.Part1.4">1.3.1</a>, <a href="#rfc.xref.Part1.5">1.3.1</a>, <a href="#rfc.xref.Part1.6">1.3.1</a>, <a href="#rfc.xref.Part1.7">1.3.1</a>, <a href="#rfc.xref.Part1.8">1.3.1</a>, <a href="#rfc.xref.Part1.9">1.3.1</a>, <a href="#rfc.xref.Part1.10">1.3.1</a>, <a href="#rfc.xref.Part1.11">1.3.1</a>, <a href="#rfc.xref.Part1.12">1.3.2</a>, <a href="#rfc.xref.Part1.13">1.3.2</a>, <a href="#rfc.xref.Part1.14">1.3.2</a>, <a href="#rfc.xref.Part1.15">1.3.2</a>, <a href="#rfc.xref.Part1.16">2</a>, <a href="#rfc.xref.Part1.17">2.2.1</a>, <a href="#rfc.xref.Part1.18">2.3.1</a>, <a href="#rfc.xref.Part1.19">2.3.7</a>, <a href="#rfc.xref.Part1.20">2.3.7</a>, <a href="#rfc.xref.Part1.21">2.3.8</a>, <a href="#rfc.xref.Part1.22">3</a>, <a href="#rfc.xref.Part1.23">3.1</a>, <a href="#rfc.xref.Part1.24">3.1</a>, <a href="#rfc.xref.Part1.25">3.1</a>, <a href="#rfc.xref.Part1.26">3.1</a>, <a href="#rfc.xref.Part1.27">3.1</a>, <a href="#rfc.xref.Part1.28">3.2</a>, <a href="#rfc.xref.Part1.29">3.2</a>, <a href="#rfc.xref.Part1.30">3.3</a>, <a href="#rfc.xref.Part1.31">4.3.1</a>, <a href="#rfc.xref.Part1.32">4.3.2</a>, <a href="#rfc.xref.Part1.33">4.4.4</a>, <a href="#rfc.xref.Part1.34">4.4.6</a>, <a href="#rfc.xref.Part1.35">4.6.15</a>, <a href="#rfc.xref.Part1.36">4.7.6</a>, <a href="#rfc.xref.Part1.37">5</a>, <a href="#rfc.xref.Part1.38">5.1</a>, <a href="#rfc.xref.Part1.39">6.4</a>, <a href="#rfc.xref.Part1.40">6.4</a>, <a href="#rfc.xref.Part1.41">6.4</a>, <a href="#rfc.xref.Part1.42">6.4.1</a>, <a href="#rfc.xref.Part1.43">6.4.1</a>, <a href="#rfc.xref.Part1.44">7.1</a>, <a href="#rfc.xref.Part1.45">7.3</a>, <a href="#rfc.xref.Part1.46">7.8</a>, <a href="#rfc.xref.Part1.47">7.11</a>, <a href="#rfc.xref.Part1.48">7.17</a>, <a href="#rfc.xref.Part1.49">7.17</a>, <a href="#rfc.xref.Part1.50">7.18</a>, <a href="#rfc.xref.Part1.51">10</a>, <a href="#Part1"><b>11.1</b></a>, <a href="#rfc.xref.Part1.52">A</a>, <a href="#rfc.xref.Part1.53">D.1.1</a>, <a href="#rfc.xref.Part1.54">D.1.2</a>, <a href="#rfc.xref.Part1.55">D.3.1</a>, <a href="#rfc.xref.Part1.56">D.4.1</a>, <a href="#rfc.xref.Part1.57">D.4.1</a>, <a href="#rfc.xref.Part1.58">D.4.1</a>, <a href="#rfc.xref.Part1.59">D.6.6</a><ul> 5009 5006 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.3">1.3</a></li> 5010 5007 <li><em>Section 2</em> <a href="#rfc.xref.Part1.2">1.2</a></li> … … 5013 5010 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.12">1.3.2</a>, <a href="#rfc.xref.Part1.14">1.3.2</a>, <a href="#rfc.xref.Part1.15">1.3.2</a></li> 5014 5011 <li><em>Section 3.2.1</em> <a href="#rfc.xref.Part1.5">1.3.1</a>, <a href="#rfc.xref.Part1.6">1.3.1</a>, <a href="#rfc.xref.Part1.7">1.3.1</a></li> 5015 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.22">3</a>, <a href="#rfc.xref.Part1.25">3.1</a>, <a href="#rfc.xref.Part1.4 5">7.9</a>, <a href="#rfc.xref.Part1.47">7.10</a></li>5012 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.22">3</a>, <a href="#rfc.xref.Part1.25">3.1</a>, <a href="#rfc.xref.Part1.48">7.17</a>, <a href="#rfc.xref.Part1.50">7.18</a></li> 5016 5013 <li><em>Section 3.2.4</em> <a href="#rfc.xref.Part1.8">1.3.1</a>, <a href="#rfc.xref.Part1.9">1.3.1</a>, <a href="#rfc.xref.Part1.10">1.3.1</a>, <a href="#rfc.xref.Part1.11">1.3.1</a>, <a href="#rfc.xref.Part1.13">1.3.2</a>, <a href="#rfc.xref.Part1.24">3.1</a></li> 5017 5014 <li><em>Section 3.2.5</em> <a href="#rfc.xref.Part1.23">3.1</a></li> 5018 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.17">2.2.1</a>, <a href="#rfc.xref.Part1.34">4.4.6</a>, <a href="#rfc.xref.Part1.37">5</a>, <a href="#rfc.xref.Part1.5 1">D.1.2</a></li>5019 <li><em>Section 3.3.1</em> <a href="#rfc.xref.Part1.59">D. 7.6</a></li>5020 <li><em>Section 3.3.2</em> <a href="#rfc.xref.Part1.5 0">D.1.1</a></li>5015 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.17">2.2.1</a>, <a href="#rfc.xref.Part1.34">4.4.6</a>, <a href="#rfc.xref.Part1.37">5</a>, <a href="#rfc.xref.Part1.54">D.1.2</a></li> 5016 <li><em>Section 3.3.1</em> <a href="#rfc.xref.Part1.59">D.6.6</a></li> 5017 <li><em>Section 3.3.2</em> <a href="#rfc.xref.Part1.53">D.1.1</a></li> 5021 5018 <li><em>Section 4</em> <a href="#rfc.xref.Part1.42">6.4.1</a></li> 5022 5019 <li><em>Section 4.1</em> <a href="#rfc.xref.Part1.27">3.1</a></li> 5023 <li><em>Section 4.2.1</em> <a href="#rfc.xref.Part1.39">6.4</a>, <a href="#rfc.xref.Part1.56">D. 5.1</a></li>5020 <li><em>Section 4.2.1</em> <a href="#rfc.xref.Part1.39">6.4</a>, <a href="#rfc.xref.Part1.56">D.4.1</a></li> 5024 5021 <li><em>Section 4.2</em> <a href="#rfc.xref.Part1.43">6.4.1</a></li> 5025 <li><em>Section 4.2.2</em> <a href="#rfc.xref.Part1.40">6.4</a>, <a href="#rfc.xref.Part1.57">D. 5.1</a></li>5026 <li><em>Section 4.2.3</em> <a href="#rfc.xref.Part1.41">6.4</a>, <a href="#rfc.xref.Part1.58">D. 5.1</a></li>5022 <li><em>Section 4.2.2</em> <a href="#rfc.xref.Part1.40">6.4</a>, <a href="#rfc.xref.Part1.57">D.4.1</a></li> 5023 <li><em>Section 4.2.3</em> <a href="#rfc.xref.Part1.41">6.4</a>, <a href="#rfc.xref.Part1.58">D.4.1</a></li> 5027 5024 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.29">3.2</a></li> 5028 <li><em>Section 4.3.1</em> <a href="#rfc.xref.Part1. 52">D.3.1</a>, <a href="#rfc.xref.Part1.53">D.4.1</a>, <a href="#rfc.xref.Part1.54">D.4.3</a></li>5025 <li><em>Section 4.3.1</em> <a href="#rfc.xref.Part1.44">7.1</a>, <a href="#rfc.xref.Part1.45">7.3</a>, <a href="#rfc.xref.Part1.55">D.3.1</a></li> 5029 5026 <li><em>Section 5.3</em> <a href="#rfc.xref.Part1.18">2.3.1</a>, <a href="#rfc.xref.Part1.21">2.3.8</a></li> 5030 5027 <li><em>Section 5.4</em> <a href="#rfc.xref.Part1.28">3.2</a></li> 5031 <li><em>Section 5.5</em> <a href="#rfc.xref.Part1.16">2</a>, <a href="#rfc.xref.Part1.30">3.3</a>, <a href="#rfc.xref.Part1.38">5.1</a>, <a href="#rfc.xref.Part1. 55">D.4.7</a></li>5028 <li><em>Section 5.5</em> <a href="#rfc.xref.Part1.16">2</a>, <a href="#rfc.xref.Part1.30">3.3</a>, <a href="#rfc.xref.Part1.38">5.1</a>, <a href="#rfc.xref.Part1.46">7.8</a></li> 5032 5029 <li><em>Section 6.1</em> <a href="#rfc.xref.Part1.26">3.1</a></li> 5033 <li><em>Section 6.2</em> <a href="#rfc.xref.Part1.19">2.3.7</a>, <a href="#rfc.xref.Part1.4 6">7.9</a>, <a href="#rfc.xref.Part1.49">A</a></li>5034 <li><em>Section 6.4.3</em> <a href="#rfc.xref.Part1.31">4.3.1</a>, <a href="#rfc.xref.Part1.4 4">7.3</a></li>5030 <li><em>Section 6.2</em> <a href="#rfc.xref.Part1.19">2.3.7</a>, <a href="#rfc.xref.Part1.49">7.17</a>, <a href="#rfc.xref.Part1.52">A</a></li> 5031 <li><em>Section 6.4.3</em> <a href="#rfc.xref.Part1.31">4.3.1</a>, <a href="#rfc.xref.Part1.47">7.11</a></li> 5035 5032 <li><em>Section 6.5</em> <a href="#rfc.xref.Part1.32">4.3.2</a>, <a href="#rfc.xref.Part1.35">4.6.15</a></li> 5036 5033 <li><em>Section 7.3.1</em> <a href="#rfc.xref.Part1.20">2.3.7</a></li> 5037 <li><em>Section 9</em> <a href="#rfc.xref.Part1. 48">10</a></li>5034 <li><em>Section 9</em> <a href="#rfc.xref.Part1.51">10</a></li> 5038 5035 </ul> 5039 5036 </li> … … 5088 5085 </li> 5089 5086 <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul> 5090 <li>Referer header field <a href="#rfc.xref.header.referer.1">3.2</a>, <a href="#rfc.iref.r.1"><b>7. 7</b></a>, <a href="#rfc.xref.header.referer.2">8.3</a>, <a href="#rfc.xref.header.referer.3">A</a></li>5087 <li>Referer header field <a href="#rfc.xref.header.referer.1">3.2</a>, <a href="#rfc.iref.r.1"><b>7.15</b></a>, <a href="#rfc.xref.header.referer.2">8.3</a>, <a href="#rfc.xref.header.referer.3">A</a></li> 5091 5088 <li>representation <a href="#rfc.iref.r.3">D.2</a></li> 5092 <li>Retry-After header field <a href="#rfc.xref.header.retry-after.1">3.3</a>, <a href="#rfc.xref.header.retry-after.2">4.7.4</a>, <a href="#rfc.iref.r.2"><b>7. 8</b></a>, <a href="#rfc.xref.header.retry-after.3">8.3</a></li>5089 <li>Retry-After header field <a href="#rfc.xref.header.retry-after.1">3.3</a>, <a href="#rfc.xref.header.retry-after.2">4.7.4</a>, <a href="#rfc.iref.r.2"><b>7.16</b></a>, <a href="#rfc.xref.header.retry-after.3">8.3</a></li> 5093 5090 <li><em>RFC1123</em> <a href="#rfc.xref.RFC1123.1">6.1</a>, <a href="#rfc.xref.RFC1123.2">6.1</a>, <a href="#RFC1123"><b>11.2</b></a><ul> 5094 5091 <li><em>Section 5.2.14</em> <a href="#rfc.xref.RFC1123.2">6.1</a></li> 5095 5092 </ul> 5096 5093 </li> 5097 <li><em>RFC1945</em> <a href="#rfc.xref.RFC1945.1">4.5</a>, <a href="#RFC1945"><b>11.2</b></a>, <a href="#rfc.xref.RFC1945.2">D. 8</a><ul>5094 <li><em>RFC1945</em> <a href="#rfc.xref.RFC1945.1">4.5</a>, <a href="#RFC1945"><b>11.2</b></a>, <a href="#rfc.xref.RFC1945.2">D.7</a><ul> 5098 5095 <li><em>Section 9.3</em> <a href="#rfc.xref.RFC1945.1">4.5</a></li> 5099 5096 </ul> 5100 5097 </li> 5101 <li><em>RFC1950</em> <a href="#RFC1950"><b>11.1</b></a>, <a href="#rfc.xref.RFC1950.1">D. 5.1</a></li>5102 <li><em>RFC1951</em> <a href="#RFC1951"><b>11.1</b></a>, <a href="#rfc.xref.RFC1951.1">D. 5.1</a></li>5103 <li><em>RFC1952</em> <a href="#RFC1952"><b>11.1</b></a>, <a href="#rfc.xref.RFC1952.1">D. 5.1</a></li>5104 <li><em>RFC2045</em> <a href="#RFC2045"><b>11.1</b></a>, <a href="#rfc.xref.RFC2045.1">D. 7</a>, <a href="#rfc.xref.RFC2045.2">D.7.1</a></li>5105 <li><em>RFC2046</em> <a href="#rfc.xref.RFC2046.1">6.5</a>, <a href="#rfc.xref.RFC2046.2">6.5.2</a>, <a href="#RFC2046"><b>11.1</b></a>, <a href="#rfc.xref.RFC2046.3">D.2.2</a>, <a href="#rfc.xref.RFC2046.4">D. 7.2</a><ul>5098 <li><em>RFC1950</em> <a href="#RFC1950"><b>11.1</b></a>, <a href="#rfc.xref.RFC1950.1">D.4.1</a></li> 5099 <li><em>RFC1951</em> <a href="#RFC1951"><b>11.1</b></a>, <a href="#rfc.xref.RFC1951.1">D.4.1</a></li> 5100 <li><em>RFC1952</em> <a href="#RFC1952"><b>11.1</b></a>, <a href="#rfc.xref.RFC1952.1">D.4.1</a></li> 5101 <li><em>RFC2045</em> <a href="#RFC2045"><b>11.1</b></a>, <a href="#rfc.xref.RFC2045.1">D.6</a>, <a href="#rfc.xref.RFC2045.2">D.6.1</a></li> 5102 <li><em>RFC2046</em> <a href="#rfc.xref.RFC2046.1">6.5</a>, <a href="#rfc.xref.RFC2046.2">6.5.2</a>, <a href="#RFC2046"><b>11.1</b></a>, <a href="#rfc.xref.RFC2046.3">D.2.2</a>, <a href="#rfc.xref.RFC2046.4">D.6.2</a><ul> 5106 5103 <li><em>Section 4.5.1</em> <a href="#rfc.xref.RFC2046.3">D.2.2</a></li> 5107 5104 <li><em>Section 5.1.1</em> <a href="#rfc.xref.RFC2046.2">6.5.2</a></li> 5108 5105 </ul> 5109 5106 </li> 5110 <li><em>RFC2049</em> <a href="#RFC2049"><b>11.2</b></a>, <a href="#rfc.xref.RFC2049.1">D. 7.2</a><ul>5111 <li><em>Section 4</em> <a href="#rfc.xref.RFC2049.1">D. 7.2</a></li>5107 <li><em>RFC2049</em> <a href="#RFC2049"><b>11.2</b></a>, <a href="#rfc.xref.RFC2049.1">D.6.2</a><ul> 5108 <li><em>Section 4</em> <a href="#rfc.xref.RFC2049.1">D.6.2</a></li> 5112 5109 </ul> 5113 5110 </li> 5114 <li><em>RFC2068</em> <a href="#rfc.xref.RFC2068.1">4.5</a>, <a href="#rfc.xref.RFC2068.2">4.5</a>, <a href="#RFC2068"><b>11.2</b></a>, <a href="#rfc.xref.RFC2068.3">D. 8</a><ul>5111 <li><em>RFC2068</em> <a href="#rfc.xref.RFC2068.1">4.5</a>, <a href="#rfc.xref.RFC2068.2">4.5</a>, <a href="#RFC2068"><b>11.2</b></a>, <a href="#rfc.xref.RFC2068.3">D.7</a><ul> 5115 5112 <li><em>Section 10.3</em> <a href="#rfc.xref.RFC2068.2">4.5</a></li> 5116 5113 <li><em>Section 10.3.4</em> <a href="#rfc.xref.RFC2068.1">4.5</a></li> 5117 5114 </ul> 5118 5115 </li> 5119 <li><em>RFC2076</em> <a href="#RFC2076"><b>11.2</b></a>, <a href="#rfc.xref.RFC2076.1">D. 8</a></li>5116 <li><em>RFC2076</em> <a href="#RFC2076"><b>11.2</b></a>, <a href="#rfc.xref.RFC2076.1">D.7</a></li> 5120 5117 <li><em>RFC2119</em> <a href="#rfc.xref.RFC2119.1">1.2</a>, <a href="#RFC2119"><b>11.1</b></a></li> 5121 5118 <li><em>RFC2277</em> <a href="#rfc.xref.RFC2277.1">6.3</a>, <a href="#RFC2277"><b>11.2</b></a></li> 5122 5119 <li><em>RFC2295</em> <a href="#RFC2295"><b>11.2</b></a>, <a href="#rfc.xref.RFC2295.1">D.3</a></li> 5123 5120 <li><em>RFC2388</em> <a href="#rfc.xref.RFC2388.1">6.5.2</a>, <a href="#RFC2388"><b>11.2</b></a></li> 5124 <li><em>RFC2557</em> <a href="# RFC2557"><b>11.2</b></a>, <a href="#rfc.xref.RFC2557.1">D.4.7</a>, <a href="#rfc.xref.RFC2557.2">D.7.7</a><ul>5125 <li><em>Section 4</em> <a href="#rfc.xref.RFC2557.1"> D.4.7</a></li>5121 <li><em>RFC2557</em> <a href="#rfc.xref.RFC2557.1">7.8</a>, <a href="#RFC2557"><b>11.2</b></a>, <a href="#rfc.xref.RFC2557.2">D.6.7</a><ul> 5122 <li><em>Section 4</em> <a href="#rfc.xref.RFC2557.1">7.8</a></li> 5126 5123 </ul> 5127 5124 </li> 5128 <li><em>RFC2616</em> <a href="#rfc.xref.RFC2616.1">1</a>, <a href="#rfc.xref.RFC2616.2">4.5</a>, <a href="# RFC2616"><b>11.2</b></a>, <a href="#rfc.xref.RFC2616.3">C.1</a>, <a href="#rfc.xref.RFC2616.4">D.4.4</a>, <a href="#rfc.xref.RFC2616.5">D.10.1</a><ul>5125 <li><em>RFC2616</em> <a href="#rfc.xref.RFC2616.1">1</a>, <a href="#rfc.xref.RFC2616.2">4.5</a>, <a href="#rfc.xref.RFC2616.3">7.4</a>, <a href="#RFC2616"><b>11.2</b></a>, <a href="#rfc.xref.RFC2616.4">C.1</a>, <a href="#rfc.xref.RFC2616.5">D.9.1</a><ul> 5129 5126 <li><em>Section 10.3.8</em> <a href="#rfc.xref.RFC2616.2">4.5</a></li> 5130 <li><em>Section 14.4</em> <a href="#rfc.xref.RFC2616. 4">D.4.4</a></li>5127 <li><em>Section 14.4</em> <a href="#rfc.xref.RFC2616.3">7.4</a></li> 5131 5128 </ul> 5132 5129 </li> … … 5140 5137 </ul> 5141 5138 </li> 5142 <li><em>RFC3986</em> <a href="#rfc.xref.RFC3986.1">7. 5</a>, <a href="#rfc.xref.RFC3986.2">7.5</a>, <a href="#RFC3986"><b>11.1</b></a><ul>5143 <li><em>Section 4.2</em> <a href="#rfc.xref.RFC3986.1">7. 5</a></li>5144 <li><em>Section 5</em> <a href="#rfc.xref.RFC3986.2">7. 5</a></li>5139 <li><em>RFC3986</em> <a href="#rfc.xref.RFC3986.1">7.13</a>, <a href="#rfc.xref.RFC3986.2">7.13</a>, <a href="#RFC3986"><b>11.1</b></a><ul> 5140 <li><em>Section 4.2</em> <a href="#rfc.xref.RFC3986.1">7.13</a></li> 5141 <li><em>Section 5</em> <a href="#rfc.xref.RFC3986.2">7.13</a></li> 5145 5142 </ul> 5146 5143 </li> 5147 5144 <li><em>RFC4288</em> <a href="#rfc.xref.RFC4288.1">6.5</a>, <a href="#RFC4288"><b>11.2</b></a></li> 5148 <li><em>RFC4647</em> <a href="# RFC4647"><b>11.1</b></a>, <a href="#rfc.xref.RFC4647.1">D.4.4</a>, <a href="#rfc.xref.RFC4647.2">D.4.4</a>, <a href="#rfc.xref.RFC4647.3">D.4.4</a>, <a href="#rfc.xref.RFC4647.4">D.4.4</a><ul>5149 <li><em>Section 2.1</em> <a href="#rfc.xref.RFC4647.1"> D.4.4</a></li>5150 <li><em>Section 2.3</em> <a href="#rfc.xref.RFC4647.2"> D.4.4</a></li>5151 <li><em>Section 3</em> <a href="#rfc.xref.RFC4647.3"> D.4.4</a></li>5152 <li><em>Section 3.3.1</em> <a href="#rfc.xref.RFC4647.4"> D.4.4</a></li>5145 <li><em>RFC4647</em> <a href="#rfc.xref.RFC4647.1">7.4</a>, <a href="#rfc.xref.RFC4647.2">7.4</a>, <a href="#rfc.xref.RFC4647.3">7.4</a>, <a href="#rfc.xref.RFC4647.4">7.4</a>, <a href="#RFC4647"><b>11.1</b></a><ul> 5146 <li><em>Section 2.1</em> <a href="#rfc.xref.RFC4647.1">7.4</a></li> 5147 <li><em>Section 2.3</em> <a href="#rfc.xref.RFC4647.2">7.4</a></li> 5148 <li><em>Section 3</em> <a href="#rfc.xref.RFC4647.3">7.4</a></li> 5149 <li><em>Section 3.3.1</em> <a href="#rfc.xref.RFC4647.4">7.4</a></li> 5153 5150 </ul> 5154 5151 </li> … … 5161 5158 </ul> 5162 5159 </li> 5163 <li><em>RFC5322</em> <a href="#rfc.xref.RFC5322.1">6.1</a>, <a href="#rfc.xref.RFC5322.2">7. 2</a>, <a href="#rfc.xref.RFC5322.3">7.4</a>, <a href="#rfc.xref.RFC5322.4">7.4</a>, <a href="#RFC5322"><b>11.2</b></a>, <a href="#rfc.xref.RFC5322.5">D.7</a><ul>5160 <li><em>RFC5322</em> <a href="#rfc.xref.RFC5322.1">6.1</a>, <a href="#rfc.xref.RFC5322.2">7.10</a>, <a href="#rfc.xref.RFC5322.3">7.12</a>, <a href="#rfc.xref.RFC5322.4">7.12</a>, <a href="#RFC5322"><b>11.2</b></a>, <a href="#rfc.xref.RFC5322.5">D.6</a><ul> 5164 5161 <li><em>Section 3.3</em> <a href="#rfc.xref.RFC5322.1">6.1</a></li> 5165 <li><em>Section 3.4</em> <a href="#rfc.xref.RFC5322.3">7. 4</a>, <a href="#rfc.xref.RFC5322.4">7.4</a></li>5166 <li><em>Section 3.6.1</em> <a href="#rfc.xref.RFC5322.2">7. 2</a></li>5162 <li><em>Section 3.4</em> <a href="#rfc.xref.RFC5322.3">7.12</a>, <a href="#rfc.xref.RFC5322.4">7.12</a></li> 5163 <li><em>Section 3.6.1</em> <a href="#rfc.xref.RFC5322.2">7.10</a></li> 5167 5164 </ul> 5168 5165 </li> … … 5173 5170 <li><em>RFC5789</em> <a href="#rfc.xref.RFC5789.1">2.3.5</a>, <a href="#RFC5789"><b>11.2</b></a></li> 5174 5171 <li><em>RFC5987</em> <a href="#rfc.xref.RFC5987.1">3.1</a>, <a href="#RFC5987"><b>11.2</b></a></li> 5175 <li><em>RFC6151</em> <a href="#RFC6151"><b>11.2</b></a>, <a href="#rfc.xref.RFC6151.1">D. 9</a></li>5176 <li><em>RFC6266</em> <a href="#RFC6266"><b>11.2</b></a>, <a href="#rfc.xref.RFC6266.1">D. 8</a>, <a href="#rfc.xref.RFC6266.2">D.9</a></li>5172 <li><em>RFC6151</em> <a href="#RFC6151"><b>11.2</b></a>, <a href="#rfc.xref.RFC6151.1">D.8</a></li> 5173 <li><em>RFC6266</em> <a href="#RFC6266"><b>11.2</b></a>, <a href="#rfc.xref.RFC6266.1">D.7</a>, <a href="#rfc.xref.RFC6266.2">D.8</a></li> 5177 5174 </ul> 5178 5175 </li> … … 5180 5177 <li>Safe Methods <a href="#rfc.iref.s.2"><b>2.1.1</b></a></li> 5181 5178 <li>selected representation <a href="#rfc.iref.s.1"><b>1.1</b></a></li> 5182 <li>Server header field <a href="#rfc.xref.header.server.1">3.3</a>, <a href="#rfc.iref.s.39"><b>7. 9</b></a>, <a href="#rfc.xref.header.server.2">8.3</a>, <a href="#rfc.xref.header.server.3">9.1</a>, <a href="#rfc.xref.header.server.4">A</a></li>5179 <li>Server header field <a href="#rfc.xref.header.server.1">3.3</a>, <a href="#rfc.iref.s.39"><b>7.17</b></a>, <a href="#rfc.xref.header.server.2">8.3</a>, <a href="#rfc.xref.header.server.3">9.1</a>, <a href="#rfc.xref.header.server.4">A</a></li> 5183 5180 <li>Status Codes 5184 5181 <ul> … … 5224 5221 </li> 5225 5222 <li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul> 5226 <li>TRACE method <a href="#rfc.iref.t.1"><b>2.3.7</b></a>, <a href="#rfc.xref.TRACE.1">7. 6</a>, <a href="#rfc.xref.TRACE.2">8.1</a>, <a href="#rfc.xref.TRACE.3">9.1</a></li>5223 <li>TRACE method <a href="#rfc.iref.t.1"><b>2.3.7</b></a>, <a href="#rfc.xref.TRACE.1">7.14</a>, <a href="#rfc.xref.TRACE.2">8.1</a>, <a href="#rfc.xref.TRACE.3">9.1</a></li> 5227 5224 </ul> 5228 5225 </li> 5229 5226 <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul> 5230 <li>User-Agent header field <a href="#rfc.xref.header.user-agent.1">3.2</a>, <a href="#rfc.iref.u.1"><b>7.1 0</b></a>, <a href="#rfc.xref.header.user-agent.2">8.3</a>, <a href="#rfc.xref.header.user-agent.3">9.1</a>, <a href="#rfc.xref.header.user-agent.4">D.3.1</a></li>5227 <li>User-Agent header field <a href="#rfc.xref.header.user-agent.1">3.2</a>, <a href="#rfc.iref.u.1"><b>7.18</b></a>, <a href="#rfc.xref.header.user-agent.2">8.3</a>, <a href="#rfc.xref.header.user-agent.3">9.1</a>, <a href="#rfc.xref.header.user-agent.4">D.3.1</a></li> 5231 5228 </ul> 5232 5229 </li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1644 r1645 2605 2605 <t> 2606 2606 This section defines the syntax and semantics of HTTP/1.1 header fields 2607 related to request and response semantics. 2608 </t> 2607 related to request and response semantics and to the payload of messages. 2608 </t> 2609 2610 2611 <section title="Accept" anchor="header.accept"> 2612 <iref primary="true" item="Accept header field" x:for-anchor=""/> 2613 <iref primary="true" item="Header Fields" subitem="Accept" x:for-anchor=""/> 2614 <x:anchor-alias value="Accept"/> 2615 <x:anchor-alias value="accept-ext"/> 2616 <x:anchor-alias value="accept-params"/> 2617 <x:anchor-alias value="media-range"/> 2618 <t> 2619 The "Accept" header field can be used by user agents to specify 2620 response media types that are acceptable. Accept header fields can be used to 2621 indicate that the request is specifically limited to a small set of desired 2622 types, as in the case of a request for an in-line image. 2623 </t> 2624 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept"/><iref primary="true" item="Grammar" subitem="media-range"/><iref primary="true" item="Grammar" subitem="accept-params"/><iref primary="true" item="Grammar" subitem="accept-ext"/> 2625 <x:ref>Accept</x:ref> = #( <x:ref>media-range</x:ref> [ <x:ref>accept-params</x:ref> ] ) 2626 2627 <x:ref>media-range</x:ref> = ( "*/*" 2628 / ( <x:ref>type</x:ref> "/" "*" ) 2629 / ( <x:ref>type</x:ref> "/" <x:ref>subtype</x:ref> ) 2630 ) *( <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> <x:ref>parameter</x:ref> ) 2631 <x:ref>accept-params</x:ref> = <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> "q=" <x:ref>qvalue</x:ref> *( <x:ref>accept-ext</x:ref> ) 2632 <x:ref>accept-ext</x:ref> = <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> <x:ref>token</x:ref> [ "=" <x:ref>word</x:ref> ] 2633 </artwork></figure> 2634 <t> 2635 The asterisk "*" character is used to group media types into ranges, 2636 with "*/*" indicating all media types and "type/*" indicating all 2637 subtypes of that type. The media-range &MAY; include media type 2638 parameters that are applicable to that range. 2639 </t> 2640 <t> 2641 Each media-range &MAY; be followed by one or more accept-params, 2642 beginning with the "q" parameter for indicating a relative quality 2643 factor. The first "q" parameter (if any) separates the media-range 2644 parameter(s) from the accept-params. Quality factors allow the user 2645 or user agent to indicate the relative degree of preference for that 2646 media-range, using the qvalue scale from 0 to 1 (&qvalue;). The 2647 default value is q=1. 2648 </t> 2649 <x:note> 2650 <t> 2651 <x:h>Note:</x:h> Use of the "q" parameter name to separate media type 2652 parameters from Accept extension parameters is due to historical 2653 practice. Although this prevents any media type parameter named 2654 "q" from being used with a media range, such an event is believed 2655 to be unlikely given the lack of any "q" parameters in the IANA 2656 media type registry and the rare usage of any media type 2657 parameters in Accept. Future media types are discouraged from 2658 registering any parameter named "q". 2659 </t> 2660 </x:note> 2661 <t> 2662 The example 2663 </t> 2664 <figure><artwork type="example"> 2665 Accept: audio/*; q=0.2, audio/basic 2666 </artwork></figure> 2667 <t> 2668 &SHOULD; be interpreted as "I prefer audio/basic, but send me any audio 2669 type if it is the best available after an 80% mark-down in quality". 2670 </t> 2671 <t> 2672 A request without any Accept header field implies that the user agent 2673 will accept any media type in response. 2674 If an Accept header field is present in a request and none of the 2675 available representations for the response have a media type that is 2676 listed as acceptable, the origin server &MAY; either 2677 honor the Accept header field by sending a 406 (Not Acceptable) response 2678 or disregard the Accept header field by treating the response as if 2679 it is not subject to content negotiation. 2680 </t> 2681 <t> 2682 A more elaborate example is 2683 </t> 2684 <figure><artwork type="example"> 2685 Accept: text/plain; q=0.5, text/html, 2686 text/x-dvi; q=0.8, text/x-c 2687 </artwork></figure> 2688 <t> 2689 Verbally, this would be interpreted as "text/html and text/x-c are 2690 the preferred media types, but if they do not exist, then send the 2691 text/x-dvi representation, and if that does not exist, send the text/plain 2692 representation". 2693 </t> 2694 <t> 2695 Media ranges can be overridden by more specific media ranges or 2696 specific media types. If more than one media range applies to a given 2697 type, the most specific reference has precedence. For example, 2698 </t> 2699 <figure><artwork type="example"> 2700 Accept: text/*, text/plain, text/plain;format=flowed, */* 2701 </artwork></figure> 2702 <t> 2703 have the following precedence: 2704 <list style="numbers"> 2705 <t>text/plain;format=flowed</t> 2706 <t>text/plain</t> 2707 <t>text/*</t> 2708 <t>*/*</t> 2709 </list> 2710 </t> 2711 <t> 2712 The media type quality factor associated with a given type is 2713 determined by finding the media range with the highest precedence 2714 which matches that type. For example, 2715 </t> 2716 <figure><artwork type="example"> 2717 Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, 2718 text/html;level=2;q=0.4, */*;q=0.5 2719 </artwork></figure> 2720 <t> 2721 would cause the following values to be associated: 2722 </t> 2723 <texttable align="left"> 2724 <ttcol>Media Type</ttcol><ttcol>Quality Value</ttcol> 2725 <c>text/html;level=1</c> <c>1</c> 2726 <c>text/html</c> <c>0.7</c> 2727 <c>text/plain</c> <c>0.3</c> 2728 <c>image/jpeg</c> <c>0.5</c> 2729 <c>text/html;level=2</c> <c>0.4</c> 2730 <c>text/html;level=3</c> <c>0.7</c> 2731 </texttable> 2732 <t> 2733 <x:h>Note:</x:h> A user agent might be provided with a default set of quality 2734 values for certain media ranges. However, unless the user agent is 2735 a closed system which cannot interact with other rendering agents, 2736 this default set ought to be configurable by the user. 2737 </t> 2738 </section> 2739 2740 <section title="Accept-Charset" anchor="header.accept-charset"> 2741 <iref primary="true" item="Accept-Charset header field" x:for-anchor=""/> 2742 <iref primary="true" item="Header Fields" subitem="Accept-Charset" x:for-anchor=""/> 2743 <x:anchor-alias value="Accept-Charset"/> 2744 <t> 2745 The "Accept-Charset" header field can be used by user agents to 2746 indicate what character encodings are acceptable in a response 2747 payload. This field allows 2748 clients capable of understanding more comprehensive or special-purpose 2749 character encodings to signal that capability to a server which is capable of 2750 representing documents in those character encodings. 2751 </t> 2752 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Charset"/> 2753 <x:ref>Accept-Charset</x:ref> = 1#( ( <x:ref>charset</x:ref> / "*" ) 2754 [ <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> "q=" <x:ref>qvalue</x:ref> ] ) 2755 </artwork></figure> 2756 <t> 2757 Character encoding values (a.k.a., charsets) are described in 2758 <xref target="character.sets"/>. Each charset &MAY; be given an 2759 associated quality value which represents the user's preference 2760 for that charset. The default value is q=1. An example is 2761 </t> 2762 <figure><artwork type="example"> 2763 Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 2764 </artwork></figure> 2765 <t> 2766 The special value "*", if present in the Accept-Charset field, 2767 matches every character encoding which is not mentioned elsewhere in the 2768 Accept-Charset field. If no "*" is present in an Accept-Charset field, then 2769 all character encodings not explicitly mentioned get a quality value of 0. 2770 </t> 2771 <t> 2772 A request without any Accept-Charset header field implies that the user 2773 agent will accept any character encoding in response. 2774 If an Accept-Charset header field is present in a request and none of the 2775 available representations for the response have a character encoding that 2776 is listed as acceptable, the origin server &MAY; either honor the 2777 Accept-Charset header field by sending a 406 (Not Acceptable) response or 2778 disregard the Accept-Charset header field by treating the response as if 2779 it is not subject to content negotiation. 2780 </t> 2781 </section> 2782 2783 <section title="Accept-Encoding" anchor="header.accept-encoding"> 2784 <iref primary="true" item="Accept-Encoding header field" x:for-anchor=""/> 2785 <iref primary="true" item="Header Fields" subitem="Accept-Encoding" x:for-anchor=""/> 2786 <x:anchor-alias value="Accept-Encoding"/> 2787 <x:anchor-alias value="codings"/> 2788 <t> 2789 The "Accept-Encoding" header field can be used by user agents to 2790 indicate what response content-codings (<xref target="content.codings"/>) 2791 are acceptable in the response. An "identity" token is used as a synonym 2792 for "no encoding" in order to communicate when no encoding is preferred. 2793 </t> 2794 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Encoding"/><iref primary="true" item="Grammar" subitem="codings"/> 2795 <x:ref>Accept-Encoding</x:ref> = #( <x:ref>codings</x:ref> [ <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> "q=" <x:ref>qvalue</x:ref> ] ) 2796 <x:ref>codings</x:ref> = <x:ref>content-coding</x:ref> / "identity" / "*" 2797 </artwork></figure> 2798 <t> 2799 Each codings value &MAY; be given an associated quality value which 2800 represents the preference for that encoding. The default value is q=1. 2801 </t> 2802 <t> 2803 For example, 2804 </t> 2805 <figure><artwork type="example"> 2806 Accept-Encoding: compress, gzip 2807 Accept-Encoding: 2808 Accept-Encoding: * 2809 Accept-Encoding: compress;q=0.5, gzip;q=1.0 2810 Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 2811 </artwork></figure> 2812 <t> 2813 A server tests whether a content-coding for a given representation is 2814 acceptable, according to an Accept-Encoding field, using these rules: 2815 <list style="numbers"> 2816 <t>The special "*" symbol in an Accept-Encoding field matches any 2817 available content-coding not explicitly listed in the header 2818 field.</t> 2819 2820 <t>If the representation has no content-coding, then it is acceptable 2821 by default unless specifically excluded by the Accept-Encoding field 2822 stating either "identity;q=0" or "*;q=0" without a more specific 2823 entry for "identity".</t> 2824 2825 <t>If the representation's content-coding is one of the content-codings 2826 listed in the Accept-Encoding field, then it is acceptable unless 2827 it is accompanied by a qvalue of 0. (As defined in &qvalue;, a 2828 qvalue of 0 means "not acceptable".)</t> 2829 2830 <t>If multiple content-codings are acceptable, then the acceptable 2831 content-coding with the highest non-zero qvalue is preferred.</t> 2832 </list> 2833 </t> 2834 <t> 2835 An Accept-Encoding header field with a combined field-value that is empty 2836 implies that the user agent does not want any content-coding in response. 2837 If an Accept-Encoding header field is present in a request and none of the 2838 available representations for the response have a content-coding that 2839 is listed as acceptable, the origin server &SHOULD; send a response 2840 without any content-coding. 2841 </t> 2842 <t> 2843 A request without an Accept-Encoding header field implies that the user 2844 agent will accept any content-coding in response, but a representation 2845 without content-coding is preferred for compatibility with the widest 2846 variety of user agents. 2847 </t> 2848 <x:note> 2849 <t> 2850 <x:h>Note:</x:h> Most HTTP/1.0 applications do not recognize or obey qvalues 2851 associated with content-codings. This means that qvalues will not 2852 work and are not permitted with x-gzip or x-compress. 2853 </t> 2854 </x:note> 2855 </section> 2856 2857 <section title="Accept-Language" anchor="header.accept-language"> 2858 <iref primary="true" item="Accept-Language header field" x:for-anchor=""/> 2859 <iref primary="true" item="Header Fields" subitem="Accept-Language" x:for-anchor=""/> 2860 <x:anchor-alias value="Accept-Language"/> 2861 <x:anchor-alias value="language-range"/> 2862 <t> 2863 The "Accept-Language" header field can be used by user agents to 2864 indicate the set of natural languages that are preferred in the response. 2865 Language tags are defined in <xref target="language.tags"/>. 2866 </t> 2867 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Language"/><iref primary="true" item="Grammar" subitem="language-range"/> 2868 <x:ref>Accept-Language</x:ref> = 2869 1#( <x:ref>language-range</x:ref> [ <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> "q=" <x:ref>qvalue</x:ref> ] ) 2870 <x:ref>language-range</x:ref> = 2871 <language-range, defined in <xref target="RFC4647" x:fmt="," x:sec="2.1"/>> 2872 </artwork></figure> 2873 <t> 2874 Each language-range can be given an associated quality value which 2875 represents an estimate of the user's preference for the languages 2876 specified by that range. The quality value defaults to "q=1". For 2877 example, 2878 </t> 2879 <figure><artwork type="example"> 2880 Accept-Language: da, en-gb;q=0.8, en;q=0.7 2881 </artwork></figure> 2882 <t> 2883 would mean: "I prefer Danish, but will accept British English and 2884 other types of English". 2885 (see also <xref target="RFC4647" x:sec="2.3" x:fmt="of"/>) 2886 </t> 2887 <t> 2888 For matching, <xref target="RFC4647" x:sec="3" x:fmt="of"/> defines 2889 several matching schemes. Implementations can offer the most appropriate 2890 matching scheme for their requirements. 2891 </t> 2892 <x:note> 2893 <t> 2894 <x:h>Note:</x:h> The "Basic Filtering" scheme (<xref target="RFC4647" 2895 x:fmt="," x:sec="3.3.1"/>) is identical to the matching scheme that was 2896 previously defined in <xref target="RFC2616" x:fmt="of" x:sec="14.4"/>. 2897 </t> 2898 </x:note> 2899 <t> 2900 It might be contrary to the privacy expectations of the user to send 2901 an Accept-Language header field with the complete linguistic preferences of 2902 the user in every request. For a discussion of this issue, see 2903 <xref target="privacy.issues.connected.to.accept.header.fields"/>. 2904 </t> 2905 <t> 2906 As intelligibility is highly dependent on the individual user, it is 2907 recommended that client applications make the choice of linguistic 2908 preference available to the user. If the choice is not made 2909 available, then the Accept-Language header field &MUST-NOT; be given in 2910 the request. 2911 </t> 2912 <x:note> 2913 <t> 2914 <x:h>Note:</x:h> When making the choice of linguistic preference available to 2915 the user, we remind implementors of the fact that users are not 2916 familiar with the details of language matching as described above, 2917 and ought to be provided appropriate guidance. As an example, users 2918 might assume that on selecting "en-gb", they will be served any 2919 kind of English document if British English is not available. A 2920 user agent might suggest in such a case to add "en" to get the 2921 best matching behavior. 2922 </t> 2923 </x:note> 2924 </section> 2609 2925 2610 2926 <section title="Allow" anchor="header.allow"> … … 2634 2950 understand all the methods specified in order to handle them according to 2635 2951 the generic message handling rules. 2952 </t> 2953 </section> 2954 2955 2956 <section title="Content-Encoding" anchor="header.content-encoding"> 2957 <iref primary="true" item="Content-Encoding header field" x:for-anchor=""/> 2958 <iref primary="true" item="Header Fields" subitem="Content-Encoding" x:for-anchor=""/> 2959 <x:anchor-alias value="Content-Encoding"/> 2960 <t> 2961 The "Content-Encoding" header field indicates what content-codings 2962 have been applied to the representation beyond those inherent in the media 2963 type, and thus what decoding mechanisms have to be applied in order to obtain 2964 the media-type referenced by the Content-Type header field. 2965 Content-Encoding is primarily used to allow a representation to be 2966 compressed without losing the identity of its underlying media type. 2967 </t> 2968 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Encoding"/> 2969 <x:ref>Content-Encoding</x:ref> = 1#<x:ref>content-coding</x:ref> 2970 </artwork></figure> 2971 <t> 2972 Content codings are defined in <xref target="content.codings"/>. An example of its use is 2973 </t> 2974 <figure><artwork type="example"> 2975 Content-Encoding: gzip 2976 </artwork></figure> 2977 <t> 2978 The content-coding is a characteristic of the representation. 2979 Typically, the representation body is stored with this 2980 encoding and is only decoded before rendering or analogous usage. 2981 However, a transforming proxy &MAY; modify the content-coding if the 2982 new coding is known to be acceptable to the recipient, unless the 2983 "no-transform" cache-control directive is present in the message. 2984 </t> 2985 <t> 2986 If the media type includes an inherent encoding, such as a data format 2987 that is always compressed, then that encoding would not be restated as 2988 a Content-Encoding even if it happens to be the same algorithm as one 2989 of the content-codings. Such a content-coding would only be listed if, 2990 for some bizarre reason, it is applied a second time to form the 2991 representation. Likewise, an origin server might choose to publish the 2992 same payload data as multiple representations that differ only in whether 2993 the coding is defined as part of Content-Type or Content-Encoding, since 2994 some user agents will behave differently in their handling of each 2995 response (e.g., open a "Save as ..." dialog instead of automatic 2996 decompression and rendering of content). 2997 </t> 2998 <t> 2999 A representation that has a content-coding applied to it &MUST; include 3000 a Content-Encoding header field (<xref target="header.content-encoding"/>) 3001 that lists the content-coding(s) applied. 3002 </t> 3003 <t> 3004 If multiple encodings have been applied to a representation, the content 3005 codings &MUST; be listed in the order in which they were applied. 3006 Additional information about the encoding parameters &MAY; be provided 3007 by other header fields not defined by this specification. 3008 </t> 3009 <t> 3010 If the content-coding of a representation in a request message is not 3011 acceptable to the origin server, the server &SHOULD; respond with a 3012 status code of 415 (Unsupported Media Type). 3013 </t> 3014 </section> 3015 3016 <section title="Content-Language" anchor="header.content-language"> 3017 <iref primary="true" item="Content-Language header field" x:for-anchor=""/> 3018 <iref primary="true" item="Header Fields" subitem="Content-Language" x:for-anchor=""/> 3019 <x:anchor-alias value="Content-Language"/> 3020 <t> 3021 The "Content-Language" header field describes the natural 3022 language(s) of the intended audience for the representation. Note that this might 3023 not be equivalent to all the languages used within the representation. 3024 </t> 3025 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Language"/> 3026 <x:ref>Content-Language</x:ref> = 1#<x:ref>language-tag</x:ref> 3027 </artwork></figure> 3028 <t> 3029 Language tags are defined in <xref target="language.tags"/>. The primary purpose of 3030 Content-Language is to allow a user to identify and differentiate 3031 representations according to the user's own preferred language. Thus, if the 3032 body content is intended only for a Danish-literate audience, the 3033 appropriate field is 3034 </t> 3035 <figure><artwork type="example"> 3036 Content-Language: da 3037 </artwork></figure> 3038 <t> 3039 If no Content-Language is specified, the default is that the content 3040 is intended for all language audiences. This might mean that the 3041 sender does not consider it to be specific to any natural language, 3042 or that the sender does not know for which language it is intended. 3043 </t> 3044 <t> 3045 Multiple languages &MAY; be listed for content that is intended for 3046 multiple audiences. For example, a rendition of the "Treaty of 3047 Waitangi", presented simultaneously in the original Maori and English 3048 versions, would call for 3049 </t> 3050 <figure><artwork type="example"> 3051 Content-Language: mi, en 3052 </artwork></figure> 3053 <t> 3054 However, just because multiple languages are present within a representation 3055 does not mean that it is intended for multiple linguistic audiences. 3056 An example would be a beginner's language primer, such as "A First 3057 Lesson in Latin", which is clearly intended to be used by an 3058 English-literate audience. In this case, the Content-Language would 3059 properly only include "en". 3060 </t> 3061 <t> 3062 Content-Language &MAY; be applied to any media type — it is not 3063 limited to textual documents. 3064 </t> 3065 </section> 3066 3067 <section title="Content-Location" anchor="header.content-location"> 3068 <iref primary="true" item="Content-Location header field" x:for-anchor=""/> 3069 <iref primary="true" item="Header Fields" subitem="Content-Location" x:for-anchor=""/> 3070 <x:anchor-alias value="Content-Location"/> 3071 <t> 3072 The "Content-Location" header field supplies a URI that can be used 3073 as a specific identifier for the representation in this message. 3074 In other words, if one were to perform a GET on this URI at the time 3075 of this message's generation, then a 200 response would contain the 3076 same representation that is enclosed as payload in this message. 3077 </t> 3078 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Location"/> 3079 <x:ref>Content-Location</x:ref> = <x:ref>absolute-URI</x:ref> / <x:ref>partial-URI</x:ref> 3080 </artwork></figure> 3081 <t> 3082 The Content-Location value is not a replacement for the effective 3083 Request URI (&effective-request-uri;). It is representation metadata. 3084 It has the same syntax and semantics as the header field of the same name 3085 defined for MIME body parts in <xref target="RFC2557" x:fmt="of" x:sec="4"/>. 3086 However, its appearance in an HTTP message has some special implications 3087 for HTTP recipients. 3088 </t> 3089 <t> 3090 If Content-Location is included in a response message and its value 3091 is the same as the effective request URI, then the response payload 3092 &SHOULD; be considered a current representation of that resource. 3093 For a GET or HEAD request, this is the same as the default semantics 3094 when no Content-Location is provided by the server. For a state-changing 3095 request like PUT or POST, it implies that the server's response contains 3096 the new representation of that resource, thereby distinguishing it from 3097 representations that might only report about the action (e.g., "It worked!"). 3098 This allows authoring applications to update their local copies without 3099 the need for a subsequent GET request. 3100 </t> 3101 <t> 3102 If Content-Location is included in a response message and its value 3103 differs from the effective request URI, then the origin server is 3104 informing recipients that this representation has its own, presumably 3105 more specific, identifier. For a GET or HEAD request, this is an 3106 indication that the effective request URI identifies a resource that 3107 is subject to content negotiation and the selected representation for 3108 this response can also be found at the identified URI. For other 3109 methods, such a Content-Location indicates that this representation 3110 contains a report on the action's status and the same report is 3111 available (for future access with GET) at the given URI. For 3112 example, a purchase transaction made via a POST request might 3113 include a receipt document as the payload of the 200 response; 3114 the Content-Location value provides an identifier for retrieving 3115 a copy of that same receipt in the future. 3116 </t> 3117 <t> 3118 If Content-Location is included in a request message, then it &MAY; 3119 be interpreted by the origin server as an indication of where the 3120 user agent originally obtained the content of the enclosed 3121 representation (prior to any subsequent modification of the content 3122 by that user agent). In other words, the user agent is providing 3123 the same representation metadata that it received with the original 3124 representation. However, such interpretation &MUST-NOT; be used to 3125 alter the semantics of the method requested by the client. For 3126 example, if a client makes a PUT request on a negotiated resource 3127 and the origin server accepts that PUT (without redirection), then the 3128 new set of values for that resource is expected to be consistent with 3129 the one representation supplied in that PUT; the Content-Location 3130 cannot be used as a form of reverse content selection that 3131 identifies only one of the negotiated representations to be updated. 3132 If the user agent had wanted the latter semantics, it would have applied 3133 the PUT directly to the Content-Location URI. 3134 </t> 3135 <t> 3136 A Content-Location field received in a request message is transitory 3137 information that &SHOULD-NOT; be saved with other representation 3138 metadata for use in later responses. The Content-Location's value 3139 might be saved for use in other contexts, such as within source links 3140 or other metadata. 3141 </t> 3142 <t> 3143 A cache cannot assume that a representation with a Content-Location 3144 different from the URI used to retrieve it can be used to respond to 3145 later requests on that Content-Location URI. 3146 </t> 3147 <t> 3148 If the Content-Location value is a partial URI, the partial URI is 3149 interpreted relative to the effective request URI. 3150 </t> 3151 </section> 3152 3153 <section title="Content-Type" anchor="header.content-type"> 3154 <iref primary="true" item="Content-Type header field" x:for-anchor=""/> 3155 <iref primary="true" item="Header Fields" subitem="Content-Type" x:for-anchor=""/> 3156 <x:anchor-alias value="Content-Type"/> 3157 <t> 3158 The "Content-Type" header field indicates the media type of the 3159 representation. In the case of responses to the HEAD method, the media type is 3160 that which would have been sent had the request been a GET. 3161 </t> 3162 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Type"/> 3163 <x:ref>Content-Type</x:ref> = <x:ref>media-type</x:ref> 3164 </artwork></figure> 3165 <t> 3166 Media types are defined in <xref target="media.types"/>. An example of the field is 3167 </t> 3168 <figure><artwork type="example"> 3169 Content-Type: text/html; charset=ISO-8859-4 3170 </artwork></figure> 3171 <t> 3172 Further discussion of Content-Type is provided in <xref target="representation.data"/>. 2636 3173 </t> 2637 3174 </section> … … 3061 3598 </artwork></figure> 3062 3599 </section> 3063 3064 3600 </section> 3065 3601 … … 5510 6046 </section> 5511 6047 5512 <section title="Header Field Definitions" anchor="header.field.definitions3">5513 <t>5514 This section defines the syntax and semantics of HTTP/1.1 header fields5515 related to the payload of messages.5516 </t>5517 5518 <section title="Accept" anchor="header.accept">5519 <iref primary="true" item="Accept header field" x:for-anchor=""/>5520 <iref primary="true" item="Header Fields" subitem="Accept" x:for-anchor=""/>5521 <x:anchor-alias value="Accept"/>5522 <x:anchor-alias value="accept-ext"/>5523 <x:anchor-alias value="accept-params"/>5524 <x:anchor-alias value="media-range"/>5525 <t>5526 The "Accept" header field can be used by user agents to specify5527 response media types that are acceptable. Accept header fields can be used to5528 indicate that the request is specifically limited to a small set of desired5529 types, as in the case of a request for an in-line image.5530 </t>5531 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept"/><iref primary="true" item="Grammar" subitem="media-range"/><iref primary="true" item="Grammar" subitem="accept-params"/><iref primary="true" item="Grammar" subitem="accept-ext"/>5532 <x:ref>Accept</x:ref> = #( <x:ref>media-range</x:ref> [ <x:ref>accept-params</x:ref> ] )5533 5534 <x:ref>media-range</x:ref> = ( "*/*"5535 / ( <x:ref>type</x:ref> "/" "*" )5536 / ( <x:ref>type</x:ref> "/" <x:ref>subtype</x:ref> )5537 ) *( <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> <x:ref>parameter</x:ref> )5538 <x:ref>accept-params</x:ref> = <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> "q=" <x:ref>qvalue</x:ref> *( <x:ref>accept-ext</x:ref> )5539 <x:ref>accept-ext</x:ref> = <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> <x:ref>token</x:ref> [ "=" <x:ref>word</x:ref> ]5540 </artwork></figure>5541 <t>5542 The asterisk "*" character is used to group media types into ranges,5543 with "*/*" indicating all media types and "type/*" indicating all5544 subtypes of that type. The media-range &MAY; include media type5545 parameters that are applicable to that range.5546 </t>5547 <t>5548 Each media-range &MAY; be followed by one or more accept-params,5549 beginning with the "q" parameter for indicating a relative quality5550 factor. The first "q" parameter (if any) separates the media-range5551 parameter(s) from the accept-params. Quality factors allow the user5552 or user agent to indicate the relative degree of preference for that5553 media-range, using the qvalue scale from 0 to 1 (&qvalue;). The5554 default value is q=1.5555 </t>5556 <x:note>5557 <t>5558 <x:h>Note:</x:h> Use of the "q" parameter name to separate media type5559 parameters from Accept extension parameters is due to historical5560 practice. Although this prevents any media type parameter named5561 "q" from being used with a media range, such an event is believed5562 to be unlikely given the lack of any "q" parameters in the IANA5563 media type registry and the rare usage of any media type5564 parameters in Accept. Future media types are discouraged from5565 registering any parameter named "q".5566 </t>5567 </x:note>5568 <t>5569 The example5570 </t>5571 <figure><artwork type="example">5572 Accept: audio/*; q=0.2, audio/basic5573 </artwork></figure>5574 <t>5575 &SHOULD; be interpreted as "I prefer audio/basic, but send me any audio5576 type if it is the best available after an 80% mark-down in quality".5577 </t>5578 <t>5579 A request without any Accept header field implies that the user agent5580 will accept any media type in response.5581 If an Accept header field is present in a request and none of the5582 available representations for the response have a media type that is5583 listed as acceptable, the origin server &MAY; either5584 honor the Accept header field by sending a 406 (Not Acceptable) response5585 or disregard the Accept header field by treating the response as if5586 it is not subject to content negotiation.5587 </t>5588 <t>5589 A more elaborate example is5590 </t>5591 <figure><artwork type="example">5592 Accept: text/plain; q=0.5, text/html,5593 text/x-dvi; q=0.8, text/x-c5594 </artwork></figure>5595 <t>5596 Verbally, this would be interpreted as "text/html and text/x-c are5597 the preferred media types, but if they do not exist, then send the5598 text/x-dvi representation, and if that does not exist, send the text/plain5599 representation".5600 </t>5601 <t>5602 Media ranges can be overridden by more specific media ranges or5603 specific media types. If more than one media range applies to a given5604 type, the most specific reference has precedence. For example,5605 </t>5606 <figure><artwork type="example">5607 Accept: text/*, text/plain, text/plain;format=flowed, */*5608 </artwork></figure>5609 <t>5610 have the following precedence:5611 <list style="numbers">5612 <t>text/plain;format=flowed</t>5613 <t>text/plain</t>5614 <t>text/*</t>5615 <t>*/*</t>5616 </list>5617 </t>5618 <t>5619 The media type quality factor associated with a given type is5620 determined by finding the media range with the highest precedence5621 which matches that type. For example,5622 </t>5623 <figure><artwork type="example">5624 Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,5625 text/html;level=2;q=0.4, */*;q=0.55626 </artwork></figure>5627 <t>5628 would cause the following values to be associated:5629 </t>5630 <texttable align="left">5631 <ttcol>Media Type</ttcol><ttcol>Quality Value</ttcol>5632 <c>text/html;level=1</c> <c>1</c>5633 <c>text/html</c> <c>0.7</c>5634 <c>text/plain</c> <c>0.3</c>5635 <c>image/jpeg</c> <c>0.5</c>5636 <c>text/html;level=2</c> <c>0.4</c>5637 <c>text/html;level=3</c> <c>0.7</c>5638 </texttable>5639 <t>5640 <x:h>Note:</x:h> A user agent might be provided with a default set of quality5641 values for certain media ranges. However, unless the user agent is5642 a closed system which cannot interact with other rendering agents,5643 this default set ought to be configurable by the user.5644 </t>5645 </section>5646 5647 <section title="Accept-Charset" anchor="header.accept-charset">5648 <iref primary="true" item="Accept-Charset header field" x:for-anchor=""/>5649 <iref primary="true" item="Header Fields" subitem="Accept-Charset" x:for-anchor=""/>5650 <x:anchor-alias value="Accept-Charset"/>5651 <t>5652 The "Accept-Charset" header field can be used by user agents to5653 indicate what character encodings are acceptable in a response5654 payload. This field allows5655 clients capable of understanding more comprehensive or special-purpose5656 character encodings to signal that capability to a server which is capable of5657 representing documents in those character encodings.5658 </t>5659 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Charset"/>5660 <x:ref>Accept-Charset</x:ref> = 1#( ( <x:ref>charset</x:ref> / "*" )5661 [ <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> "q=" <x:ref>qvalue</x:ref> ] )5662 </artwork></figure>5663 <t>5664 Character encoding values (a.k.a., charsets) are described in5665 <xref target="character.sets"/>. Each charset &MAY; be given an5666 associated quality value which represents the user's preference5667 for that charset. The default value is q=1. An example is5668 </t>5669 <figure><artwork type="example">5670 Accept-Charset: iso-8859-5, unicode-1-1;q=0.85671 </artwork></figure>5672 <t>5673 The special value "*", if present in the Accept-Charset field,5674 matches every character encoding which is not mentioned elsewhere in the5675 Accept-Charset field. If no "*" is present in an Accept-Charset field, then5676 all character encodings not explicitly mentioned get a quality value of 0.5677 </t>5678 <t>5679 A request without any Accept-Charset header field implies that the user5680 agent will accept any character encoding in response.5681 If an Accept-Charset header field is present in a request and none of the5682 available representations for the response have a character encoding that5683 is listed as acceptable, the origin server &MAY; either honor the5684 Accept-Charset header field by sending a 406 (Not Acceptable) response or5685 disregard the Accept-Charset header field by treating the response as if5686 it is not subject to content negotiation.5687 </t>5688 </section>5689 5690 <section title="Accept-Encoding" anchor="header.accept-encoding">5691 <iref primary="true" item="Accept-Encoding header field" x:for-anchor=""/>5692 <iref primary="true" item="Header Fields" subitem="Accept-Encoding" x:for-anchor=""/>5693 <x:anchor-alias value="Accept-Encoding"/>5694 <x:anchor-alias value="codings"/>5695 <t>5696 The "Accept-Encoding" header field can be used by user agents to5697 indicate what response content-codings (<xref target="content.codings"/>)5698 are acceptable in the response. An "identity" token is used as a synonym5699 for "no encoding" in order to communicate when no encoding is preferred.5700 </t>5701 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Encoding"/><iref primary="true" item="Grammar" subitem="codings"/>5702 <x:ref>Accept-Encoding</x:ref> = #( <x:ref>codings</x:ref> [ <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> "q=" <x:ref>qvalue</x:ref> ] )5703 <x:ref>codings</x:ref> = <x:ref>content-coding</x:ref> / "identity" / "*"5704 </artwork></figure>5705 <t>5706 Each codings value &MAY; be given an associated quality value which5707 represents the preference for that encoding. The default value is q=1.5708 </t>5709 <t>5710 For example,5711 </t>5712 <figure><artwork type="example">5713 Accept-Encoding: compress, gzip5714 Accept-Encoding:5715 Accept-Encoding: *5716 Accept-Encoding: compress;q=0.5, gzip;q=1.05717 Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=05718 </artwork></figure>5719 <t>5720 A server tests whether a content-coding for a given representation is5721 acceptable, according to an Accept-Encoding field, using these rules:5722 <list style="numbers">5723 <t>The special "*" symbol in an Accept-Encoding field matches any5724 available content-coding not explicitly listed in the header5725 field.</t>5726 5727 <t>If the representation has no content-coding, then it is acceptable5728 by default unless specifically excluded by the Accept-Encoding field5729 stating either "identity;q=0" or "*;q=0" without a more specific5730 entry for "identity".</t>5731 5732 <t>If the representation's content-coding is one of the content-codings5733 listed in the Accept-Encoding field, then it is acceptable unless5734 it is accompanied by a qvalue of 0. (As defined in &qvalue;, a5735 qvalue of 0 means "not acceptable".)</t>5736 5737 <t>If multiple content-codings are acceptable, then the acceptable5738 content-coding with the highest non-zero qvalue is preferred.</t>5739 </list>5740 </t>5741 <t>5742 An Accept-Encoding header field with a combined field-value that is empty5743 implies that the user agent does not want any content-coding in response.5744 If an Accept-Encoding header field is present in a request and none of the5745 available representations for the response have a content-coding that5746 is listed as acceptable, the origin server &SHOULD; send a response5747 without any content-coding.5748 </t>5749 <t>5750 A request without an Accept-Encoding header field implies that the user5751 agent will accept any content-coding in response, but a representation5752 without content-coding is preferred for compatibility with the widest5753 variety of user agents.5754 </t>5755 <x:note>5756 <t>5757 <x:h>Note:</x:h> Most HTTP/1.0 applications do not recognize or obey qvalues5758 associated with content-codings. This means that qvalues will not5759 work and are not permitted with x-gzip or x-compress.5760 </t>5761 </x:note>5762 </section>5763 5764 <section title="Accept-Language" anchor="header.accept-language">5765 <iref primary="true" item="Accept-Language header field" x:for-anchor=""/>5766 <iref primary="true" item="Header Fields" subitem="Accept-Language" x:for-anchor=""/>5767 <x:anchor-alias value="Accept-Language"/>5768 <x:anchor-alias value="language-range"/>5769 <t>5770 The "Accept-Language" header field can be used by user agents to5771 indicate the set of natural languages that are preferred in the response.5772 Language tags are defined in <xref target="language.tags"/>.5773 </t>5774 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Language"/><iref primary="true" item="Grammar" subitem="language-range"/>5775 <x:ref>Accept-Language</x:ref> =5776 1#( <x:ref>language-range</x:ref> [ <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> "q=" <x:ref>qvalue</x:ref> ] )5777 <x:ref>language-range</x:ref> =5778 <language-range, defined in <xref target="RFC4647" x:fmt="," x:sec="2.1"/>>5779 </artwork></figure>5780 <t>5781 Each language-range can be given an associated quality value which5782 represents an estimate of the user's preference for the languages5783 specified by that range. The quality value defaults to "q=1". For5784 example,5785 </t>5786 <figure><artwork type="example">5787 Accept-Language: da, en-gb;q=0.8, en;q=0.75788 </artwork></figure>5789 <t>5790 would mean: "I prefer Danish, but will accept British English and5791 other types of English".5792 (see also <xref target="RFC4647" x:sec="2.3" x:fmt="of"/>)5793 </t>5794 <t>5795 For matching, <xref target="RFC4647" x:sec="3" x:fmt="of"/> defines5796 several matching schemes. Implementations can offer the most appropriate5797 matching scheme for their requirements.5798 </t>5799 <x:note>5800 <t>5801 <x:h>Note:</x:h> The "Basic Filtering" scheme (<xref target="RFC4647"5802 x:fmt="," x:sec="3.3.1"/>) is identical to the matching scheme that was5803 previously defined in <xref target="RFC2616" x:fmt="of" x:sec="14.4"/>.5804 </t>5805 </x:note>5806 <t>5807 It might be contrary to the privacy expectations of the user to send5808 an Accept-Language header field with the complete linguistic preferences of5809 the user in every request. For a discussion of this issue, see5810 <xref target="privacy.issues.connected.to.accept.header.fields"/>.5811 </t>5812 <t>5813 As intelligibility is highly dependent on the individual user, it is5814 recommended that client applications make the choice of linguistic5815 preference available to the user. If the choice is not made5816 available, then the Accept-Language header field &MUST-NOT; be given in5817 the request.5818 </t>5819 <x:note>5820 <t>5821 <x:h>Note:</x:h> When making the choice of linguistic preference available to5822 the user, we remind implementors of the fact that users are not5823 familiar with the details of language matching as described above,5824 and ought to be provided appropriate guidance. As an example, users5825 might assume that on selecting "en-gb", they will be served any5826 kind of English document if British English is not available. A5827 user agent might suggest in such a case to add "en" to get the5828 best matching behavior.5829 </t>5830 </x:note>5831 </section>5832 5833 <section title="Content-Encoding" anchor="header.content-encoding">5834 <iref primary="true" item="Content-Encoding header field" x:for-anchor=""/>5835 <iref primary="true" item="Header Fields" subitem="Content-Encoding" x:for-anchor=""/>5836 <x:anchor-alias value="Content-Encoding"/>5837 <t>5838 The "Content-Encoding" header field indicates what content-codings5839 have been applied to the representation beyond those inherent in the media5840 type, and thus what decoding mechanisms have to be applied in order to obtain5841 the media-type referenced by the Content-Type header field.5842 Content-Encoding is primarily used to allow a representation to be5843 compressed without losing the identity of its underlying media type.5844 </t>5845 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Encoding"/>5846 <x:ref>Content-Encoding</x:ref> = 1#<x:ref>content-coding</x:ref>5847 </artwork></figure>5848 <t>5849 Content codings are defined in <xref target="content.codings"/>. An example of its use is5850 </t>5851 <figure><artwork type="example">5852 Content-Encoding: gzip5853 </artwork></figure>5854 <t>5855 The content-coding is a characteristic of the representation.5856 Typically, the representation body is stored with this5857 encoding and is only decoded before rendering or analogous usage.5858 However, a transforming proxy &MAY; modify the content-coding if the5859 new coding is known to be acceptable to the recipient, unless the5860 "no-transform" cache-control directive is present in the message.5861 </t>5862 <t>5863 If the media type includes an inherent encoding, such as a data format5864 that is always compressed, then that encoding would not be restated as5865 a Content-Encoding even if it happens to be the same algorithm as one5866 of the content-codings. Such a content-coding would only be listed if,5867 for some bizarre reason, it is applied a second time to form the5868 representation. Likewise, an origin server might choose to publish the5869 same payload data as multiple representations that differ only in whether5870 the coding is defined as part of Content-Type or Content-Encoding, since5871 some user agents will behave differently in their handling of each5872 response (e.g., open a "Save as ..." dialog instead of automatic5873 decompression and rendering of content).5874 </t>5875 <t>5876 A representation that has a content-coding applied to it &MUST; include5877 a Content-Encoding header field (<xref target="header.content-encoding"/>)5878 that lists the content-coding(s) applied.5879 </t>5880 <t>5881 If multiple encodings have been applied to a representation, the content5882 codings &MUST; be listed in the order in which they were applied.5883 Additional information about the encoding parameters &MAY; be provided5884 by other header fields not defined by this specification.5885 </t>5886 <t>5887 If the content-coding of a representation in a request message is not5888 acceptable to the origin server, the server &SHOULD; respond with a5889 status code of 415 (Unsupported Media Type).5890 </t>5891 </section>5892 5893 <section title="Content-Language" anchor="header.content-language">5894 <iref primary="true" item="Content-Language header field" x:for-anchor=""/>5895 <iref primary="true" item="Header Fields" subitem="Content-Language" x:for-anchor=""/>5896 <x:anchor-alias value="Content-Language"/>5897 <t>5898 The "Content-Language" header field describes the natural5899 language(s) of the intended audience for the representation. Note that this might5900 not be equivalent to all the languages used within the representation.5901 </t>5902 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Language"/>5903 <x:ref>Content-Language</x:ref> = 1#<x:ref>language-tag</x:ref>5904 </artwork></figure>5905 <t>5906 Language tags are defined in <xref target="language.tags"/>. The primary purpose of5907 Content-Language is to allow a user to identify and differentiate5908 representations according to the user's own preferred language. Thus, if the5909 body content is intended only for a Danish-literate audience, the5910 appropriate field is5911 </t>5912 <figure><artwork type="example">5913 Content-Language: da5914 </artwork></figure>5915 <t>5916 If no Content-Language is specified, the default is that the content5917 is intended for all language audiences. This might mean that the5918 sender does not consider it to be specific to any natural language,5919 or that the sender does not know for which language it is intended.5920 </t>5921 <t>5922 Multiple languages &MAY; be listed for content that is intended for5923 multiple audiences. For example, a rendition of the "Treaty of5924 Waitangi", presented simultaneously in the original Maori and English5925 versions, would call for5926 </t>5927 <figure><artwork type="example">5928 Content-Language: mi, en5929 </artwork></figure>5930 <t>5931 However, just because multiple languages are present within a representation5932 does not mean that it is intended for multiple linguistic audiences.5933 An example would be a beginner's language primer, such as "A First5934 Lesson in Latin", which is clearly intended to be used by an5935 English-literate audience. In this case, the Content-Language would5936 properly only include "en".5937 </t>5938 <t>5939 Content-Language &MAY; be applied to any media type — it is not5940 limited to textual documents.5941 </t>5942 </section>5943 5944 <section title="Content-Location" anchor="header.content-location">5945 <iref primary="true" item="Content-Location header field" x:for-anchor=""/>5946 <iref primary="true" item="Header Fields" subitem="Content-Location" x:for-anchor=""/>5947 <x:anchor-alias value="Content-Location"/>5948 <t>5949 The "Content-Location" header field supplies a URI that can be used5950 as a specific identifier for the representation in this message.5951 In other words, if one were to perform a GET on this URI at the time5952 of this message's generation, then a 200 response would contain the5953 same representation that is enclosed as payload in this message.5954 </t>5955 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Location"/>5956 <x:ref>Content-Location</x:ref> = <x:ref>absolute-URI</x:ref> / <x:ref>partial-URI</x:ref>5957 </artwork></figure>5958 <t>5959 The Content-Location value is not a replacement for the effective5960 Request URI (&effective-request-uri;). It is representation metadata.5961 It has the same syntax and semantics as the header field of the same name5962 defined for MIME body parts in <xref target="RFC2557" x:fmt="of" x:sec="4"/>.5963 However, its appearance in an HTTP message has some special implications5964 for HTTP recipients.5965 </t>5966 <t>5967 If Content-Location is included in a response message and its value5968 is the same as the effective request URI, then the response payload5969 &SHOULD; be considered a current representation of that resource.5970 For a GET or HEAD request, this is the same as the default semantics5971 when no Content-Location is provided by the server. For a state-changing5972 request like PUT or POST, it implies that the server's response contains5973 the new representation of that resource, thereby distinguishing it from5974 representations that might only report about the action (e.g., "It worked!").5975 This allows authoring applications to update their local copies without5976 the need for a subsequent GET request.5977 </t>5978 <t>5979 If Content-Location is included in a response message and its value5980 differs from the effective request URI, then the origin server is5981 informing recipients that this representation has its own, presumably5982 more specific, identifier. For a GET or HEAD request, this is an5983 indication that the effective request URI identifies a resource that5984 is subject to content negotiation and the selected representation for5985 this response can also be found at the identified URI. For other5986 methods, such a Content-Location indicates that this representation5987 contains a report on the action's status and the same report is5988 available (for future access with GET) at the given URI. For5989 example, a purchase transaction made via a POST request might5990 include a receipt document as the payload of the 200 response;5991 the Content-Location value provides an identifier for retrieving5992 a copy of that same receipt in the future.5993 </t>5994 <t>5995 If Content-Location is included in a request message, then it &MAY;5996 be interpreted by the origin server as an indication of where the5997 user agent originally obtained the content of the enclosed5998 representation (prior to any subsequent modification of the content5999 by that user agent). In other words, the user agent is providing6000 the same representation metadata that it received with the original6001 representation. However, such interpretation &MUST-NOT; be used to6002 alter the semantics of the method requested by the client. For6003 example, if a client makes a PUT request on a negotiated resource6004 and the origin server accepts that PUT (without redirection), then the6005 new set of values for that resource is expected to be consistent with6006 the one representation supplied in that PUT; the Content-Location6007 cannot be used as a form of reverse content selection that6008 identifies only one of the negotiated representations to be updated.6009 If the user agent had wanted the latter semantics, it would have applied6010 the PUT directly to the Content-Location URI.6011 </t>6012 <t>6013 A Content-Location field received in a request message is transitory6014 information that &SHOULD-NOT; be saved with other representation6015 metadata for use in later responses. The Content-Location's value6016 might be saved for use in other contexts, such as within source links6017 or other metadata.6018 </t>6019 <t>6020 A cache cannot assume that a representation with a Content-Location6021 different from the URI used to retrieve it can be used to respond to6022 later requests on that Content-Location URI.6023 </t>6024 <t>6025 If the Content-Location value is a partial URI, the partial URI is6026 interpreted relative to the effective request URI.6027 </t>6028 </section>6029 6030 <section title="Content-Type" anchor="header.content-type">6031 <iref primary="true" item="Content-Type header field" x:for-anchor=""/>6032 <iref primary="true" item="Header Fields" subitem="Content-Type" x:for-anchor=""/>6033 <x:anchor-alias value="Content-Type"/>6034 <t>6035 The "Content-Type" header field indicates the media type of the6036 representation. In the case of responses to the HEAD method, the media type is6037 that which would have been sent had the request been a GET.6038 </t>6039 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Type"/>6040 <x:ref>Content-Type</x:ref> = <x:ref>media-type</x:ref>6041 </artwork></figure>6042 <t>6043 Media types are defined in <xref target="media.types"/>. An example of the field is6044 </t>6045 <figure><artwork type="example">6046 Content-Type: text/html; charset=ISO-8859-46047 </artwork></figure>6048 <t>6049 Further discussion of Content-Type is provided in <xref target="representation.data"/>.6050 </t>6051 </section>6052 6053 </section>6054 6048 6055 6049 <section title="IANA Considerations" anchor="IANA.considerations3"> -
draft-ietf-httpbis/latest/p4-conditional.html
r1643 r1645 896 896 </div> 897 897 <h3 id="rfc.section.2.3.3"><a href="#rfc.section.2.3.3">2.3.3</a> <a id="example.entity.tag.vs.conneg" href="#example.entity.tag.vs.conneg">Example: Entity-tags varying on Content-Negotiated Resources</a></h3> 898 <p id="rfc.section.2.3.3.p.1">Consider a resource that is subject to content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Appendix D. 4</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), and where the representations returned upon a GET request vary based on the Accept-Encoding request header field (<a href="p2-semantics.html#header.accept-encoding" title="Accept-Encoding">Appendix D.5.3</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>):898 <p id="rfc.section.2.3.3.p.1">Consider a resource that is subject to content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Appendix D.3</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), and where the representations returned upon a GET request vary based on the Accept-Encoding request header field (<a href="p2-semantics.html#header.accept-encoding" title="Accept-Encoding">Section 7.3</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>): 899 899 </p> 900 900 <div id="rfc.figure.u.6"></div> … … 1123 1123 as if it were the payload of a 200 response. The 304 response <em class="bcp14">MUST NOT</em> contain a message-body, and thus is always terminated by the first empty line after the header fields. 1124 1124 </p> 1125 <p id="rfc.section.4.1.p.2">A 304 response <em class="bcp14">MUST</em> include a Date header field (<a href="p2-semantics.html#header.date" title="Date">Section 7. 2</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) unless the origin server does not have a clock that can provide a reasonable approximation of the current time. If a 2001125 <p id="rfc.section.4.1.p.2">A 304 response <em class="bcp14">MUST</em> include a Date header field (<a href="p2-semantics.html#header.date" title="Date">Section 7.10</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) unless the origin server does not have a clock that can provide a reasonable approximation of the current time. If a 200 1126 1126 response to the same request would have included any of the header fields Cache-Control, Content-Location, ETag, Expires, 1127 1127 or Vary, then those same header fields <em class="bcp14">MUST</em> be sent in a 304 response. … … 1425 1425 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1.2</a>, <a href="#rfc.xref.Part2.2">1.2</a>, <a href="#rfc.xref.Part2.3">2.3.3</a>, <a href="#rfc.xref.Part2.4">2.3.3</a>, <a href="#rfc.xref.Part2.5">4.1</a>, <a href="#Part2"><b>8.1</b></a><ul> 1426 1426 <li><em>Section 6.1</em> <a href="#rfc.xref.Part2.2">1.2</a></li> 1427 <li><em>Section 7. 2</em> <a href="#rfc.xref.Part2.5">4.1</a></li>1428 <li><em> Appendix D.4</em> <a href="#rfc.xref.Part2.3">2.3.3</a></li>1429 <li><em>Appendix D. 5.3</em> <a href="#rfc.xref.Part2.4">2.3.3</a></li>1427 <li><em>Section 7.3</em> <a href="#rfc.xref.Part2.4">2.3.3</a></li> 1428 <li><em>Section 7.10</em> <a href="#rfc.xref.Part2.5">4.1</a></li> 1429 <li><em>Appendix D.3</em> <a href="#rfc.xref.Part2.3">2.3.3</a></li> 1430 1430 </ul> 1431 1431 </li> -
draft-ietf-httpbis/latest/p6-cache.html
r1643 r1645 987 987 <li>HTTP/1.1 requires origin servers to send a Date header field, if possible, with every response, giving the time at which the 988 988 response was generated. The term "date_value" denotes the value of the Date header field, in a form appropriate for arithmetic 989 operations. See <a href="p2-semantics.html#header.date" title="Date">Section 7. 2</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for the definition of the Date header field, and for requirements regarding responses without it.989 operations. See <a href="p2-semantics.html#header.date" title="Date">Section 7.10</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for the definition of the Date header field, and for requirements regarding responses without it. 990 990 </li> 991 991 </ul> … … 2185 2185 <li><em>Section 4</em> <a href="#rfc.xref.Part2.4">2.3.1.1</a></li> 2186 2186 <li><em>Section 6.1</em> <a href="#rfc.xref.Part2.1">1.4.2</a>, <a href="#rfc.xref.Part2.7">3.3</a></li> 2187 <li><em>Section 7. 2</em> <a href="#rfc.xref.Part2.5">2.3.2</a></li>2187 <li><em>Section 7.10</em> <a href="#rfc.xref.Part2.5">2.3.2</a></li> 2188 2188 </ul> 2189 2189 </li>
Note: See TracChangeset
for help on using the changeset viewer.