Changeset 1644
- Timestamp:
- 30/03/12 15:28:57 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 4 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r1643 r1644 487 487 <link rel="Chapter" title="4 Status Codes" href="#rfc.section.4"> 488 488 <link rel="Chapter" title="5 Representation" href="#rfc.section.5"> 489 <link rel="Chapter" title="6 CommonProtocol Parameters" href="#rfc.section.6">489 <link rel="Chapter" title="6 Protocol Parameters" href="#rfc.section.6"> 490 490 <link rel="Chapter" title="7 Header Field Definitions" href="#rfc.section.7"> 491 491 <link rel="Chapter" title="8 IANA Considerations" href="#rfc.section.8"> … … 691 691 </ul> 692 692 </li> 693 <li>6. <a href="# common.protocol.parameters">CommonProtocol Parameters</a><ul>693 <li>6. <a href="#protocol.parameters">Protocol Parameters</a><ul> 694 694 <li>6.1 <a href="#http.date">Date/Time Formats</a></li> 695 695 <li>6.2 <a href="#product.tokens">Product Tokens</a></li> 696 <li>6.3 <a href="#character.sets">Character Encodings (charset)</a></li> 697 <li>6.4 <a href="#content.codings">Content Codings</a><ul> 698 <li>6.4.1 <a href="#content.coding.registry">Content Coding Registry</a></li> 699 </ul> 700 </li> 701 <li>6.5 <a href="#media.types">Media Types</a><ul> 702 <li>6.5.1 <a href="#canonicalization.and.text.defaults">Canonicalization and Text Defaults</a></li> 703 <li>6.5.2 <a href="#multipart.types">Multipart Types</a></li> 704 </ul> 705 </li> 706 <li>6.6 <a href="#language.tags">Language Tags</a></li> 696 707 </ul> 697 708 </li> … … 756 767 </li> 757 768 <li>D. <a href="#rfc.section.D">THE TEXT FORMERLY KNOWN AS PART3</a><ul> 758 <li>D.1 <a href="#protocol.parameters">Protocol Parameters</a><ul> 759 <li>D.1.1 <a href="#character.sets">Character Encodings (charset)</a></li> 760 <li>D.1.2 <a href="#content.codings">Content Codings</a><ul> 761 <li>D.1.2.1 <a href="#content.coding.registry">Content Coding Registry</a></li> 762 </ul> 763 </li> 764 <li>D.1.3 <a href="#media.types">Media Types</a><ul> 765 <li>D.1.3.1 <a href="#canonicalization.and.text.defaults">Canonicalization and Text Defaults</a></li> 766 <li>D.1.3.2 <a href="#multipart.types">Multipart Types</a></li> 767 </ul> 768 </li> 769 <li>D.1.4 <a href="#language.tags">Language Tags</a></li> 769 <li>D.1 <a href="#payload">Payload</a><ul> 770 <li>D.1.1 <a href="#payload.header.fields">Payload Header Fields</a></li> 771 <li>D.1.2 <a href="#payload.body">Payload Body</a></li> 770 772 </ul> 771 773 </li> 772 <li>D.2 <a href="# payload">Payload</a><ul>773 <li>D.2.1 <a href="# payload.header.fields">PayloadHeader Fields</a></li>774 <li>D.2.2 <a href="# payload.body">Payload Body</a></li>774 <li>D.2 <a href="#representation3">Representation</a><ul> 775 <li>D.2.1 <a href="#representation.header.fields">Representation Header Fields</a></li> 776 <li>D.2.2 <a href="#representation.data">Representation Data</a></li> 775 777 </ul> 776 778 </li> 777 <li>D.3 <a href="# representation3">Representation</a><ul>778 <li>D.3.1 <a href="# representation.header.fields">Representation Header Fields</a></li>779 <li>D.3.2 <a href="# representation.data">Representation Data</a></li>779 <li>D.3 <a href="#content.negotiation">Content Negotiation</a><ul> 780 <li>D.3.1 <a href="#server-driven.negotiation">Server-driven Negotiation</a></li> 781 <li>D.3.2 <a href="#agent-driven.negotiation">Agent-driven Negotiation</a></li> 780 782 </ul> 781 783 </li> 782 <li>D.4 <a href="#content.negotiation">Content Negotiation</a><ul> 783 <li>D.4.1 <a href="#server-driven.negotiation">Server-driven Negotiation</a></li> 784 <li>D.4.2 <a href="#agent-driven.negotiation">Agent-driven Negotiation</a></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> 785 793 </ul> 786 794 </li> 787 <li>D.5 <a href="#header.field.definitions3">Header Field Definitions</a><ul> 788 <li>D.5.1 <a href="#header.accept">Accept</a></li> 789 <li>D.5.2 <a href="#header.accept-charset">Accept-Charset</a></li> 790 <li>D.5.3 <a href="#header.accept-encoding">Accept-Encoding</a></li> 791 <li>D.5.4 <a href="#header.accept-language">Accept-Language</a></li> 792 <li>D.5.5 <a href="#header.content-encoding">Content-Encoding</a></li> 793 <li>D.5.6 <a href="#header.content-language">Content-Language</a></li> 794 <li>D.5.7 <a href="#header.content-location">Content-Location</a></li> 795 <li>D.5.8 <a href="#header.content-type">Content-Type</a></li> 795 <li>D.5 <a href="#IANA.considerations3">IANA Considerations</a><ul> 796 <li>D.5.1 <a href="#content.coding.registration">Content Coding Registry</a></li> 796 797 </ul> 797 798 </li> 798 <li>D.6 <a href="# IANA.considerations3">IANAConsiderations</a><ul>799 <li>D.6.1 <a href="# content.coding.registration">Content Coding Registry</a></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 801 </ul> 801 802 </li> 802 <li>D.7 <a href="#security.considerations3">Security Considerations</a><ul> 803 <li>D.7.1 <a href="#privacy.issues.connected.to.accept.header.fields">Privacy Issues Connected to Accept Header Fields</a></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> 804 811 </ul> 805 812 </li> 806 <li>D.8 <a href="#differences.between.http.and.mime">Differences between HTTP and MIME</a><ul> 807 <li>D.8.1 <a href="#mime-version">MIME-Version</a></li> 808 <li>D.8.2 <a href="#conversion.to.canonical.form">Conversion to Canonical Form</a></li> 809 <li>D.8.3 <a href="#conversion.of.date.formats">Conversion of Date Formats</a></li> 810 <li>D.8.4 <a href="#introduction.of.content-encoding">Introduction of Content-Encoding</a></li> 811 <li>D.8.5 <a href="#no.content-transfer-encoding">No Content-Transfer-Encoding</a></li> 812 <li>D.8.6 <a href="#introduction.of.transfer-encoding">Introduction of Transfer-Encoding</a></li> 813 <li>D.8.7 <a href="#mhtml.line.length">MHTML and Line Length Limitations</a></li> 814 </ul> 815 </li> 816 <li>D.9 <a href="#additional.features">Additional Features</a></li> 817 <li>D.10 <a href="#changes.from.rfc.2616-3">Changes from RFC 2616</a></li> 818 <li>D.11 <a href="#change.log3">Change Log (to be removed by RFC Editor before publication)</a><ul> 819 <li>D.11.1 <a href="#rfc.section.D.11.1">Since RFC 2616</a></li> 820 <li>D.11.2 <a href="#rfc.section.D.11.2">Since draft-ietf-httpbis-p3-payload-00</a></li> 821 <li>D.11.3 <a href="#rfc.section.D.11.3">Since draft-ietf-httpbis-p3-payload-01</a></li> 822 <li>D.11.4 <a href="#changes.3.since.02">Since draft-ietf-httpbis-p3-payload-02</a></li> 823 <li>D.11.5 <a href="#changes.3.since.03">Since draft-ietf-httpbis-p3-payload-03</a></li> 824 <li>D.11.6 <a href="#changes.3.since.04">Since draft-ietf-httpbis-p3-payload-04</a></li> 825 <li>D.11.7 <a href="#changes.3.since.05">Since draft-ietf-httpbis-p3-payload-05</a></li> 826 <li>D.11.8 <a href="#changes.3.since.06">Since draft-ietf-httpbis-p3-payload-06</a></li> 827 <li>D.11.9 <a href="#changes.3.since.07">Since draft-ietf-httpbis-p3-payload-07</a></li> 828 <li>D.11.10 <a href="#changes.3.since.08">Since draft-ietf-httpbis-p3-payload-08</a></li> 829 <li>D.11.11 <a href="#changes.3.since.09">Since draft-ietf-httpbis-p3-payload-09</a></li> 830 <li>D.11.12 <a href="#changes.3.since.10">Since draft-ietf-httpbis-p3-payload-10</a></li> 831 <li>D.11.13 <a href="#changes.3.since.11">Since draft-ietf-httpbis-p3-payload-11</a></li> 832 <li>D.11.14 <a href="#changes.3.since.12">Since draft-ietf-httpbis-p3-payload-12</a></li> 833 <li>D.11.15 <a href="#changes.3.since.13">Since draft-ietf-httpbis-p3-payload-13</a></li> 834 <li>D.11.16 <a href="#changes.3.since.14">Since draft-ietf-httpbis-p3-payload-14</a></li> 835 <li>D.11.17 <a href="#changes.3.since.15">Since draft-ietf-httpbis-p3-payload-15</a></li> 836 <li>D.11.18 <a href="#changes.3.since.16">Since draft-ietf-httpbis-p3-payload-16</a></li> 837 <li>D.11.19 <a href="#changes.3.since.17">Since draft-ietf-httpbis-p3-payload-17</a></li> 838 <li>D.11.20 <a href="#changes.3.since.18">Since draft-ietf-httpbis-p3-payload-18</a></li> 839 <li>D.11.21 <a href="#changes.3.since.19">Since draft-ietf-httpbis-p3-payload-19</a></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> 840 837 </ul> 841 838 </li> … … 1061 1058 a Location header field (see <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section 7.5</a>). 1062 1059 </p> 1063 <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. 5.7</a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.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. 1064 1061 </p> 1065 1062 <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 … … 1224 1221 double quotes will likely cause unnecessary confusion. 1225 1222 </p> 1226 <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. 5.8</a>). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing1223 <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 existing 1227 1224 parser components. When allowing both forms, the meaning of a parameter value ought to be independent of the syntax used for 1228 it (for an example, see the notes on parameter handling for media types in <a href="#media.types" title="Media Types"> Appendix D.1.3</a>).1225 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>). 1229 1226 </p> 1230 1227 <p id="rfc.section.3.1.p.9">Authors of specifications defining new header fields are advised to consider documenting: </p> … … 1281 1278 <tr> 1282 1279 <td class="left">Accept</td> 1283 <td class="left"><a href="#header.accept" id="rfc.xref.header.accept.1" title="Accept">Appendix D. 5.1</a></td>1280 <td class="left"><a href="#header.accept" id="rfc.xref.header.accept.1" title="Accept">Appendix D.4.1</a></td> 1284 1281 </tr> 1285 1282 <tr> 1286 1283 <td class="left">Accept-Charset</td> 1287 <td class="left"><a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Appendix D. 5.2</a></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> 1288 1285 </tr> 1289 1286 <tr> 1290 1287 <td class="left">Accept-Encoding</td> 1291 <td class="left"><a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.1" title="Accept-Encoding">Appendix D. 5.3</a></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> 1292 1289 </tr> 1293 1290 <tr> 1294 1291 <td class="left">Accept-Language</td> 1295 <td class="left"><a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Appendix D. 5.4</a></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> 1296 1293 </tr> 1297 1294 <tr> … … 1437 1434 </ul> 1438 1435 <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 1439 media type (<a href="#header.content-type" id="rfc.xref.header.content-type.2" title="Content-Type">Appendix D. 5.8</a>).1436 media type (<a href="#header.content-type" id="rfc.xref.header.content-type.2" title="Content-Type">Appendix D.4.8</a>). 1440 1437 </p> 1441 1438 <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> … … 1816 1813 </li> 1817 1814 <li> 1818 <p>Redirection offering a choice of matching resources for use by agent-driven content negotiation (<a href="#agent-driven.negotiation" title="Agent-driven Negotiation">Appendix D. 4.2</a>). This is status code 300 (Multiple Choices).1815 <p>Redirection offering a choice of matching resources for use by agent-driven content negotiation (<a href="#agent-driven.negotiation" title="Agent-driven Negotiation">Appendix D.3.2</a>). This is status code 300 (Multiple Choices). 1819 1816 </p> 1820 1817 </li> … … 1848 1845 <h3 id="rfc.section.4.5.1"><a href="#rfc.section.4.5.1">4.5.1</a> <a id="status.300" href="#status.300">300 Multiple Choices</a></h3> 1849 1846 <p id="rfc.section.4.5.1.p.1">The target resource has more than one representation, each with its own specific location, and agent-driven negotiation information 1850 (<a href="#content.negotiation" title="Content Negotiation">Appendix D. 4</a>) is being provided so that the user (or user agent) can select a preferred representation by redirecting its request to that1847 (<a href="#content.negotiation" title="Content Negotiation">Appendix D.3</a>) is being provided so that the user (or user agent) can select a preferred representation by redirecting its request to that 1851 1848 location. 1852 1849 </p> … … 2151 2148 cache invalidation.]</span> 2152 2149 </p> 2153 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id=" common.protocol.parameters" href="#common.protocol.parameters">CommonProtocol Parameters</a></h1>2150 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1> 2154 2151 <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="http.date" href="#http.date">Date/Time Formats</a></h2> 2155 2152 <p id="rfc.section.6.1.p.1">HTTP applications have historically allowed three different formats for date/time stamps. However, the preferred format is … … 2250 2247 </pre><p id="rfc.section.6.2.p.5">Product tokens <em class="bcp14">SHOULD</em> be short and to the point. They <em class="bcp14">MUST NOT</em> be used for advertising or other non-essential information. Although any token octet <em class="bcp14">MAY</em> appear in a product-version, this token <em class="bcp14">SHOULD</em> only be used for a version identifier (i.e., successive versions of the same product <em class="bcp14">SHOULD</em> only differ in the product-version portion of the product value). 2251 2248 </p> 2249 <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a> <a id="character.sets" href="#character.sets">Character Encodings (charset)</a></h2> 2250 <p id="rfc.section.6.3.p.1">HTTP uses charset names to indicate the character encoding of a textual representation.</p> 2251 <div id="rule.charset"> 2252 <p id="rfc.section.6.3.p.2"> A character encoding is identified by a case-insensitive token. The complete set of tokens is defined by the IANA Character 2253 Set registry (<<a href="http://www.iana.org/assignments/character-sets">http://www.iana.org/assignments/character-sets</a>>). 2254 </p> 2255 </div> 2256 <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.21"></span> <a href="#rule.charset" class="smpl">charset</a> = <a href="#core.rules" class="smpl">token</a> 2257 </pre><p id="rfc.section.6.3.p.4">Although HTTP allows an arbitrary token to be used as a charset value, any token that has a predefined value within the IANA 2258 Character Set registry <em class="bcp14">MUST</em> represent the character encoding defined by that registry. Applications <em class="bcp14">SHOULD</em> limit their use of character encodings to those defined within the IANA registry. 2259 </p> 2260 <p id="rfc.section.6.3.p.5">HTTP uses charset in two contexts: within an Accept-Charset request header field (in which the charset value is an unquoted 2261 token) and as the value of a parameter in a Content-Type header field (within a request or response), in which case the parameter 2262 value of the charset parameter can be quoted. 2263 </p> 2264 <p id="rfc.section.6.3.p.6">Implementors need to be aware of IETF character set requirements <a href="#RFC3629" id="rfc.xref.RFC3629.1"><cite title="UTF-8, a transformation format of ISO 10646">[RFC3629]</cite></a> <a href="#RFC2277" id="rfc.xref.RFC2277.1"><cite title="IETF Policy on Character Sets and Languages">[RFC2277]</cite></a>. 2265 </p> 2266 <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a> <a id="content.codings" href="#content.codings">Content Codings</a></h2> 2267 <p id="rfc.section.6.4.p.1">Content coding values indicate an encoding transformation that has been or can be applied to a representation. Content codings 2268 are primarily used to allow a representation to be compressed or otherwise usefully transformed without losing the identity 2269 of its underlying media type and without loss of information. Frequently, the representation is stored in coded form, transmitted 2270 directly, and only decoded by the recipient. 2271 </p> 2272 <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 decoding 2274 mechanism will be required to remove the encoding. 2275 </p> 2276 <p id="rfc.section.6.4.p.4">compress<span id="rfc.iref.c.3"></span><span id="rfc.iref.c.4"></span> 2277 </p> 2278 <ul class="empty"> 2279 <li>See <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 4.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.39"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 2280 </li> 2281 </ul> 2282 <p id="rfc.section.6.4.p.5">deflate<span id="rfc.iref.d.2"></span><span id="rfc.iref.c.5"></span> 2283 </p> 2284 <ul class="empty"> 2285 <li>See <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 4.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.40"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 2286 </li> 2287 </ul> 2288 <p id="rfc.section.6.4.p.6">gzip<span id="rfc.iref.g.23"></span><span id="rfc.iref.c.6"></span> 2289 </p> 2290 <ul class="empty"> 2291 <li>See <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 4.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.41"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 2292 </li> 2293 </ul> 2294 <h3 id="rfc.section.6.4.1"><a href="#rfc.section.6.4.1">6.4.1</a> <a id="content.coding.registry" href="#content.coding.registry">Content Coding Registry</a></h3> 2295 <p id="rfc.section.6.4.1.p.1">The HTTP Content Coding Registry defines the name space for the content coding names.</p> 2296 <p id="rfc.section.6.4.1.p.2">Registrations <em class="bcp14">MUST</em> include the following fields: 2297 </p> 2298 <ul> 2299 <li>Name</li> 2300 <li>Description</li> 2301 <li>Pointer to specification text</li> 2302 </ul> 2303 <p id="rfc.section.6.4.1.p.3">Names of content codings <em class="bcp14">MUST NOT</em> overlap with names of transfer codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 4</a> of <a href="#Part1" id="rfc.xref.Part1.42"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), unless the encoding transformation is identical (as is the case for the compression codings defined in <a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.43"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 2304 </p> 2305 <p id="rfc.section.6.4.1.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.3"><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 content coding defined in this section. 2306 </p> 2307 <p id="rfc.section.6.4.1.p.5">The registry itself is maintained at <<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>>. 2308 </p> 2309 <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. 2311 </p> 2312 <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> ) 2313 <a href="#media.types" class="smpl">type</a> = <a href="#core.rules" class="smpl">token</a> 2314 <a href="#media.types" class="smpl">subtype</a> = <a href="#core.rules" class="smpl">token</a> 2315 </pre><div id="rule.parameter"> 2316 <p id="rfc.section.6.5.p.3"> The type/subtype <em class="bcp14">MAY</em> be followed by parameters in the form of attribute/value pairs. 2317 </p> 2318 </div> 2319 <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.27"></span><span id="rfc.iref.g.28"></span><span id="rfc.iref.g.29"></span> <a href="#rule.parameter" class="smpl">parameter</a> = <a href="#rule.parameter" class="smpl">attribute</a> "=" <a href="#rule.parameter" class="smpl">value</a> 2320 <a href="#rule.parameter" class="smpl">attribute</a> = <a href="#core.rules" class="smpl">token</a> 2321 <a href="#rule.parameter" class="smpl">value</a> = <a href="#core.rules" class="smpl">word</a> 2322 </pre><p id="rfc.section.6.5.p.5">The type, subtype, and parameter attribute names are case-insensitive. Parameter values might or might not be case-sensitive, 2323 depending on the semantics of the parameter name. The presence or absence of a parameter might be significant to the processing 2324 of a media-type, depending on its definition within the media type registry. 2325 </p> 2326 <p id="rfc.section.6.5.p.6">A parameter value that matches the <a href="#core.rules" class="smpl">token</a> production can be transmitted as either a token or within a quoted-string. The quoted and unquoted values are equivalent. 2327 </p> 2328 <p id="rfc.section.6.5.p.7">Note that some older HTTP applications do not recognize media type parameters. When sending data to older HTTP applications, 2329 implementations <em class="bcp14">SHOULD</em> only use media type parameters when they are required by that type/subtype definition. 2330 </p> 2331 <p id="rfc.section.6.5.p.8">Media-type values are registered with the Internet Assigned Number Authority (IANA). The media type registration process is 2332 outlined in <a href="#RFC4288" id="rfc.xref.RFC4288.1"><cite title="Media Type Specifications and Registration Procedures">[RFC4288]</cite></a>. Use of non-registered media types is discouraged. 2333 </p> 2334 <h3 id="rfc.section.6.5.1"><a href="#rfc.section.6.5.1">6.5.1</a> <a id="canonicalization.and.text.defaults" href="#canonicalization.and.text.defaults">Canonicalization and Text Defaults</a></h3> 2335 <p id="rfc.section.6.5.1.p.1">Internet media types are registered with a canonical form. A representation transferred via HTTP messages <em class="bcp14">MUST</em> be in the appropriate canonical form prior to its transmission except for "text" types, as defined in the next paragraph. 2336 </p> 2337 <p id="rfc.section.6.5.1.p.2">When in canonical form, media subtypes of the "text" type use CRLF as the text line break. HTTP relaxes this requirement and 2338 allows the transport of text media with plain CR or LF alone representing a line break when it is done consistently for an 2339 entire representation. HTTP applications <em class="bcp14">MUST</em> accept CRLF, bare CR, and bare LF as indicating a line break in text media received via HTTP. In addition, if the text is 2340 in a character encoding that does not use octets 13 and 10 for CR and LF respectively, as is the case for some multi-byte 2341 character encodings, HTTP allows the use of whatever octet sequences are defined by that character encoding to represent the 2342 equivalent of CR and LF for line breaks. This flexibility regarding line breaks applies only to text media in the payload 2343 body; a bare CR or LF <em class="bcp14">MUST NOT</em> be substituted for CRLF within any of the HTTP control structures (such as header fields and multipart boundaries). 2344 </p> 2345 <p id="rfc.section.6.5.1.p.3">If a representation is encoded with a content-coding, the underlying data <em class="bcp14">MUST</em> be in a form defined above prior to being encoded. 2346 </p> 2347 <h3 id="rfc.section.6.5.2"><a href="#rfc.section.6.5.2">6.5.2</a> <a id="multipart.types" href="#multipart.types">Multipart Types</a></h3> 2348 <p id="rfc.section.6.5.2.p.1">MIME provides for a number of "multipart" types — encapsulations of one or more representations within a single message body. 2349 All multipart types share a common syntax, as defined in <a href="http://tools.ietf.org/html/rfc2046#section-5.1.1">Section 5.1.1</a> of <a href="#RFC2046" id="rfc.xref.RFC2046.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, and <em class="bcp14">MUST</em> include a boundary parameter as part of the media type value. The message body is itself a protocol element and <em class="bcp14">MUST</em> therefore use only CRLF to represent line breaks between body-parts. 2350 </p> 2351 <p id="rfc.section.6.5.2.p.2">In general, HTTP treats a multipart message body no differently than any other media type: strictly as payload. HTTP does 2352 not use the multipart boundary as an indicator of message body length. In all other respects, an HTTP user agent <em class="bcp14">SHOULD</em> follow the same or similar behavior as a MIME user agent would upon receipt of a multipart type. The MIME header fields within 2353 each body-part of a multipart message body do not have any significance to HTTP beyond that defined by their MIME semantics. 2354 </p> 2355 <p id="rfc.section.6.5.2.p.3">If an application receives an unrecognized multipart subtype, the application <em class="bcp14">MUST</em> treat it as being equivalent to "multipart/mixed". 2356 </p> 2357 <div class="note" id="rfc.section.6.5.2.p.4"> 2358 <p> <b>Note:</b> The "multipart/form-data" type has been specifically defined for carrying form data suitable for processing via the POST request 2359 method, as described in <a href="#RFC2388" id="rfc.xref.RFC2388.1"><cite title="Returning Values from Forms: multipart/form-data">[RFC2388]</cite></a>. 2360 </p> 2361 </div> 2362 <h2 id="rfc.section.6.6"><a href="#rfc.section.6.6">6.6</a> <a id="language.tags" href="#language.tags">Language Tags</a></h2> 2363 <p id="rfc.section.6.6.p.1">A language tag, as defined in <a href="#RFC5646" id="rfc.xref.RFC5646.1"><cite title="Tags for Identifying Languages">[RFC5646]</cite></a>, identifies a natural language spoken, written, or otherwise conveyed by human beings for communication of information to 2364 other human beings. Computer languages are explicitly excluded. HTTP uses language tags within the Accept-Language and Content-Language 2365 fields. 2366 </p> 2367 <p id="rfc.section.6.6.p.2">In summary, a language tag is composed of one or more parts: A primary language subtag followed by a possibly empty series 2368 of subtags: 2369 </p> 2370 <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.30"></span> <a href="#language.tags" class="smpl">language-tag</a> = <Language-Tag, defined in <a href="#RFC5646" id="rfc.xref.RFC5646.2"><cite title="Tags for Identifying Languages">[RFC5646]</cite></a>, <a href="http://tools.ietf.org/html/rfc5646#section-2.1">Section 2.1</a>> 2371 </pre><p id="rfc.section.6.6.p.4">White space is not allowed within the tag and all tags are case-insensitive. The name space of language subtags is administered 2372 by the IANA (see <<a href="http://www.iana.org/assignments/language-subtag-registry">http://www.iana.org/assignments/language-subtag-registry</a>>). 2373 </p> 2374 <div id="rfc.figure.u.22"></div> 2375 <p>Example tags include:</p> <pre class="text"> en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN 2376 </pre> <p id="rfc.section.6.6.p.6">See <a href="#RFC5646" id="rfc.xref.RFC5646.3"><cite title="Tags for Identifying Languages">[RFC5646]</cite></a> for further information. 2377 </p> 2252 2378 <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> 2253 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> … … 2258 2384 is strictly to inform the recipient of valid request methods associated with the resource. 2259 2385 </p> 2260 <div id="rfc.figure.u. 17"></div><pre class="inline"><span id="rfc.iref.g.21"></span> <a href="#header.allow" class="smpl">Allow</a> = #<a href="#methods" class="smpl">method</a>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> 2261 2387 </pre><p id="rfc.section.7.1.p.3">Example of use:</p> 2262 <div id="rfc.figure.u. 18"></div><pre class="text"> Allow: GET, HEAD, PUT2388 <div id="rfc.figure.u.24"></div><pre class="text"> Allow: GET, HEAD, PUT 2263 2389 </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> 2264 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 according 2265 2391 to the generic message handling rules. 2266 2392 </p> 2267 <div id="rfc.iref.d. 2"></div>2393 <div id="rfc.iref.d.3"></div> 2268 2394 <div id="rfc.iref.h.3"></div> 2269 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> … … 2271 2397 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. 2272 2398 </p> 2273 <div id="rfc.figure.u. 19"></div><pre class="inline"><span id="rfc.iref.g.22"></span> <a href="#header.date" class="smpl">Date</a> = <a href="#http.date" class="smpl">HTTP-date</a>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> 2274 2400 </pre><p id="rfc.section.7.2.p.3">An example is</p> 2275 <div id="rfc.figure.u.2 0"></div><pre class="text"> Date: Tue, 15 Nov 1994 08:12:31 GMT2401 <div id="rfc.figure.u.26"></div><pre class="text"> Date: Tue, 15 Nov 1994 08:12:31 GMT 2276 2402 </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: 2277 2403 </p> … … 2299 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> 2300 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> 2301 <div id="rfc.figure.u.2 1"></div><pre class="inline"><span id="rfc.iref.g.23"></span><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span><span id="rfc.iref.g.26"></span><span id="rfc.iref.g.27"></span> <a href="#header.expect" class="smpl">Expect</a> = 1#<a href="#header.expect" class="smpl">expectation</a>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> 2302 2428 2303 2429 <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> ] … … 2311 2437 </p> 2312 2438 <p id="rfc.section.7.3.p.4">The only expectation defined by this specification is:</p> 2313 <p id="rfc.section.7.3.p.5"><span id="rfc.iref. 88"></span><span id="rfc.iref.e.2"></span> 100-continue2439 <p id="rfc.section.7.3.p.5"><span id="rfc.iref.103"></span><span id="rfc.iref.e.2"></span> 100-continue 2314 2440 </p> 2315 2441 <ul class="empty"> 2316 <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. 39"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. It does not support any expect-params.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.44"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. It does not support any expect-params. 2317 2443 </li> 2318 2444 </ul> … … 2327 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>: 2328 2454 </p> 2329 <div id="rfc.figure.u.2 2"></div><pre class="inline"><span id="rfc.iref.g.28"></span> <a href="#header.from" class="smpl">From</a> = <a href="#header.from" class="smpl">mailbox</a>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> 2330 2456 2331 2457 <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>> 2332 2458 </pre><p id="rfc.section.7.4.p.3">An example is:</p> 2333 <div id="rfc.figure.u.2 3"></div><pre class="text"> From: webmaster@example.org2459 <div id="rfc.figure.u.29"></div><pre class="text"> From: webmaster@example.org 2334 2460 </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 performed 2335 2461 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 … … 2348 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. 2349 2475 </p> 2350 <div id="rfc.figure.u. 24"></div><pre class="inline"><span id="rfc.iref.g.29"></span> <a href="#header.location" class="smpl">Location</a> = <a href="#abnf.dependencies" class="smpl">URI-reference</a>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> 2351 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, 2352 2478 the location <em class="bcp14">SHOULD</em> indicate the server's preferred URI for automatic redirection to the resource. … … 2355 2481 then the original URI's fragment identifier is added to the final value. 2356 2482 </p> 2357 <div id="rfc.figure.u. 25"></div>2483 <div id="rfc.figure.u.31"></div> 2358 2484 <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 2359 2485 </pre> <p>would result in a final value of "http://www.example.org/pub/WWW/People.html#tim"</p> 2360 <div id="rfc.figure.u. 26"></div>2486 <div id="rfc.figure.u.32"></div> 2361 2487 <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 2362 2488 </pre> <p>would result in a final value of "http://www.example.net/index.html#larry", preserving the original fragment identifier.</p> … … 2370 2496 </p> 2371 2497 <div class="note" id="rfc.section.7.5.p.9"> 2372 <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. 5.7</a>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation.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. 2373 2499 It is therefore possible for a response to contain header fields for both Location and Content-Location. 2374 2500 </p> … … 2380 2506 to trace a request which appears to be failing or looping mid-chain. 2381 2507 </p> 2382 <div id="rfc.figure.u. 27"></div><pre class="inline"><span id="rfc.iref.g.30"></span> <a href="#header.max-forwards" class="smpl">Max-Forwards</a> = 1*<a href="#notation" class="smpl">DIGIT</a>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> 2383 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> 2384 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). … … 2400 2526 non-HTTP URIs (e.g., FTP). 2401 2527 </p> 2402 <div id="rfc.figure.u. 28"></div><pre class="inline"><span id="rfc.iref.g.31"></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>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> 2403 2529 </pre><p id="rfc.section.7.7.p.5">Example:</p> 2404 <div id="rfc.figure.u. 29"></div><pre class="text"> Referer: http://www.example.org/hypertext/Overview.html2530 <div id="rfc.figure.u.35"></div><pre class="text"> Referer: http://www.example.org/hypertext/Overview.html 2405 2531 </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. 2406 2532 </p> … … 2413 2539 </p> 2414 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> 2415 <div id="rfc.figure.u.3 0"></div><pre class="inline"><span id="rfc.iref.g.32"></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>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> 2416 2542 </pre><div id="rule.delta-seconds"> 2417 2543 <p id="rfc.section.7.8.p.4"> Time spans are non-negative decimal integers, representing time in seconds.</p> 2418 2544 </div> 2419 <div id="rfc.figure.u.3 1"></div><pre class="inline"><span id="rfc.iref.g.33"></span> <a href="#rule.delta-seconds" class="smpl">delta-seconds</a> = 1*<a href="#notation" class="smpl">DIGIT</a>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> 2420 2546 </pre><p id="rfc.section.7.8.p.6">Two examples of its use are</p> 2421 <div id="rfc.figure.u.3 2"></div><pre class="text"> Retry-After: Fri, 31 Dec 1999 23:59:59 GMT2547 <div id="rfc.figure.u.38"></div><pre class="text"> Retry-After: Fri, 31 Dec 1999 23:59:59 GMT 2422 2548 Retry-After: 120 2423 2549 </pre><p id="rfc.section.7.8.p.8">In the latter example, the delay is 2 minutes.</p> … … 2426 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> 2427 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> 2428 <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.4 0"><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 for2554 <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 for 2429 2555 identifying the application. 2430 2556 </p> 2431 <div id="rfc.figure.u.3 3"></div><pre class="inline"><span id="rfc.iref.g.34"></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> ) )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> ) ) 2432 2558 </pre><p id="rfc.section.7.9.p.4">Example:</p> 2433 <div id="rfc.figure.u. 34"></div><pre class="text"> Server: CERN/3.0 libwww/2.172434 </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.4 1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).2559 <div id="rfc.figure.u.40"></div><pre class="text"> Server: CERN/3.0 libwww/2.17 2560 </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>). 2435 2561 </p> 2436 2562 <div class="note" id="rfc.section.7.9.p.7"> … … 2448 2574 user agent limitations. 2449 2575 </p> 2450 <p id="rfc.section.7.10.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.4 2"><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 significance2576 <p id="rfc.section.7.10.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 significance 2451 2577 for identifying the application. 2452 2578 </p> … … 2459 2585 doing so makes the field value more difficult to parse. 2460 2586 </p> 2461 <div id="rfc.figure.u. 35"></div><pre class="inline"><span id="rfc.iref.g.35"></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> ) )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> ) ) 2462 2588 </pre><p id="rfc.section.7.10.p.7">Example:</p> 2463 <div id="rfc.figure.u. 36"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b32589 <div id="rfc.figure.u.42"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3 2464 2590 </pre><h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> 2465 2591 <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> … … 2784 2910 <td class="left">http</td> 2785 2911 <td class="left">standard</td> 2786 <td class="left"> <a href="#header.accept" id="rfc.xref.header.accept. 2" title="Accept">Appendix D.5.1</a>2912 <td class="left"> <a href="#header.accept" id="rfc.xref.header.accept.3" title="Accept">Appendix D.4.1</a> 2787 2913 </td> 2788 2914 </tr> … … 2791 2917 <td class="left">http</td> 2792 2918 <td class="left">standard</td> 2793 <td class="left"> <a href="#header.accept-charset" id="rfc.xref.header.accept-charset.2" title="Accept-Charset">Appendix D. 5.2</a>2919 <td class="left"> <a href="#header.accept-charset" id="rfc.xref.header.accept-charset.2" title="Accept-Charset">Appendix D.4.2</a> 2794 2920 </td> 2795 2921 </tr> … … 2798 2924 <td class="left">http</td> 2799 2925 <td class="left">standard</td> 2800 <td class="left"> <a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding. 2" title="Accept-Encoding">Appendix D.5.3</a>2926 <td class="left"> <a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.3" title="Accept-Encoding">Appendix D.4.3</a> 2801 2927 </td> 2802 2928 </tr> … … 2805 2931 <td class="left">http</td> 2806 2932 <td class="left">standard</td> 2807 <td class="left"> <a href="#header.accept-language" id="rfc.xref.header.accept-language.2" title="Accept-Language">Appendix D. 5.4</a>2933 <td class="left"> <a href="#header.accept-language" id="rfc.xref.header.accept-language.2" title="Accept-Language">Appendix D.4.4</a> 2808 2934 </td> 2809 2935 </tr> … … 2819 2945 <td class="left">http</td> 2820 2946 <td class="left">standard</td> 2821 <td class="left"> <a href="#header.content-encoding" id="rfc.xref.header.content-encoding. 1" title="Content-Encoding">Appendix D.5.5</a>2947 <td class="left"> <a href="#header.content-encoding" id="rfc.xref.header.content-encoding.2" title="Content-Encoding">Appendix D.4.5</a> 2822 2948 </td> 2823 2949 </tr> … … 2826 2952 <td class="left">http</td> 2827 2953 <td class="left">standard</td> 2828 <td class="left"> <a href="#header.content-language" id="rfc.xref.header.content-language.1" title="Content-Language">Appendix D. 5.6</a>2954 <td class="left"> <a href="#header.content-language" id="rfc.xref.header.content-language.1" title="Content-Language">Appendix D.4.6</a> 2829 2955 </td> 2830 2956 </tr> … … 2833 2959 <td class="left">http</td> 2834 2960 <td class="left">standard</td> 2835 <td class="left"> <a href="#header.content-location" id="rfc.xref.header.content-location.3" title="Content-Location">Appendix D. 5.7</a>2961 <td class="left"> <a href="#header.content-location" id="rfc.xref.header.content-location.3" title="Content-Location">Appendix D.4.7</a> 2836 2962 </td> 2837 2963 </tr> … … 2840 2966 <td class="left">http</td> 2841 2967 <td class="left">standard</td> 2842 <td class="left"> <a href="#header.content-type" id="rfc.xref.header.content-type. 3" title="Content-Type">Appendix D.5.8</a>2968 <td class="left"> <a href="#header.content-type" id="rfc.xref.header.content-type.4" title="Content-Type">Appendix D.4.8</a> 2843 2969 </td> 2844 2970 </tr> … … 2875 3001 <td class="left">http</td> 2876 3002 <td class="left">standard</td> 2877 <td class="left"> <a href="#mime-version" id="rfc.xref.mime-version.1" title="MIME-Version">Appendix D. 8.1</a>3003 <td class="left"> <a href="#mime-version" id="rfc.xref.mime-version.1" title="MIME-Version">Appendix D.7.1</a> 2878 3004 </td> 2879 3005 </tr> … … 2981 3107 </p> 2982 3108 <h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a> <a id="acks" href="#acks">Acknowledgments</a></h1> 2983 <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.4 3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.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>. 2984 3110 </p> 2985 3111 <h1 id="rfc.references"><a id="rfc.section.11" href="#rfc.section.11">11.</a> References … … 3225 3351 </p> 3226 3352 <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 3227 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.4 4"><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>)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>) 3228 3354 </p> 3229 3355 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 3230 <div id="rfc.figure.u. 37"></div> <pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [3356 <div id="rfc.figure.u.43"></div> <pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ 3231 3357 OWS media-range [ accept-params ] ] ) ] 3232 3358 <a href="#header.accept-charset" class="smpl">Accept-Charset</a> = *( "," OWS ) ( charset / "*" ) [ OWS ";" OWS "q=" … … 3375 3501 3376 3502 <a href="#preferred.date.format" class="smpl">year</a> = 4DIGIT 3377 </pre> <div id="rfc.figure.u. 38"></div>3503 </pre> <div id="rfc.figure.u.44"></div> 3378 3504 <p>ABNF diagnostics:</p><pre class="inline">; qvalue UNDEFINED 3379 3505 ; Accept defined but not used … … 3722 3848 <h1 id="rfc.section.D"><a href="#rfc.section.D">D.</a> THE TEXT FORMERLY KNOWN AS PART3 3723 3849 </h1> 3724 <h2 id="rfc.section.D.1"><a href="#rfc.section.D.1">D.1</a> <a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h2> 3725 <h3 id="rfc.section.D.1.1"><a href="#rfc.section.D.1.1">D.1.1</a> <a id="character.sets" href="#character.sets">Character Encodings (charset)</a></h3> 3726 <p id="rfc.section.D.1.1.p.1">HTTP uses charset names to indicate the character encoding of a textual representation.</p> 3727 <div id="rule.charset"> 3728 <p id="rfc.section.D.1.1.p.2"> A character encoding is identified by a case-insensitive token. The complete set of tokens is defined by the IANA Character 3729 Set registry (<<a href="http://www.iana.org/assignments/character-sets">http://www.iana.org/assignments/character-sets</a>>). 3730 </p> 3731 </div> 3732 <div id="rfc.figure.u.39"></div><pre class="inline"><span id="rfc.iref.g.36"></span> <a href="#rule.charset" class="smpl">charset</a> = <a href="#core.rules" class="smpl">token</a> 3733 </pre><p id="rfc.section.D.1.1.p.4">Although HTTP allows an arbitrary token to be used as a charset value, any token that has a predefined value within the IANA 3734 Character Set registry <em class="bcp14">MUST</em> represent the character encoding defined by that registry. Applications <em class="bcp14">SHOULD</em> limit their use of character encodings to those defined within the IANA registry. 3735 </p> 3736 <p id="rfc.section.D.1.1.p.5">HTTP uses charset in two contexts: within an Accept-Charset request header field (in which the charset value is an unquoted 3737 token) and as the value of a parameter in a Content-Type header field (within a request or response), in which case the parameter 3738 value of the charset parameter can be quoted. 3739 </p> 3740 <p id="rfc.section.D.1.1.p.6">Implementors need to be aware of IETF character set requirements <a href="#RFC3629" id="rfc.xref.RFC3629.1"><cite title="UTF-8, a transformation format of ISO 10646">[RFC3629]</cite></a> <a href="#RFC2277" id="rfc.xref.RFC2277.1"><cite title="IETF Policy on Character Sets and Languages">[RFC2277]</cite></a>. 3741 </p> 3742 <h3 id="rfc.section.D.1.2"><a href="#rfc.section.D.1.2">D.1.2</a> <a id="content.codings" href="#content.codings">Content Codings</a></h3> 3743 <p id="rfc.section.D.1.2.p.1">Content coding values indicate an encoding transformation that has been or can be applied to a representation. Content codings 3744 are primarily used to allow a representation to be compressed or otherwise usefully transformed without losing the identity 3745 of its underlying media type and without loss of information. Frequently, the representation is stored in coded form, transmitted 3746 directly, and only decoded by the recipient. 3747 </p> 3748 <div id="rfc.figure.u.40"></div><pre class="inline"><span id="rfc.iref.g.37"></span> <a href="#content.codings" class="smpl">content-coding</a> = <a href="#core.rules" class="smpl">token</a> 3749 </pre><p id="rfc.section.D.1.2.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.3" title="Accept-Encoding">Appendix D.5.3</a>) and Content-Encoding (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.2" title="Content-Encoding">Appendix D.5.5</a>) header fields. Although the value describes the content-coding, what is more important is that it indicates what decoding 3750 mechanism will be required to remove the encoding. 3751 </p> 3752 <p id="rfc.section.D.1.2.p.4">compress<span id="rfc.iref.c.3"></span><span id="rfc.iref.c.4"></span> 3753 </p> 3754 <ul class="empty"> 3755 <li>See <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 4.2.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>. 3756 </li> 3757 </ul> 3758 <p id="rfc.section.D.1.2.p.5">deflate<span id="rfc.iref.d.3"></span><span id="rfc.iref.c.5"></span> 3759 </p> 3760 <ul class="empty"> 3761 <li>See <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 4.2.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>. 3762 </li> 3763 </ul> 3764 <p id="rfc.section.D.1.2.p.6">gzip<span id="rfc.iref.g.38"></span><span id="rfc.iref.c.6"></span> 3765 </p> 3766 <ul class="empty"> 3767 <li>See <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 4.2.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>. 3768 </li> 3769 </ul> 3770 <h4 id="rfc.section.D.1.2.1"><a href="#rfc.section.D.1.2.1">D.1.2.1</a> <a id="content.coding.registry" href="#content.coding.registry">Content Coding Registry</a></h4> 3771 <p id="rfc.section.D.1.2.1.p.1">The HTTP Content Coding Registry defines the name space for the content coding names.</p> 3772 <p id="rfc.section.D.1.2.1.p.2">Registrations <em class="bcp14">MUST</em> include the following fields: 3773 </p> 3774 <ul> 3775 <li>Name</li> 3776 <li>Description</li> 3777 <li>Pointer to specification text</li> 3778 </ul> 3779 <p id="rfc.section.D.1.2.1.p.3">Names of content codings <em class="bcp14">MUST NOT</em> overlap with names of transfer codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 4</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>), unless the encoding transformation is identical (as is the case for the compression codings defined in <a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 4.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>). 3780 </p> 3781 <p id="rfc.section.D.1.2.1.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.3"><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 content coding defined in this section. 3782 </p> 3783 <p id="rfc.section.D.1.2.1.p.5">The registry itself is maintained at <<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>>. 3784 </p> 3785 <h3 id="rfc.section.D.1.3"><a href="#rfc.section.D.1.3">D.1.3</a> <a id="media.types" href="#media.types">Media Types</a></h3> 3786 <p id="rfc.section.D.1.3.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.4" title="Content-Type">Appendix D.5.8</a>) and Accept (<a href="#header.accept" id="rfc.xref.header.accept.3" title="Accept">Appendix D.5.1</a>) header fields in order to provide open and extensible data typing and type negotiation. 3787 </p> 3788 <div id="rfc.figure.u.41"></div><pre class="inline"><span id="rfc.iref.g.39"></span><span id="rfc.iref.g.40"></span><span id="rfc.iref.g.41"></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> ) 3789 <a href="#media.types" class="smpl">type</a> = <a href="#core.rules" class="smpl">token</a> 3790 <a href="#media.types" class="smpl">subtype</a> = <a href="#core.rules" class="smpl">token</a> 3791 </pre><div id="rule.parameter"> 3792 <p id="rfc.section.D.1.3.p.3"> The type/subtype <em class="bcp14">MAY</em> be followed by parameters in the form of attribute/value pairs. 3793 </p> 3794 </div> 3795 <div id="rfc.figure.u.42"></div><pre class="inline"><span id="rfc.iref.g.42"></span><span id="rfc.iref.g.43"></span><span id="rfc.iref.g.44"></span> <a href="#rule.parameter" class="smpl">parameter</a> = <a href="#rule.parameter" class="smpl">attribute</a> "=" <a href="#rule.parameter" class="smpl">value</a> 3796 <a href="#rule.parameter" class="smpl">attribute</a> = <a href="#core.rules" class="smpl">token</a> 3797 <a href="#rule.parameter" class="smpl">value</a> = <a href="#core.rules" class="smpl">word</a> 3798 </pre><p id="rfc.section.D.1.3.p.5">The type, subtype, and parameter attribute names are case-insensitive. Parameter values might or might not be case-sensitive, 3799 depending on the semantics of the parameter name. The presence or absence of a parameter might be significant to the processing 3800 of a media-type, depending on its definition within the media type registry. 3801 </p> 3802 <p id="rfc.section.D.1.3.p.6">A parameter value that matches the <a href="#core.rules" class="smpl">token</a> production can be transmitted as either a token or within a quoted-string. The quoted and unquoted values are equivalent. 3803 </p> 3804 <p id="rfc.section.D.1.3.p.7">Note that some older HTTP applications do not recognize media type parameters. When sending data to older HTTP applications, 3805 implementations <em class="bcp14">SHOULD</em> only use media type parameters when they are required by that type/subtype definition. 3806 </p> 3807 <p id="rfc.section.D.1.3.p.8">Media-type values are registered with the Internet Assigned Number Authority (IANA). The media type registration process is 3808 outlined in <a href="#RFC4288" id="rfc.xref.RFC4288.1"><cite title="Media Type Specifications and Registration Procedures">[RFC4288]</cite></a>. Use of non-registered media types is discouraged. 3809 </p> 3810 <h4 id="rfc.section.D.1.3.1"><a href="#rfc.section.D.1.3.1">D.1.3.1</a> <a id="canonicalization.and.text.defaults" href="#canonicalization.and.text.defaults">Canonicalization and Text Defaults</a></h4> 3811 <p id="rfc.section.D.1.3.1.p.1">Internet media types are registered with a canonical form. A representation transferred via HTTP messages <em class="bcp14">MUST</em> be in the appropriate canonical form prior to its transmission except for "text" types, as defined in the next paragraph. 3812 </p> 3813 <p id="rfc.section.D.1.3.1.p.2">When in canonical form, media subtypes of the "text" type use CRLF as the text line break. HTTP relaxes this requirement and 3814 allows the transport of text media with plain CR or LF alone representing a line break when it is done consistently for an 3815 entire representation. HTTP applications <em class="bcp14">MUST</em> accept CRLF, bare CR, and bare LF as indicating a line break in text media received via HTTP. In addition, if the text is 3816 in a character encoding that does not use octets 13 and 10 for CR and LF respectively, as is the case for some multi-byte 3817 character encodings, HTTP allows the use of whatever octet sequences are defined by that character encoding to represent the 3818 equivalent of CR and LF for line breaks. This flexibility regarding line breaks applies only to text media in the payload 3819 body; a bare CR or LF <em class="bcp14">MUST NOT</em> be substituted for CRLF within any of the HTTP control structures (such as header fields and multipart boundaries). 3820 </p> 3821 <p id="rfc.section.D.1.3.1.p.3">If a representation is encoded with a content-coding, the underlying data <em class="bcp14">MUST</em> be in a form defined above prior to being encoded. 3822 </p> 3823 <h4 id="rfc.section.D.1.3.2"><a href="#rfc.section.D.1.3.2">D.1.3.2</a> <a id="multipart.types" href="#multipart.types">Multipart Types</a></h4> 3824 <p id="rfc.section.D.1.3.2.p.1">MIME provides for a number of "multipart" types — encapsulations of one or more representations within a single message body. 3825 All multipart types share a common syntax, as defined in <a href="http://tools.ietf.org/html/rfc2046#section-5.1.1">Section 5.1.1</a> of <a href="#RFC2046" id="rfc.xref.RFC2046.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, and <em class="bcp14">MUST</em> include a boundary parameter as part of the media type value. The message body is itself a protocol element and <em class="bcp14">MUST</em> therefore use only CRLF to represent line breaks between body-parts. 3826 </p> 3827 <p id="rfc.section.D.1.3.2.p.2">In general, HTTP treats a multipart message body no differently than any other media type: strictly as payload. HTTP does 3828 not use the multipart boundary as an indicator of message body length. In all other respects, an HTTP user agent <em class="bcp14">SHOULD</em> follow the same or similar behavior as a MIME user agent would upon receipt of a multipart type. The MIME header fields within 3829 each body-part of a multipart message body do not have any significance to HTTP beyond that defined by their MIME semantics. 3830 </p> 3831 <p id="rfc.section.D.1.3.2.p.3">If an application receives an unrecognized multipart subtype, the application <em class="bcp14">MUST</em> treat it as being equivalent to "multipart/mixed". 3832 </p> 3833 <div class="note" id="rfc.section.D.1.3.2.p.4"> 3834 <p> <b>Note:</b> The "multipart/form-data" type has been specifically defined for carrying form data suitable for processing via the POST request 3835 method, as described in <a href="#RFC2388" id="rfc.xref.RFC2388.1"><cite title="Returning Values from Forms: multipart/form-data">[RFC2388]</cite></a>. 3836 </p> 3837 </div> 3838 <h3 id="rfc.section.D.1.4"><a href="#rfc.section.D.1.4">D.1.4</a> <a id="language.tags" href="#language.tags">Language Tags</a></h3> 3839 <p id="rfc.section.D.1.4.p.1">A language tag, as defined in <a href="#RFC5646" id="rfc.xref.RFC5646.1"><cite title="Tags for Identifying Languages">[RFC5646]</cite></a>, identifies a natural language spoken, written, or otherwise conveyed by human beings for communication of information to 3840 other human beings. Computer languages are explicitly excluded. HTTP uses language tags within the Accept-Language and Content-Language 3841 fields. 3842 </p> 3843 <p id="rfc.section.D.1.4.p.2">In summary, a language tag is composed of one or more parts: A primary language subtag followed by a possibly empty series 3844 of subtags: 3845 </p> 3846 <div id="rfc.figure.u.43"></div><pre class="inline"><span id="rfc.iref.g.45"></span> <a href="#language.tags" class="smpl">language-tag</a> = <Language-Tag, defined in <a href="#RFC5646" id="rfc.xref.RFC5646.2"><cite title="Tags for Identifying Languages">[RFC5646]</cite></a>, <a href="http://tools.ietf.org/html/rfc5646#section-2.1">Section 2.1</a>> 3847 </pre><p id="rfc.section.D.1.4.p.4">White space is not allowed within the tag and all tags are case-insensitive. The name space of language subtags is administered 3848 by the IANA (see <<a href="http://www.iana.org/assignments/language-subtag-registry">http://www.iana.org/assignments/language-subtag-registry</a>>). 3849 </p> 3850 <div id="rfc.figure.u.44"></div> 3851 <p>Example tags include:</p> <pre class="text"> en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN 3852 </pre> <p id="rfc.section.D.1.4.p.6">See <a href="#RFC5646" id="rfc.xref.RFC5646.3"><cite title="Tags for Identifying Languages">[RFC5646]</cite></a> for further information. 3853 </p> 3854 <h2 id="rfc.section.D.2"><a href="#rfc.section.D.2">D.2</a> <a id="payload" href="#payload">Payload</a></h2> 3855 <p id="rfc.section.D.2.p.1">HTTP messages <em class="bcp14">MAY</em> transfer a payload if not otherwise restricted by the request method or response status code. The payload consists of metadata, 3850 <h2 id="rfc.section.D.1"><a href="#rfc.section.D.1">D.1</a> <a id="payload" href="#payload">Payload</a></h2> 3851 <p id="rfc.section.D.1.p.1">HTTP messages <em class="bcp14">MAY</em> transfer a payload if not otherwise restricted by the request method or response status code. The payload consists of metadata, 3856 3852 in the form of header fields, and data, in the form of the sequence of octets in the message body after any transfer-coding 3857 3853 has been decoded. 3858 3854 </p> 3859 3855 <div id="rfc.iref.p.3"></div> 3860 <p id="rfc.section.D. 2.p.2">A "<dfn>payload</dfn>" in HTTP is always a partial or complete representation of some resource. We use separate terms for payload and representation3856 <p id="rfc.section.D.1.p.2">A "<dfn>payload</dfn>" in HTTP is always a partial or complete representation of some resource. We use separate terms for payload and representation 3861 3857 because some messages contain only the associated representation's header fields (e.g., responses to HEAD) or only some part(s) 3862 3858 of the representation (e.g., the 206 status code). 3863 3859 </p> 3864 <h3 id="rfc.section.D. 2.1"><a href="#rfc.section.D.2.1">D.2.1</a> <a id="payload.header.fields" href="#payload.header.fields">Payload Header Fields</a></h3>3865 <p id="rfc.section.D. 2.1.p.1">HTTP header fields that specifically define the payload, rather than the associated representation, are referred to as "payload3860 <h3 id="rfc.section.D.1.1"><a href="#rfc.section.D.1.1">D.1.1</a> <a id="payload.header.fields" href="#payload.header.fields">Payload Header Fields</a></h3> 3861 <p id="rfc.section.D.1.1.p.1">HTTP header fields that specifically define the payload, rather than the associated representation, are referred to as "payload 3866 3862 header fields". The following payload header fields are defined by HTTP/1.1: 3867 3863 </p> … … 3886 3882 </table> 3887 3883 </div> 3888 <h3 id="rfc.section.D. 2.2"><a href="#rfc.section.D.2.2">D.2.2</a> <a id="payload.body" href="#payload.body">Payload Body</a></h3>3889 <p id="rfc.section.D. 2.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.51"><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 ensure3884 <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.51"><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 3890 3886 safe and proper transfer of the message. 3891 3887 </p> 3892 3888 <div id="rfc.iref.r.3"></div> 3893 <h2 id="rfc.section.D. 3"><a href="#rfc.section.D.3">D.3</a> <a id="representation3" href="#representation3">Representation</a></h2>3894 <p id="rfc.section.D. 3.p.1">A "<dfn>representation</dfn>" is information in a format that can be readily communicated from one party to another. A resource representation is information3889 <h2 id="rfc.section.D.2"><a href="#rfc.section.D.2">D.2</a> <a id="representation3" href="#representation3">Representation</a></h2> 3890 <p id="rfc.section.D.2.p.1">A "<dfn>representation</dfn>" is information in a format that can be readily communicated from one party to another. A resource representation is information 3895 3891 that reflects the state of that resource, as observed at some point in the past (e.g., in a response to GET) or to be desired 3896 3892 at some point in the future (e.g., in a PUT request). 3897 3893 </p> 3898 <p id="rfc.section.D. 3.p.2">Most, but not all, representations transferred via HTTP are intended to be a representation of the target resource (the resource3894 <p id="rfc.section.D.2.p.2">Most, but not all, representations transferred via HTTP are intended to be a representation of the target resource (the resource 3899 3895 identified by the effective request URI). The precise semantics of a representation are determined by the type of message 3900 3896 (request or response), the request method, the response status code, and the representation metadata. For example, the above … … 3905 3901 next steps are suggested for resolving it. 3906 3902 </p> 3907 <h3 id="rfc.section.D. 3.1"><a href="#rfc.section.D.3.1">D.3.1</a> <a id="representation.header.fields" href="#representation.header.fields">Representation Header Fields</a></h3>3908 <p id="rfc.section.D. 3.1.p.1">Representation header fields define metadata about the representation data enclosed in the message body or, if no message3903 <h3 id="rfc.section.D.2.1"><a href="#rfc.section.D.2.1">D.2.1</a> <a id="representation.header.fields" href="#representation.header.fields">Representation Header Fields</a></h3> 3904 <p id="rfc.section.D.2.1.p.1">Representation header fields define metadata about the representation data enclosed in the message body or, if no message 3909 3905 body is present, about the representation that would have been transferred in a 200 response to a simultaneous GET request 3910 3906 with the same effective request URI. 3911 3907 </p> 3912 <p id="rfc.section.D. 3.1.p.2">The following header fields are defined as representation metadata:</p>3908 <p id="rfc.section.D.2.1.p.2">The following header fields are defined as representation metadata:</p> 3913 3909 <div id="rfc.table.u.5"> 3914 3910 <table class="tt full left" cellpadding="3" cellspacing="0"> … … 3922 3918 <tr> 3923 3919 <td class="left">Content-Encoding</td> 3924 <td class="left"><a href="#header.content-encoding" id="rfc.xref.header.content-encoding.3" title="Content-Encoding">Appendix D. 5.5</a></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> 3925 3921 </tr> 3926 3922 <tr> 3927 3923 <td class="left">Content-Language</td> 3928 <td class="left"><a href="#header.content-language" id="rfc.xref.header.content-language.2" title="Content-Language">Appendix D. 5.6</a></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> 3929 3925 </tr> 3930 3926 <tr> 3931 3927 <td class="left">Content-Location</td> 3932 <td class="left"><a href="#header.content-location" id="rfc.xref.header.content-location.4" title="Content-Location">Appendix D. 5.7</a></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> 3933 3929 </tr> 3934 3930 <tr> 3935 3931 <td class="left">Content-Type</td> 3936 <td class="left"><a href="#header.content-type" id="rfc.xref.header.content-type.5" title="Content-Type">Appendix D. 5.8</a></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> 3937 3933 </tr> 3938 3934 <tr> … … 3943 3939 </table> 3944 3940 </div> 3945 <p id="rfc.section.D. 3.1.p.3">Additional header fields define metadata about the selected representation, which might differ from the representation included3941 <p id="rfc.section.D.2.1.p.3">Additional header fields define metadata about the selected representation, which might differ from the representation included 3946 3942 in the message for responses to some state-changing methods. The following header fields are defined as selected representation 3947 3943 metadata: … … 3967 3963 </table> 3968 3964 </div> 3969 <h3 id="rfc.section.D. 3.2"><a href="#rfc.section.D.3.2">D.3.2</a> <a id="representation.data" href="#representation.data">Representation Data</a></h3>3970 <p id="rfc.section.D. 3.2.p.1">The representation body associated with an HTTP message is either provided as the payload body of the message or referred3965 <h3 id="rfc.section.D.2.2"><a href="#rfc.section.D.2.2">D.2.2</a> <a id="representation.data" href="#representation.data">Representation Data</a></h3> 3966 <p id="rfc.section.D.2.2.p.1">The representation body associated with an HTTP message is either provided as the payload body of the message or referred 3971 3967 to by the message semantics and the effective request URI. The representation data is in a format and encoding defined by 3972 3968 the representation metadata header fields. 3973 3969 </p> 3974 <p id="rfc.section.D. 3.2.p.2">The data type of the representation data is determined via the header fields Content-Type and Content-Encoding. These define3970 <p id="rfc.section.D.2.2.p.2">The data type of the representation data is determined via the header fields Content-Type and Content-Encoding. These define 3975 3971 a two-layer, ordered encoding model: 3976 3972 </p> 3977 3973 <div id="rfc.figure.u.45"></div><pre class="text"> representation-data := Content-Encoding( Content-Type( bits ) ) 3978 </pre><p id="rfc.section.D. 3.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 payload3974 </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 3979 3975 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 3980 3976 to the sender. If the Content-Type header field is not present, it indicates that the sender does not know the media type 3981 3977 of the representation; recipients <em class="bcp14">MAY</em> either assume that the media type is "application/octet-stream" (<a href="#RFC2046" id="rfc.xref.RFC2046.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, <a href="http://tools.ietf.org/html/rfc2046#section-4.5.1">Section 4.5.1</a>) or examine the content to determine its type. 3982 3978 </p> 3983 <p id="rfc.section.D. 3.2.p.5">In practice, resource owners do not always properly configure their origin server to provide the correct Content-Type for3979 <p id="rfc.section.D.2.2.p.5">In practice, resource owners do not always properly configure their origin server to provide the correct Content-Type for 3984 3980 a given representation, with the result that some clients will examine a response body's content and override the specified 3985 3981 type. Clients that do so risk drawing incorrect conclusions, which might expose additional security risks (e.g., "privilege … … 3988 3984 such "content sniffing" when it is used. 3989 3985 </p> 3990 <p id="rfc.section.D. 3.2.p.6">Content-Encoding is used to indicate any additional content codings applied to the data, usually for the purpose of data compression,3986 <p id="rfc.section.D.2.2.p.6">Content-Encoding is used to indicate any additional content codings applied to the data, usually for the purpose of data compression, 3991 3987 that are a property of the representation. If Content-Encoding is not present, then there is no additional encoding beyond 3992 3988 that defined by the Content-Type. 3993 3989 </p> 3994 <h2 id="rfc.section.D. 4"><a href="#rfc.section.D.4">D.4</a> <a id="content.negotiation" href="#content.negotiation">Content Negotiation</a></h2>3995 <p id="rfc.section.D. 4.p.1">HTTP responses include a representation which contains information for interpretation, whether by a human user or for further3990 <h2 id="rfc.section.D.3"><a href="#rfc.section.D.3">D.3</a> <a id="content.negotiation" href="#content.negotiation">Content Negotiation</a></h2> 3991 <p id="rfc.section.D.3.p.1">HTTP responses include a representation which contains information for interpretation, whether by a human user or for further 3996 3992 processing. Often, the server has different ways of representing the same information; for example, in different formats, 3997 3993 languages, or using different character encodings. 3998 3994 </p> 3999 <p id="rfc.section.D. 4.p.2">HTTP clients and their users might have different or variable capabilities, characteristics or preferences which would influence3995 <p id="rfc.section.D.3.p.2">HTTP clients and their users might have different or variable capabilities, characteristics or preferences which would influence 4000 3996 which representation, among those available from the server, would be best for the server to deliver. For this reason, HTTP 4001 3997 provides mechanisms for "content negotiation" — a process of allowing selection of a representation of a given resource, when 4002 3998 more than one is available. 4003 3999 </p> 4004 <p id="rfc.section.D. 4.p.3">This specification defines two patterns of content negotiation; "server-driven", where the server selects the representation4000 <p id="rfc.section.D.3.p.3">This specification defines two patterns of content negotiation; "server-driven", where the server selects the representation 4005 4001 based upon the client's stated preferences, and "agent-driven" negotiation, where the server provides a list of representations 4006 4002 for the client to choose from, based upon their metadata. In addition, there are other patterns: some applications use an … … 4008 4004 parameters, selects additional resources to invoke. "Transparent Content Negotiation" (<a href="#RFC2295" id="rfc.xref.RFC2295.1"><cite title="Transparent Content Negotiation in HTTP">[RFC2295]</cite></a>) has also been proposed. 4009 4005 </p> 4010 <p id="rfc.section.D. 4.p.4">These patterns are all widely used, and have trade-offs in applicability and practicality. In particular, when the number4006 <p id="rfc.section.D.3.p.4">These patterns are all widely used, and have trade-offs in applicability and practicality. In particular, when the number 4011 4007 of preferences or capabilities to be expressed by a client are large (such as when many different formats are supported by 4012 4008 a user-agent), server-driven negotiation becomes unwieldy, and might not be appropriate. Conversely, when the number of representations 4013 4009 to choose from is very large, agent-driven negotiation might not be appropriate. 4014 4010 </p> 4015 <p id="rfc.section.D. 4.p.5">Note that in all cases, the supplier of representations has the responsibility for determining which representations might4011 <p id="rfc.section.D.3.p.5">Note that in all cases, the supplier of representations has the responsibility for determining which representations might 4016 4012 be considered to be the "same information". 4017 4013 </p> 4018 <h3 id="rfc.section.D. 4.1"><a href="#rfc.section.D.4.1">D.4.1</a> <a id="server-driven.negotiation" href="#server-driven.negotiation">Server-driven Negotiation</a></h3>4019 <p id="rfc.section.D. 4.1.p.1">If the selection of the best representation for a response is made by an algorithm located at the server, it is called server-driven4014 <h3 id="rfc.section.D.3.1"><a href="#rfc.section.D.3.1">D.3.1</a> <a id="server-driven.negotiation" href="#server-driven.negotiation">Server-driven Negotiation</a></h3> 4015 <p id="rfc.section.D.3.1.p.1">If the selection of the best representation for a response is made by an algorithm located at the server, it is called server-driven 4020 4016 negotiation. Selection is based on the available representations of the response (the dimensions over which it can vary; e.g., 4021 4017 language, content-coding, etc.) and the contents of particular header fields in the request message or on other information 4022 4018 pertaining to the request (such as the network address of the client). 4023 4019 </p> 4024 <p id="rfc.section.D. 4.1.p.2">Server-driven negotiation is advantageous when the algorithm for selecting from among the available representations is difficult4020 <p id="rfc.section.D.3.1.p.2">Server-driven negotiation is advantageous when the algorithm for selecting from among the available representations is difficult 4025 4021 to describe to the user agent, or when the server desires to send its "best guess" to the client along with the first response 4026 4022 (hoping to avoid the round-trip delay of a subsequent request if the "best guess" is good enough for the user). In order to 4027 4023 improve the server's guess, the user agent <em class="bcp14">MAY</em> include request header fields (Accept, Accept-Language, Accept-Encoding, etc.) which describe its preferences for such a response. 4028 4024 </p> 4029 <p id="rfc.section.D. 4.1.p.3">Server-driven negotiation has disadvantages: </p>4025 <p id="rfc.section.D.3.1.p.3">Server-driven negotiation has disadvantages: </p> 4030 4026 <ol> 4031 4027 <li>It is impossible for the server to accurately determine what might be "best" for any given user, since that would require … … 4039 4035 <li>It might limit a public cache's ability to use the same response for multiple user's requests.</li> 4040 4036 </ol> 4041 <p id="rfc.section.D. 4.1.p.4">Server-driven negotiation allows the user agent to specify its preferences, but it cannot expect responses to always honor4037 <p id="rfc.section.D.3.1.p.4">Server-driven negotiation allows the user agent to specify its preferences, but it cannot expect responses to always honor 4042 4038 them. For example, the origin server might not implement server-driven negotiation, or it might decide that sending a response 4043 4039 that doesn't conform to them is better than sending a 406 (Not Acceptable) response. 4044 4040 </p> 4045 <p id="rfc.section.D. 4.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.52"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for more information.4046 </p> 4047 <p id="rfc.section.D. 4.1.p.6">HTTP/1.1 includes the following header fields for enabling server-driven negotiation through description of user agent capabilities4048 and user preferences: Accept (<a href="#header.accept" id="rfc.xref.header.accept.4" title="Accept">Appendix D. 5.1</a>), Accept-Charset (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.3" title="Accept-Charset">Appendix D.5.2</a>), Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.4" title="Accept-Encoding">Appendix D.5.3</a>), Accept-Language (<a href="#header.accept-language" id="rfc.xref.header.accept-language.3" title="Accept-Language">Appendix D.5.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 information4041 <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.52"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for more information. 4042 </p> 4043 <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 information 4049 4045 within extension header fields not defined by this specification. 4050 4046 </p> 4051 <div class="note" id="rfc.section.D. 4.1.p.7">4047 <div class="note" id="rfc.section.D.3.1.p.7"> 4052 4048 <p> <b>Note:</b> In practice, User-Agent based negotiation is fragile, because new clients might not be recognized. 4053 4049 </p> 4054 4050 </div> 4055 <p id="rfc.section.D. 4.1.p.8">The Vary header field (<a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.19"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) can be used to express the parameters the server uses to select a representation that is subject to server-driven negotiation.4056 </p> 4057 <h3 id="rfc.section.D. 4.2"><a href="#rfc.section.D.4.2">D.4.2</a> <a id="agent-driven.negotiation" href="#agent-driven.negotiation">Agent-driven Negotiation</a></h3>4058 <p id="rfc.section.D. 4.2.p.1">With agent-driven negotiation, selection of the best representation for a response is performed by the user agent after receiving4051 <p id="rfc.section.D.3.1.p.8">The Vary header field (<a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.19"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) can be used to express the parameters the server uses to select a representation that is subject to server-driven negotiation. 4052 </p> 4053 <h3 id="rfc.section.D.3.2"><a href="#rfc.section.D.3.2">D.3.2</a> <a id="agent-driven.negotiation" href="#agent-driven.negotiation">Agent-driven Negotiation</a></h3> 4054 <p id="rfc.section.D.3.2.p.1">With agent-driven negotiation, selection of the best representation for a response is performed by the user agent after receiving 4059 4055 an initial response from the origin server. Selection is based on a list of the available representations of the response 4060 4056 included within the header fields or body of the initial response, with each representation identified by its own URI. Selection … … 4062 4058 user selecting from a generated (possibly hypertext) menu. 4063 4059 </p> 4064 <p id="rfc.section.D. 4.2.p.2">Agent-driven negotiation is advantageous when the response would vary over commonly-used dimensions (such as type, language,4060 <p id="rfc.section.D.3.2.p.2">Agent-driven negotiation is advantageous when the response would vary over commonly-used dimensions (such as type, language, 4065 4061 or encoding), when the origin server is unable to determine a user agent's capabilities from examining the request, and generally 4066 4062 when public caches are used to distribute server load and reduce network usage. 4067 4063 </p> 4068 <p id="rfc.section.D. 4.2.p.3">Agent-driven negotiation suffers from the disadvantage of needing a second request to obtain the best alternate representation.4064 <p id="rfc.section.D.3.2.p.3">Agent-driven negotiation suffers from the disadvantage of needing a second request to obtain the best alternate representation. 4069 4065 This second request is only efficient when caching is used. In addition, this specification does not define any mechanism 4070 4066 for supporting automatic selection, though it also does not prevent any such mechanism from being developed as an extension 4071 4067 and used within HTTP/1.1. 4072 4068 </p> 4073 <p id="rfc.section.D. 4.2.p.4">This specification defines the 300 (Multiple Choices) and 406 (Not Acceptable) status codes for enabling agent-driven negotiation4069 <p id="rfc.section.D.3.2.p.4">This specification defines the 300 (Multiple Choices) and 406 (Not Acceptable) status codes for enabling agent-driven negotiation 4074 4070 when the server is unwilling or unable to provide a varying response using server-driven negotiation. 4075 4071 </p> 4076 <h2 id="rfc.section.D. 5"><a href="#rfc.section.D.5">D.5</a> <a id="header.field.definitions3" href="#header.field.definitions3">Header Field Definitions</a></h2>4077 <p id="rfc.section.D. 5.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to the payload of messages.</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> 4078 4074 <div id="rfc.iref.a.2"></div> 4079 4075 <div id="rfc.iref.h.12"></div> 4080 <h3 id="rfc.section.D. 5.1"><a href="#rfc.section.D.5.1">D.5.1</a> <a id="header.accept" href="#header.accept">Accept</a></h3>4081 <p id="rfc.section.D. 5.1.p.1">The "Accept" header field can be used by user agents to specify response media types that are acceptable. Accept header fields4076 <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 4082 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 4083 4079 for an in-line image. … … 4091 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> ) 4092 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> ] 4093 </pre><p id="rfc.section.D. 5.1.p.3">The asterisk "*" character is used to group media types into ranges, with "*/*" indicating all media types and "type/*" indicating4089 </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 4094 4090 all subtypes of that type. The media-range <em class="bcp14">MAY</em> include media type parameters that are applicable to that range. 4095 4091 </p> 4096 <p id="rfc.section.D. 5.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 first4092 <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 4097 4093 "q" parameter (if any) separates the media-range parameter(s) from the accept-params. Quality factors allow the user or user 4098 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. 4099 4095 </p> 4100 <div class="note" id="rfc.section.D. 5.1.p.5">4096 <div class="note" id="rfc.section.D.4.1.p.5"> 4101 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. 4102 4098 Although this prevents any media type parameter named "q" from being used with a media range, such an event is believed to … … 4105 4101 </p> 4106 4102 </div> 4107 <p id="rfc.section.D. 5.1.p.6">The example</p>4103 <p id="rfc.section.D.4.1.p.6">The example</p> 4108 4104 <div id="rfc.figure.u.47"></div><pre class="text"> Accept: audio/*; q=0.2, audio/basic 4109 </pre><p id="rfc.section.D. 5.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 in4105 </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 4110 4106 quality". 4111 4107 </p> 4112 <p id="rfc.section.D. 5.1.p.9">A request without any Accept header field implies that the user agent will accept any media type in response. If an Accept4108 <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 4113 4109 header field is present in a request and none of the available representations for the response have a media type that is 4114 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 4115 4111 the response as if it is not subject to content negotiation. 4116 4112 </p> 4117 <p id="rfc.section.D. 5.1.p.10">A more elaborate example is</p>4113 <p id="rfc.section.D.4.1.p.10">A more elaborate example is</p> 4118 4114 <div id="rfc.figure.u.48"></div><pre class="text"> Accept: text/plain; q=0.5, text/html, 4119 4115 text/x-dvi; q=0.8, text/x-c 4120 </pre><p id="rfc.section.D. 5.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, then4116 </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 4121 4117 send the text/x-dvi representation, and if that does not exist, send the text/plain representation". 4122 4118 </p> 4123 <p id="rfc.section.D. 5.1.p.13">Media ranges can be overridden by more specific media ranges or specific media types. If more than one media range applies4119 <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 4124 4120 to a given type, the most specific reference has precedence. For example, 4125 4121 </p> 4126 4122 <div id="rfc.figure.u.49"></div><pre class="text"> Accept: text/*, text/plain, text/plain;format=flowed, */* 4127 </pre><p id="rfc.section.D. 5.1.p.15">have the following precedence: </p>4123 </pre><p id="rfc.section.D.4.1.p.15">have the following precedence: </p> 4128 4124 <ol> 4129 4125 <li>text/plain;format=flowed</li> … … 4132 4128 <li>*/*</li> 4133 4129 </ol> 4134 <p id="rfc.section.D. 5.1.p.16">The media type quality factor associated with a given type is determined by finding the media range with the highest precedence4130 <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 4135 4131 which matches that type. For example, 4136 4132 </p> 4137 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, 4138 4134 text/html;level=2;q=0.4, */*;q=0.5 4139 </pre><p id="rfc.section.D. 5.1.p.18">would cause the following values to be associated:</p>4135 </pre><p id="rfc.section.D.4.1.p.18">would cause the following values to be associated:</p> 4140 4136 <div id="rfc.table.u.7"> 4141 4137 <table class="tt full left" cellpadding="3" cellspacing="0"> … … 4174 4170 </table> 4175 4171 </div> 4176 <p id="rfc.section.D. 5.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 agent4172 <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 4177 4173 is a closed system which cannot interact with other rendering agents, this default set ought to be configurable by the user. 4178 4174 </p> 4179 4175 <div id="rfc.iref.a.3"></div> 4180 4176 <div id="rfc.iref.h.13"></div> 4181 <h3 id="rfc.section.D. 5.2"><a href="#rfc.section.D.5.2">D.5.2</a> <a id="header.accept-charset" href="#header.accept-charset">Accept-Charset</a></h3>4182 <p id="rfc.section.D. 5.2.p.1">The "Accept-Charset" header field can be used by user agents to indicate what character encodings are acceptable in a response4177 <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 4183 4179 payload. This field allows clients capable of understanding more comprehensive or special-purpose character encodings to signal 4184 4180 that capability to a server which is capable of representing documents in those character encodings. … … 4186 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> / "*" ) 4187 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> ] ) 4188 </pre><p id="rfc.section.D. 5.2.p.3">Character encoding values (a.k.a., charsets) are described in <a href="#character.sets" title="Character Encodings (charset)">Appendix D.1.1</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. An4184 </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 4189 4185 example is 4190 4186 </p> 4191 4187 <div id="rfc.figure.u.52"></div><pre class="text"> Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 4192 </pre><p id="rfc.section.D. 5.2.p.5">The special value "*", if present in the Accept-Charset field, matches every character encoding which is not mentioned elsewhere4188 </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 4193 4189 in the Accept-Charset field. If no "*" is present in an Accept-Charset field, then all character encodings not explicitly 4194 4190 mentioned get a quality value of 0. 4195 4191 </p> 4196 <p id="rfc.section.D. 5.2.p.6">A request without any Accept-Charset header field implies that the user agent will accept any character encoding in response.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. 4197 4193 If an Accept-Charset header field is present in a request and none of the available representations for the response have 4198 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 … … 4201 4197 <div id="rfc.iref.a.4"></div> 4202 4198 <div id="rfc.iref.h.14"></div> 4203 <h3 id="rfc.section.D. 5.3"><a href="#rfc.section.D.5.3">D.5.3</a> <a id="header.accept-encoding" href="#header.accept-encoding">Accept-Encoding</a></h3>4204 <p id="rfc.section.D. 5.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">Appendix D.1.2</a>) are acceptable in the response. An "identity" token is used as a synonym for "no encoding" in order to communicate when4199 <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 4205 4201 no encoding is preferred. 4206 4202 </p> 4207 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> ] ) 4208 4204 <a href="#header.accept-encoding" class="smpl">codings</a> = <a href="#content.codings" class="smpl">content-coding</a> / "identity" / "*" 4209 </pre><p id="rfc.section.D. 5.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.4210 </p> 4211 <p id="rfc.section.D. 5.3.p.4">For example,</p>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> 4212 4208 <div id="rfc.figure.u.54"></div><pre class="text"> Accept-Encoding: compress, gzip 4213 4209 Accept-Encoding: … … 4215 4211 Accept-Encoding: compress;q=0.5, gzip;q=1.0 4216 4212 Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 4217 </pre><p id="rfc.section.D. 5.3.p.6">A server tests whether a content-coding for a given representation is acceptable, according to an Accept-Encoding field, using4213 </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 4218 4214 these rules: 4219 4215 </p> … … 4230 4226 <li>If multiple content-codings are acceptable, then the acceptable content-coding with the highest non-zero qvalue is preferred.</li> 4231 4227 </ol> 4232 <p id="rfc.section.D. 5.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-coding4228 <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 4233 4229 in response. If an Accept-Encoding header field is present in a request and none of the available representations for the 4234 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. 4235 4231 </p> 4236 <p id="rfc.section.D. 5.3.p.8">A request without an Accept-Encoding header field implies that the user agent will accept any content-coding in response,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, 4237 4233 but a representation without content-coding is preferred for compatibility with the widest variety of user agents. 4238 4234 </p> 4239 <div class="note" id="rfc.section.D. 5.3.p.9">4235 <div class="note" id="rfc.section.D.4.3.p.9"> 4240 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 4241 4237 not work and are not permitted with x-gzip or x-compress. … … 4244 4240 <div id="rfc.iref.a.5"></div> 4245 4241 <div id="rfc.iref.h.15"></div> 4246 <h3 id="rfc.section.D. 5.4"><a href="#rfc.section.D.5.4">D.5.4</a> <a id="header.accept-language" href="#header.accept-language">Accept-Language</a></h3>4247 <p id="rfc.section.D. 5.4.p.1">The "Accept-Language" header field can be used by user agents to indicate the set of natural languages that are preferred4248 in the response. Language tags are defined in <a href="#language.tags" title="Language Tags"> Appendix D.1.4</a>.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>. 4249 4245 </p> 4250 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> = … … 4252 4248 <a href="#header.accept-language" class="smpl">language-range</a> = 4253 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>> 4254 </pre><p id="rfc.section.D. 5.4.p.3">Each language-range can be given an associated quality value which represents an estimate of the user's preference for the4250 </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 4255 4251 languages specified by that range. The quality value defaults to "q=1". For example, 4256 4252 </p> 4257 4253 <div id="rfc.figure.u.56"></div><pre class="text"> Accept-Language: da, en-gb;q=0.8, en;q=0.7 4258 </pre><p id="rfc.section.D. 5.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>)4259 </p> 4260 <p id="rfc.section.D. 5.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.4261 </p> 4262 <div class="note" id="rfc.section.D. 5.4.p.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"> 4263 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>. 4264 4260 </p> 4265 4261 </div> 4266 <p id="rfc.section.D. 5.4.p.8">It might be contrary to the privacy expectations of the user to send an Accept-Language header field with the complete linguistic4267 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. 7.1</a>.4268 </p> 4269 <p id="rfc.section.D. 5.4.p.9">As intelligibility is highly dependent on the individual user, it is recommended that client applications make the choice4262 <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 4270 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. 4271 4267 </p> 4272 <div class="note" id="rfc.section.D. 5.4.p.10">4268 <div class="note" id="rfc.section.D.4.4.p.10"> 4273 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 4274 4270 familiar with the details of language matching as described above, and ought to be provided appropriate guidance. As an example, … … 4279 4275 <div id="rfc.iref.c.7"></div> 4280 4276 <div id="rfc.iref.h.16"></div> 4281 <h3 id="rfc.section.D. 5.5"><a href="#rfc.section.D.5.5">D.5.5</a> <a id="header.content-encoding" href="#header.content-encoding">Content-Encoding</a></h3>4282 <p id="rfc.section.D. 5.5.p.1">The "Content-Encoding" header field indicates what content-codings have been applied to the representation beyond those inherent4277 <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 4283 4279 in the media type, and thus what decoding mechanisms have to be applied in order to obtain the media-type referenced by the 4284 4280 Content-Type header field. Content-Encoding is primarily used to allow a representation to be compressed without losing the … … 4286 4282 </p> 4287 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> 4288 </pre><p id="rfc.section.D. 5.5.p.3">Content codings are defined in <a href="#content.codings" title="Content Codings">Appendix D.1.2</a>. An example of its use is4284 </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 4289 4285 </p> 4290 4286 <div id="rfc.figure.u.58"></div><pre class="text"> Content-Encoding: gzip 4291 </pre><p id="rfc.section.D. 5.5.p.5">The content-coding is a characteristic of the representation. Typically, the representation body is stored with this encoding4287 </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 4292 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 4293 4289 directive is present in the message. 4294 4290 </p> 4295 <p id="rfc.section.D. 5.5.p.6">If the media type includes an inherent encoding, such as a data format that is always compressed, then that encoding would4291 <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 4296 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 4297 4293 would only be listed if, for some bizarre reason, it is applied a second time to form the representation. Likewise, an origin … … 4300 4296 response (e.g., open a "Save as ..." dialog instead of automatic decompression and rendering of content). 4301 4297 </p> 4302 <p id="rfc.section.D. 5.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.5.5</a>) that lists the content-coding(s) applied.4303 </p> 4304 <p id="rfc.section.D. 5.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.4305 </p> 4306 <p id="rfc.section.D. 5.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).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). 4307 4303 </p> 4308 4304 <div id="rfc.iref.c.8"></div> 4309 4305 <div id="rfc.iref.h.17"></div> 4310 <h3 id="rfc.section.D. 5.6"><a href="#rfc.section.D.5.6">D.5.6</a> <a id="header.content-language" href="#header.content-language">Content-Language</a></h3>4311 <p id="rfc.section.D. 5.6.p.1">The "Content-Language" header field describes the natural language(s) of the intended audience for the representation. Note4306 <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 4312 4308 that this might not be equivalent to all the languages used within the representation. 4313 4309 </p> 4314 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> 4315 </pre><p id="rfc.section.D. 5.6.p.3">Language tags are defined in <a href="#language.tags" title="Language Tags">Appendix D.1.4</a>. The primary purpose of Content-Language is to allow a user to identify and differentiate representations according to the4311 </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 4316 4312 user's own preferred language. Thus, if the body content is intended only for a Danish-literate audience, the appropriate 4317 4313 field is 4318 4314 </p> 4319 4315 <div id="rfc.figure.u.60"></div><pre class="text"> Content-Language: da 4320 </pre><p id="rfc.section.D. 5.6.p.5">If no Content-Language is specified, the default is that the content is intended for all language audiences. This might mean4316 </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 4321 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 4322 4318 it is intended. 4323 4319 </p> 4324 <p id="rfc.section.D. 5.6.p.6">Multiple languages <em class="bcp14">MAY</em> be listed for content that is intended for multiple audiences. For example, a rendition of the "Treaty of Waitangi", presented4320 <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 4325 4321 simultaneously in the original Maori and English versions, would call for 4326 4322 </p> 4327 4323 <div id="rfc.figure.u.61"></div><pre class="text"> Content-Language: mi, en 4328 </pre><p id="rfc.section.D. 5.6.p.8">However, just because multiple languages are present within a representation does not mean that it is intended for multiple4324 </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 4329 4325 linguistic audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin", which is clearly 4330 4326 intended to be used by an English-literate audience. In this case, the Content-Language would properly only include "en". 4331 4327 </p> 4332 <p id="rfc.section.D. 5.6.p.9">Content-Language <em class="bcp14">MAY</em> be applied to any media type — it is not limited to textual documents.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. 4333 4329 </p> 4334 4330 <div id="rfc.iref.c.9"></div> 4335 4331 <div id="rfc.iref.h.18"></div> 4336 <h3 id="rfc.section.D. 5.7"><a href="#rfc.section.D.5.7">D.5.7</a> <a id="header.content-location" href="#header.content-location">Content-Location</a></h3>4337 <p id="rfc.section.D. 5.7.p.1">The "Content-Location" header field supplies a URI that can be used as a specific identifier for the representation in this4332 <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 4338 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 4339 4335 would contain the same representation that is enclosed as payload in this message. 4340 4336 </p> 4341 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> 4342 </pre><p id="rfc.section.D. 5.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 MIME4338 </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 4343 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. 4344 4340 </p> 4345 <p id="rfc.section.D. 5.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 response4341 <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 4346 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 4347 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 … … 4350 4346 need for a subsequent GET request. 4351 4347 </p> 4352 <p id="rfc.section.D. 5.7.p.5">If Content-Location is included in a response message and its value differs from the effective request URI, then the origin4348 <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 4353 4349 server is informing recipients that this representation has its own, presumably more specific, identifier. For a GET or HEAD 4354 4350 request, this is an indication that the effective request URI identifies a resource that is subject to content negotiation … … 4359 4355 in the future. 4360 4356 </p> 4361 <p id="rfc.section.D. 5.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 enclosed4357 <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 4362 4358 representation (prior to any subsequent modification of the content by that user agent). In other words, the user agent is 4363 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 … … 4367 4363 latter semantics, it would have applied the PUT directly to the Content-Location URI. 4368 4364 </p> 4369 <p id="rfc.section.D. 5.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 use4365 <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 4370 4366 in other contexts, such as within source links or other metadata. 4371 4367 </p> 4372 <p id="rfc.section.D. 5.7.p.8">A cache cannot assume that a representation with a Content-Location different from the URI used to retrieve it can be used4368 <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 4373 4369 to respond to later requests on that Content-Location URI. 4374 4370 </p> 4375 <p id="rfc.section.D. 5.7.p.9">If the Content-Location value is a partial URI, the partial URI is interpreted relative to the effective request URI.</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> 4376 4372 <div id="rfc.iref.c.10"></div> 4377 4373 <div id="rfc.iref.h.19"></div> 4378 <h3 id="rfc.section.D. 5.8"><a href="#rfc.section.D.5.8">D.5.8</a> <a id="header.content-type" href="#header.content-type">Content-Type</a></h3>4379 <p id="rfc.section.D. 5.8.p.1">The "Content-Type" header field indicates the media type of the representation. In the case of responses to the HEAD method,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, 4380 4376 the media type is that which would have been sent had the request been a GET. 4381 4377 </p> 4382 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> 4383 </pre><p id="rfc.section.D. 5.8.p.3">Media types are defined in <a href="#media.types" title="Media Types">Appendix D.1.3</a>. An example of the field is4379 </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 4384 4380 </p> 4385 4381 <div id="rfc.figure.u.64"></div><pre class="text"> Content-Type: text/html; charset=ISO-8859-4 4386 </pre><p id="rfc.section.D. 5.8.p.5">Further discussion of Content-Type is provided in <a href="#representation.data" title="Representation Data">Appendix D.3.2</a>.4387 </p> 4388 <h2 id="rfc.section.D. 6"><a href="#rfc.section.D.6">D.6</a> <a id="IANA.considerations3" href="#IANA.considerations3">IANA Considerations</a></h2>4389 <h3 id="rfc.section.D. 6.1"><a href="#rfc.section.D.6.1">D.6.1</a> <a id="content.coding.registration" href="#content.coding.registration">Content Coding Registry</a></h3>4390 <p id="rfc.section.D. 6.1.p.1">The registration procedure for HTTP Content Codings is now defined by <a href="#content.coding.registry" title="Content Coding Registry">Appendix D.1.2.1</a> of this document.4391 </p> 4392 <p id="rfc.section.D. 6.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: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: 4393 4389 </p> 4394 4390 <div id="rfc.table.4"> … … 4425 4421 <td class="left">identity</td> 4426 4422 <td class="left">reserved (synonym for "no encoding" in Accept-Encoding header field)</td> 4427 <td class="left"> <a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.5" title="Accept-Encoding">Appendix D. 5.3</a>4423 <td class="left"> <a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.5" title="Accept-Encoding">Appendix D.4.3</a> 4428 4424 </td> 4429 4425 </tr> … … 4431 4427 </table> 4432 4428 </div> 4433 <h2 id="rfc.section.D. 7"><a href="#rfc.section.D.7">D.7</a> <a id="security.considerations3" href="#security.considerations3">Security Considerations</a></h2>4434 <p id="rfc.section.D. 7.p.1">This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.14429 <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.1 4435 4431 as described by this document. The discussion does not include definitive solutions to the problems revealed, though it does 4436 4432 make some suggestions for reducing security risks. 4437 4433 </p> 4438 <h3 id="rfc.section.D. 7.1"><a href="#rfc.section.D.7.1">D.7.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>4439 <p id="rfc.section.D. 7.1.p.1">Accept header fields can reveal information about the user to all servers which are accessed. The Accept-Language header field4434 <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 field 4440 4436 in particular can reveal information the user would consider to be of a private nature, because the understanding of particular 4441 4437 languages is often strongly correlated to the membership of a particular ethnic group. User agents which offer the option … … 4443 4439 configuration process include a message which makes the user aware of the loss of privacy involved. 4444 4440 </p> 4445 <p id="rfc.section.D. 7.1.p.2">An approach that limits the loss of privacy would be for a user agent to omit the sending of Accept-Language header fields4441 <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 fields 4446 4442 by default, and to ask the user whether or not to start sending Accept-Language header fields to a server if it detects, by 4447 4443 looking for any Vary header fields generated by the server, that such sending could improve the quality of service. 4448 4444 </p> 4449 <p id="rfc.section.D. 7.1.p.3">Elaborate user-customized accept header fields sent in every request, in particular if these include quality values, can be4445 <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 be 4450 4446 used by servers as relatively reliable and long-lived user identifiers. Such user identifiers would allow content providers 4451 4447 to do click-trail tracking, and would allow collaborating content providers to match cross-server click-trails or form submissions … … 4455 4451 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. 4456 4452 </p> 4457 <h2 id="rfc.section.D. 8"><a href="#rfc.section.D.8">D.8</a> <a id="differences.between.http.and.mime" href="#differences.between.http.and.mime">Differences between HTTP and MIME</a></h2>4458 <p id="rfc.section.D. 8.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,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, 4459 4455 RFC 2045 discusses mail, and HTTP has a few features that are different from those described in MIME. These differences were 4460 4456 carefully chosen to optimize performance over binary connections, to allow greater freedom in the use of new media types, 4461 4457 to make date comparisons easier, and to acknowledge the practice of some early HTTP servers and clients. 4462 4458 </p> 4463 <p id="rfc.section.D. 8.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 environments4459 <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 environments 4464 4460 to HTTP also need to be aware of the differences because some conversions might be required. 4465 4461 </p> 4466 4462 <div id="rfc.iref.m.10"></div> 4467 4463 <div id="rfc.iref.h.20"></div> 4468 <h3 id="rfc.section.D. 8.1"><a href="#rfc.section.D.8.1">D.8.1</a> <a id="mime-version" href="#mime-version">MIME-Version</a></h3>4469 <p id="rfc.section.D. 8.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.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. 4470 4466 Use of the MIME-Version header field indicates that the message is in full conformance with the MIME protocol (as defined 4471 4467 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 … … 4473 4469 </p> 4474 4470 <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> 4475 </pre><p id="rfc.section.D. 8.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 this4471 </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 this 4476 4472 document and not the MIME specification. 4477 4473 </p> 4478 <h3 id="rfc.section.D. 8.2"><a href="#rfc.section.D.8.2">D.8.2</a> <a id="conversion.to.canonical.form" href="#conversion.to.canonical.form">Conversion to Canonical Form</a></h3>4479 <p id="rfc.section.D. 8.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">Appendix D.1.3.1</a> of this document describes the forms allowed for subtypes of the "text" media type when transmitted over HTTP. <a href="#RFC2046" id="rfc.xref.RFC2046.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 line4474 <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 line 4480 4476 break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a line break within text content when a message is transmitted 4481 4477 over HTTP. 4482 4478 </p> 4483 <p id="rfc.section.D. 8.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">Appendix D.1.3.1</a> of this document to the RFC 2049 canonical form of CRLF. Note, however, that this might be complicated by the presence of4479 <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 of 4484 4480 a Content-Encoding and by the fact that HTTP allows the use of some character encodings which do not use octets 13 and 10 4485 4481 to represent CR and LF, respectively, as is the case for some multi-byte character encodings. 4486 4482 </p> 4487 <p id="rfc.section.D. 8.2.p.3">Conversion will break any cryptographic checksums applied to the original content unless the original content is already in4483 <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 in 4488 4484 canonical form. Therefore, the canonical form is recommended for any content that uses such checksums in HTTP. 4489 4485 </p> 4490 <h3 id="rfc.section.D. 8.3"><a href="#rfc.section.D.8.3">D.8.3</a> <a id="conversion.of.date.formats" href="#conversion.of.date.formats">Conversion of Date Formats</a></h3>4491 <p id="rfc.section.D. 8.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.4492 </p> 4493 <h3 id="rfc.section.D. 8.4"><a href="#rfc.section.D.8.4">D.8.4</a> <a id="introduction.of.content-encoding" href="#introduction.of.content-encoding">Introduction of Content-Encoding</a></h3>4494 <p id="rfc.section.D. 8.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 on4486 <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 on 4495 4491 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 4496 4492 experimental applications of Content-Type for Internet mail have used a media-type parameter of ";conversions=<content-coding>" … … 4499 4495 <div id="rfc.iref.c.11"></div> 4500 4496 <div id="rfc.iref.h.21"></div> 4501 <h3 id="rfc.section.D. 8.5"><a href="#rfc.section.D.8.5">D.8.5</a> <a id="no.content-transfer-encoding" href="#no.content-transfer-encoding">No Content-Transfer-Encoding</a></h3>4502 <p id="rfc.section.D. 8.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.4503 </p> 4504 <p id="rfc.section.D. 8.5.p.2">Proxies and gateways from HTTP to MIME-compliant protocols are responsible for ensuring that the message is in the correct4497 <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 correct 4505 4501 format and encoding for safe transport on that protocol, where "safe transport" is defined by the limitations of the protocol 4506 4502 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 4507 4503 the destination protocol. 4508 4504 </p> 4509 <h3 id="rfc.section.D. 8.6"><a href="#rfc.section.D.8.6">D.8.6</a> <a id="introduction.of.transfer-encoding" href="#introduction.of.transfer-encoding">Introduction of Transfer-Encoding</a></h3>4510 <p id="rfc.section.D. 8.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.4511 </p> 4512 <h3 id="rfc.section.D. 8.7"><a href="#rfc.section.D.8.7">D.8.7</a> <a id="mhtml.line.length" href="#mhtml.line.length">MHTML and Line Length Limitations</a></h3>4513 <p id="rfc.section.D. 8.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 not4505 <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 not 4514 4510 fold long lines. MHTML messages being transported by HTTP follow all conventions of MHTML, including line length limitations 4515 and folding, canonicalization, etc., since HTTP transports all message-bodies as payload (see <a href="#multipart.types" title="Multipart Types"> Appendix D.1.3.2</a>) and does not interpret the content or any MIME header lines that might be contained therein.4516 </p> 4517 <h2 id="rfc.section.D. 9"><a href="#rfc.section.D.9">D.9</a> <a id="additional.features" href="#additional.features">Additional Features</a></h2>4518 <p id="rfc.section.D. 9.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.14511 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 </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.1 4519 4515 applications. Implementors are advised to be aware of these features, but cannot rely upon their presence in, or interoperability 4520 4516 with, other HTTP/1.1 applications. Some of these describe proposed experimental features, and some describe features that 4521 4517 experimental deployment found lacking that are now addressed in the base HTTP/1.1 specification. 4522 4518 </p> 4523 <p id="rfc.section.D. 9.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>).4524 </p> 4525 <h2 id="rfc.section.D. 10"><a href="#rfc.section.D.10">D.10</a> <a id="changes.from.rfc.2616-3" href="#changes.from.rfc.2616-3">Changes from RFC 2616</a></h2>4526 <p id="rfc.section.D. 10.p.1">Clarify contexts that charset is used in. (<a href="#character.sets" title="Character Encodings (charset)">Appendix D.1.1</a>)4527 </p> 4528 <p id="rfc.section.D. 10.p.2">Registration of Content Codings now requires IETF Review (<a href="#content.coding.registry" title="Content Coding Registry">Appendix D.1.2.1</a>)4529 </p> 4530 <p id="rfc.section.D. 10.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">Appendix D.1.3.1</a>)4531 </p> 4532 <p id="rfc.section.D. 10.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>)4533 </p> 4534 <p id="rfc.section.D. 10.p.5">Remove definition of Content-MD5 header field because it was inconsistently implemented with respect to partial responses,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, 4535 4531 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>) 4536 4532 </p> 4537 <p id="rfc.section.D. 10.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.5.2</a>)4538 </p> 4539 <p id="rfc.section.D. 10.p.7">Remove base URI setting semantics for Content-Location due to poor implementation support, which was caused by too many broken4533 <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 broken 4540 4536 servers emitting bogus Content-Location header fields, and also the potentially undesirable effect of potentially breaking 4541 relative links in content-negotiated resources. (<a href="#header.content-location" id="rfc.xref.header.content-location.5" title="Content-Location">Appendix D. 5.7</a>)4542 </p> 4543 <p id="rfc.section.D. 10.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.8.5</a>)4544 </p> 4545 <p id="rfc.section.D. 10.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.9</a>)4546 </p> 4547 <h2 id="rfc.section.D.1 1"><a href="#rfc.section.D.11">D.11</a> <a id="change.log3" href="#change.log3">Change Log (to be removed by RFC Editor before publication)</a></h2>4548 <h3 id="rfc.section.D.1 1.1"><a href="#rfc.section.D.11.1">D.11.1</a> Since RFC 26164537 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 2616 4549 4545 </h3> 4550 <p id="rfc.section.D.1 1.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>.4551 </p> 4552 <h3 id="rfc.section.D.1 1.2"><a href="#rfc.section.D.11.2">D.11.2</a> Since draft-ietf-httpbis-p3-payload-004546 <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-00 4553 4549 </h3> 4554 <p id="rfc.section.D.1 1.2.p.1">Closed issues: </p>4550 <p id="rfc.section.D.10.2.p.1">Closed issues: </p> 4555 4551 <ul> 4556 4552 <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>>) … … 4577 4573 </li> 4578 4574 </ul> 4579 <h3 id="rfc.section.D.1 1.3"><a href="#rfc.section.D.11.3">D.11.3</a> Since draft-ietf-httpbis-p3-payload-014575 <h3 id="rfc.section.D.10.3"><a href="#rfc.section.D.10.3">D.10.3</a> Since draft-ietf-httpbis-p3-payload-01 4580 4576 </h3> 4581 <p id="rfc.section.D.1 1.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>>):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>>): 4582 4578 </p> 4583 4579 <ul> 4584 4580 <li>Add explicit references to BNF syntax and rules imported from other parts of the specification.</li> 4585 4581 </ul> 4586 <h3 id="rfc.section.D.1 1.4"><a href="#rfc.section.D.11.4">D.11.4</a> <a id="changes.3.since.02" href="#changes.3.since.02">Since draft-ietf-httpbis-p3-payload-02</a></h3>4587 <p id="rfc.section.D.1 1.4.p.1">Closed issues: </p>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> 4588 4584 <ul> 4589 4585 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/67">http://tools.ietf.org/wg/httpbis/trac/ticket/67</a>>: "Quoting Charsets" … … 4594 4590 </li> 4595 4591 </ul> 4596 <p id="rfc.section.D.1 1.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>>):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>>): 4597 4593 </p> 4598 4594 <ul> 4599 4595 <li>Reference RFC 3984, and update header field registrations for headers defined in this document.</li> 4600 4596 </ul> 4601 <h3 id="rfc.section.D.1 1.5"><a href="#rfc.section.D.11.5">D.11.5</a> <a id="changes.3.since.03" href="#changes.3.since.03">Since draft-ietf-httpbis-p3-payload-03</a></h3>4602 <p id="rfc.section.D.1 1.5.p.1">Closed issues: </p>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> 4603 4599 <ul> 4604 4600 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/67">http://tools.ietf.org/wg/httpbis/trac/ticket/67</a>>: "Quoting Charsets" … … 4609 4605 </li> 4610 4606 </ul> 4611 <p id="rfc.section.D.1 1.5.p.2">Other changes: </p>4607 <p id="rfc.section.D.10.5.p.2">Other changes: </p> 4612 4608 <ul> 4613 4609 <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. 4614 4610 </li> 4615 4611 </ul> 4616 <h3 id="rfc.section.D.1 1.6"><a href="#rfc.section.D.11.6">D.11.6</a> <a id="changes.3.since.04" href="#changes.3.since.04">Since draft-ietf-httpbis-p3-payload-04</a></h3>4617 <p id="rfc.section.D.1 1.6.p.1">Closed issues: </p>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> 4618 4614 <ul> 4619 4615 <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" 4620 4616 </li> 4621 4617 </ul> 4622 <p id="rfc.section.D.1 1.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>>):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>>): 4623 4619 </p> 4624 4620 <ul> … … 4627 4623 <li>Rewrite ABNFs to spell out whitespace rules, factor out header field value format definitions.</li> 4628 4624 </ul> 4629 <h3 id="rfc.section.D.1 1.7"><a href="#rfc.section.D.11.7">D.11.7</a> <a id="changes.3.since.05" href="#changes.3.since.05">Since draft-ietf-httpbis-p3-payload-05</a></h3>4630 <p id="rfc.section.D.1 1.7.p.1">Closed issues: </p>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> 4631 4627 <ul> 4632 4628 <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"?" 4633 4629 </li> 4634 4630 </ul> 4635 <p id="rfc.section.D.1 1.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>>):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>>): 4636 4632 </p> 4637 4633 <ul> 4638 4634 <li>Add appendix containing collected and expanded ABNF, reorganize ABNF introduction.</li> 4639 4635 </ul> 4640 <p id="rfc.section.D.1 1.7.p.3">Other changes: </p>4636 <p id="rfc.section.D.10.7.p.3">Other changes: </p> 4641 4637 <ul> 4642 4638 <li>Move definition of quality values into Part 1.</li> 4643 4639 </ul> 4644 <h3 id="rfc.section.D.1 1.8"><a href="#rfc.section.D.11.8">D.11.8</a> <a id="changes.3.since.06" href="#changes.3.since.06">Since draft-ietf-httpbis-p3-payload-06</a></h3>4645 <p id="rfc.section.D.1 1.8.p.1">Closed issues: </p>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> 4646 4642 <ul> 4647 4643 <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" … … 4650 4646 </li> 4651 4647 </ul> 4652 <h3 id="rfc.section.D.1 1.9"><a href="#rfc.section.D.11.9">D.11.9</a> <a id="changes.3.since.07" href="#changes.3.since.07">Since draft-ietf-httpbis-p3-payload-07</a></h3>4653 <p id="rfc.section.D.1 1.9.p.1">Closed issues: </p>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> 4654 4650 <ul> 4655 4651 <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" … … 4666 4662 </li> 4667 4663 </ul> 4668 <p id="rfc.section.D.1 1.9.p.2">Partly resolved issues: </p>4664 <p id="rfc.section.D.10.9.p.2">Partly resolved issues: </p> 4669 4665 <ul> 4670 4666 <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) … … 4673 4669 </li> 4674 4670 </ul> 4675 <h3 id="rfc.section.D.1 1.10"><a href="#rfc.section.D.11.10">D.11.10</a> <a id="changes.3.since.08" href="#changes.3.since.08">Since draft-ietf-httpbis-p3-payload-08</a></h3>4676 <p id="rfc.section.D.1 1.10.p.1">Closed issues: </p>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> 4677 4673 <ul> 4678 4674 <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" … … 4681 4677 </li> 4682 4678 </ul> 4683 <h3 id="rfc.section.D.1 1.11"><a href="#rfc.section.D.11.11">D.11.11</a> <a id="changes.3.since.09" href="#changes.3.since.09">Since draft-ietf-httpbis-p3-payload-09</a></h3>4684 <p id="rfc.section.D.1 1.11.p.1">Closed issues: </p>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> 4685 4681 <ul> 4686 4682 <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" … … 4693 4689 </li> 4694 4690 </ul> 4695 <p id="rfc.section.D.1 1.11.p.2">Partly resolved issues: </p>4691 <p id="rfc.section.D.10.11.p.2">Partly resolved issues: </p> 4696 4692 <ul> 4697 4693 <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" 4698 4694 </li> 4699 4695 </ul> 4700 <h3 id="rfc.section.D.1 1.12"><a href="#rfc.section.D.11.12">D.11.12</a> <a id="changes.3.since.10" href="#changes.3.since.10">Since draft-ietf-httpbis-p3-payload-10</a></h3>4701 <p id="rfc.section.D.1 1.12.p.1">Closed issues: </p>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> 4702 4698 <ul> 4703 4699 <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'" … … 4718 4714 </li> 4719 4715 </ul> 4720 <p id="rfc.section.D.1 1.12.p.2">Partly resolved issues: </p>4716 <p id="rfc.section.D.10.12.p.2">Partly resolved issues: </p> 4721 4717 <ul> 4722 4718 <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" 4723 4719 </li> 4724 4720 </ul> 4725 <h3 id="rfc.section.D.1 1.13"><a href="#rfc.section.D.11.13">D.11.13</a> <a id="changes.3.since.11" href="#changes.3.since.11">Since draft-ietf-httpbis-p3-payload-11</a></h3>4726 <p id="rfc.section.D.1 1.13.p.1">Closed issues: </p>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> 4727 4723 <ul> 4728 4724 <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" 4729 4725 </li> 4730 4726 </ul> 4731 <h3 id="rfc.section.D.1 1.14"><a href="#rfc.section.D.11.14">D.11.14</a> <a id="changes.3.since.12" href="#changes.3.since.12">Since draft-ietf-httpbis-p3-payload-12</a></h3>4732 <p id="rfc.section.D.1 1.14.p.1">Closed issues: </p>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> 4733 4729 <ul> 4734 4730 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/224">http://tools.ietf.org/wg/httpbis/trac/ticket/224</a>>: "Header Classification" … … 4739 4735 </li> 4740 4736 </ul> 4741 <h3 id="rfc.section.D.1 1.15"><a href="#rfc.section.D.11.15">D.11.15</a> <a id="changes.3.since.13" href="#changes.3.since.13">Since draft-ietf-httpbis-p3-payload-13</a></h3>4742 <p id="rfc.section.D.1 1.15.p.1">Closed issues: </p>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> 4743 4739 <ul> 4744 4740 <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" … … 4751 4747 </li> 4752 4748 </ul> 4753 <h3 id="rfc.section.D.1 1.16"><a href="#rfc.section.D.11.16">D.11.16</a> <a id="changes.3.since.14" href="#changes.3.since.14">Since draft-ietf-httpbis-p3-payload-14</a></h3>4754 <p id="rfc.section.D.1 1.16.p.1">None.</p>4755 <h3 id="rfc.section.D.1 1.17"><a href="#rfc.section.D.11.17">D.11.17</a> <a id="changes.3.since.15" href="#changes.3.since.15">Since draft-ietf-httpbis-p3-payload-15</a></h3>4756 <p id="rfc.section.D.1 1.17.p.1">Closed issues: </p>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> 4757 4753 <ul> 4758 4754 <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" 4759 4755 </li> 4760 4756 </ul> 4761 <h3 id="rfc.section.D.1 1.18"><a href="#rfc.section.D.11.18">D.11.18</a> <a id="changes.3.since.16" href="#changes.3.since.16">Since draft-ietf-httpbis-p3-payload-16</a></h3>4762 <p id="rfc.section.D.1 1.18.p.1">Closed issues: </p>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> 4763 4759 <ul> 4764 4760 <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" 4765 4761 </li> 4766 4762 </ul> 4767 <h3 id="rfc.section.D.1 1.19"><a href="#rfc.section.D.11.19">D.11.19</a> <a id="changes.3.since.17" href="#changes.3.since.17">Since draft-ietf-httpbis-p3-payload-17</a></h3>4768 <p id="rfc.section.D.1 1.19.p.1">Closed issues: </p>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> 4769 4765 <ul> 4770 4766 <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" 4771 4767 </li> 4772 4768 </ul> 4773 <h3 id="rfc.section.D.1 1.20"><a href="#rfc.section.D.11.20">D.11.20</a> <a id="changes.3.since.18" href="#changes.3.since.18">Since draft-ietf-httpbis-p3-payload-18</a></h3>4774 <p id="rfc.section.D.1 1.20.p.1">Closed issues: </p>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> 4775 4771 <ul> 4776 4772 <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?" … … 4781 4777 </li> 4782 4778 </ul> 4783 <h3 id="rfc.section.D.1 1.21"><a href="#rfc.section.D.11.21">D.11.21</a> <a id="changes.3.since.19" href="#changes.3.since.19">Since draft-ietf-httpbis-p3-payload-19</a></h3>4784 <p id="rfc.section.D.1 1.21.p.1">None yet.</p>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> 4785 4781 <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> 4786 4782 <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> … … 4790 4786 <li><a id="rfc.index.1" href="#rfc.index.1"><b>1</b></a><ul> 4791 4787 <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> 4792 <li>100-continue (expect value) <a href="#rfc.iref. 88"><b>7.3</b></a></li>4788 <li>100-continue (expect value) <a href="#rfc.iref.103"><b>7.3</b></a></li> 4793 4789 <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> 4794 4790 </ul> … … 4841 4837 </li> 4842 4838 <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul> 4843 <li>Accept header field <a href="#rfc.xref.header.accept.1">3.2</a>, <a href="#rfc.xref.header.accept.2"> 8.3</a>, <a href="#rfc.xref.header.accept.3">D.1.3</a>, <a href="#rfc.xref.header.accept.4">D.4.1</a>, <a href="#rfc.iref.a.2"><b>D.5.1</b></a></li>4844 <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. 4.1</a>, <a href="#rfc.iref.a.3"><b>D.5.2</b></a>, <a href="#rfc.xref.header.accept-charset.4">D.10</a></li>4845 <li>Accept-Encoding header field <a href="#rfc.xref.header.accept-encoding.1">3.2</a>, <a href="#rfc.xref.header.accept-encoding.2"> 8.3</a>, <a href="#rfc.xref.header.accept-encoding.3">D.1.2</a>, <a href="#rfc.xref.header.accept-encoding.4">D.4.1</a>, <a href="#rfc.iref.a.4"><b>D.5.3</b></a>, <a href="#rfc.xref.header.accept-encoding.5">D.6.1</a></li>4846 <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. 4.1</a>, <a href="#rfc.iref.a.5"><b>D.5.4</b></a></li>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> 4847 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> 4848 4844 </ul> … … 4851 4847 <li>Coding Format 4852 4848 <ul> 4853 <li>compress <a href="#rfc.iref.c.4"> D.1.2</a></li>4854 <li>deflate <a href="#rfc.iref.c.5"> D.1.2</a></li>4855 <li>gzip <a href="#rfc.iref.c.6"> D.1.2</a></li>4849 <li>compress <a href="#rfc.iref.c.4">6.4</a></li> 4850 <li>deflate <a href="#rfc.iref.c.5">6.4</a></li> 4851 <li>gzip <a href="#rfc.iref.c.6">6.4</a></li> 4856 4852 </ul> 4857 4853 </li> 4858 <li>compress (Coding Format) <a href="#rfc.iref.c.3"> D.1.2</a></li>4854 <li>compress (Coding Format) <a href="#rfc.iref.c.3">6.4</a></li> 4859 4855 <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> 4860 4856 <li>content negotiation <a href="#rfc.iref.c.1">1.1</a></li> 4861 <li>Content-Encoding header field <a href="#rfc.xref.header.content-encoding.1"> 8.3</a>, <a href="#rfc.xref.header.content-encoding.2">D.1.2</a>, <a href="#rfc.xref.header.content-encoding.3">D.3.1</a>, <a href="#rfc.iref.c.7"><b>D.5.5</b></a>, <a href="#rfc.xref.header.content-encoding.4">D.5.5</a></li>4862 <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. 3.1</a>, <a href="#rfc.iref.c.8"><b>D.5.6</b></a></li>4863 <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. 3.1</a>, <a href="#rfc.iref.c.9"><b>D.5.7</b></a>, <a href="#rfc.xref.header.content-location.5">D.10</a></li>4864 <li>Content-Transfer-Encoding header field <a href="#rfc.iref.c.11">D. 8.5</a>, <a href="#rfc.xref.no.content-transfer-encoding.1">D.10</a></li>4865 <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"> 8.3</a>, <a href="#rfc.xref.header.content-type.4">D.1.3</a>, <a href="#rfc.xref.header.content-type.5">D.3.1</a>, <a href="#rfc.iref.c.10"><b>D.5.8</b></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> 4866 4862 </ul> 4867 4863 </li> 4868 4864 <li><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul> 4869 <li>Date header field <a href="#rfc.xref.header.date.1">3.3</a>, <a href="#rfc.iref.d. 2"><b>7.2</b></a>, <a href="#rfc.xref.header.date.2">8.3</a></li>4870 <li>deflate (Coding Format) <a href="#rfc.iref.d. 3">D.1.2</a></li>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> 4866 <li>deflate (Coding Format) <a href="#rfc.iref.d.2">6.4</a></li> 4871 4867 <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> 4872 4868 <li><em>draft-reschke-http-status-308</em> <a href="#rfc.xref.draft-reschke-http-status-308.1">4.5.7</a>, <a href="#draft-reschke-http-status-308"><b>11.2</b></a></li> … … 4890 4886 <li><tt>Grammar</tt> 4891 4887 <ul> 4892 <li><tt>Accept</tt> <a href="#rfc.iref.g.46"><b>D. 5.1</b></a></li>4893 <li><tt>Accept-Charset</tt> <a href="#rfc.iref.g.50"><b>D. 5.2</b></a></li>4894 <li><tt>Accept-Encoding</tt> <a href="#rfc.iref.g.51"><b>D. 5.3</b></a></li>4895 <li><tt>accept-ext</tt> <a href="#rfc.iref.g.49"><b>D. 5.1</b></a></li>4896 <li><tt>Accept-Language</tt> <a href="#rfc.iref.g.53"><b>D. 5.4</b></a></li>4897 <li><tt>accept-params</tt> <a href="#rfc.iref.g.48"><b>D. 5.1</b></a></li>4898 <li><tt>Allow</tt> <a href="#rfc.iref.g. 21"><b>7.1</b></a></li>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> 4899 4895 <li><tt>asctime-date</tt> <a href="#rfc.iref.g.18"><b>6.1</b></a></li> 4900 <li><tt>attribute</tt> <a href="#rfc.iref.g. 43"><b>D.1.3</b></a></li>4901 <li><tt>charset</tt> <a href="#rfc.iref.g. 36"><b>D.1.1</b></a></li>4902 <li><tt>codings</tt> <a href="#rfc.iref.g.52"><b>D. 5.3</b></a></li>4903 <li><tt>content-coding</tt> <a href="#rfc.iref.g. 37"><b>D.1.2</b></a></li>4904 <li><tt>Content-Encoding</tt> <a href="#rfc.iref.g.55"><b>D. 5.5</b></a></li>4905 <li><tt>Content-Language</tt> <a href="#rfc.iref.g.56"><b>D. 5.6</b></a></li>4906 <li><tt>Content-Location</tt> <a href="#rfc.iref.g.57"><b>D. 5.7</b></a></li>4907 <li><tt>Content-Type</tt> <a href="#rfc.iref.g.58"><b>D. 5.8</b></a></li>4908 <li><tt>Date</tt> <a href="#rfc.iref.g. 22"><b>7.2</b></a></li>4896 <li><tt>attribute</tt> <a href="#rfc.iref.g.28"><b>6.5</b></a></li> 4897 <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> 4899 <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> 4909 4905 <li><tt>date1</tt> <a href="#rfc.iref.g.5"><b>6.1</b></a></li> 4910 4906 <li><tt>day</tt> <a href="#rfc.iref.g.12"><b>6.1</b></a></li> 4911 4907 <li><tt>day-name</tt> <a href="#rfc.iref.g.10"><b>6.1</b></a></li> 4912 4908 <li><tt>day-name-l</tt> <a href="#rfc.iref.g.11"><b>6.1</b></a></li> 4913 <li><tt>delta-seconds</tt> <a href="#rfc.iref.g. 33"><b>7.8</b></a></li>4914 <li><tt>Expect</tt> <a href="#rfc.iref.g. 23"><b>7.3</b></a></li>4915 <li><tt>expect-name</tt> <a href="#rfc.iref.g. 27"><b>7.3</b></a></li>4916 <li><tt>expect-param</tt> <a href="#rfc.iref.g. 25"><b>7.3</b></a></li>4917 <li><tt>expect-value</tt> <a href="#rfc.iref.g. 26"><b>7.3</b></a></li>4918 <li><tt>expectation</tt> <a href="#rfc.iref.g. 24"><b>7.3</b></a></li>4919 <li><tt>From</tt> <a href="#rfc.iref.g. 28"><b>7.4</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> 4920 4916 <li><tt>GMT</tt> <a href="#rfc.iref.g.15"><b>6.1</b></a></li> 4921 4917 <li><tt>hour</tt> <a href="#rfc.iref.g.7"><b>6.1</b></a></li> 4922 4918 <li><tt>HTTP-date</tt> <a href="#rfc.iref.g.3"><b>6.1</b></a></li> 4923 <li><tt>language-range</tt> <a href="#rfc.iref.g.54"><b>D. 5.4</b></a></li>4924 <li><tt>language-tag</tt> <a href="#rfc.iref.g. 45"><b>D.1.4</b></a></li>4925 <li><tt>Location</tt> <a href="#rfc.iref.g. 29"><b>7.5</b></a></li>4926 <li><tt>Max-Forwards</tt> <a href="#rfc.iref.g. 30"><b>7.6</b></a></li>4927 <li><tt>media-range</tt> <a href="#rfc.iref.g.47"><b>D. 5.1</b></a></li>4928 <li><tt>media-type</tt> <a href="#rfc.iref.g. 39"><b>D.1.3</b></a></li>4919 <li><tt>language-range</tt> <a href="#rfc.iref.g.54"><b>D.4.4</b></a></li> 4920 <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> 4924 <li><tt>media-type</tt> <a href="#rfc.iref.g.24"><b>6.5</b></a></li> 4929 4925 <li><tt>method</tt> <a href="#rfc.iref.g.1"><b>2</b></a></li> 4930 <li><tt>MIME-Version</tt> <a href="#rfc.iref.g.59"><b>D. 8.1</b></a></li>4926 <li><tt>MIME-Version</tt> <a href="#rfc.iref.g.59"><b>D.7.1</b></a></li> 4931 4927 <li><tt>minute</tt> <a href="#rfc.iref.g.8"><b>6.1</b></a></li> 4932 4928 <li><tt>month</tt> <a href="#rfc.iref.g.13"><b>6.1</b></a></li> 4933 4929 <li><tt>obs-date</tt> <a href="#rfc.iref.g.16"><b>6.1</b></a></li> 4934 <li><tt>parameter</tt> <a href="#rfc.iref.g. 42"><b>D.1.3</b></a></li>4930 <li><tt>parameter</tt> <a href="#rfc.iref.g.27"><b>6.5</b></a></li> 4935 4931 <li><tt>product</tt> <a href="#rfc.iref.g.19"><b>6.2</b></a></li> 4936 4932 <li><tt>product-version</tt> <a href="#rfc.iref.g.20"><b>6.2</b></a></li> 4937 <li><tt>Referer</tt> <a href="#rfc.iref.g. 31"><b>7.7</b></a></li>4938 <li><tt>Retry-After</tt> <a href="#rfc.iref.g. 32"><b>7.8</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> 4939 4935 <li><tt>rfc1123-date</tt> <a href="#rfc.iref.g.4"><b>6.1</b></a></li> 4940 4936 <li><tt>rfc850-date</tt> <a href="#rfc.iref.g.17"><b>6.1</b></a></li> 4941 4937 <li><tt>second</tt> <a href="#rfc.iref.g.9"><b>6.1</b></a></li> 4942 <li><tt>Server</tt> <a href="#rfc.iref.g. 34"><b>7.9</b></a></li>4943 <li><tt>subtype</tt> <a href="#rfc.iref.g. 41"><b>D.1.3</b></a></li>4938 <li><tt>Server</tt> <a href="#rfc.iref.g.44"><b>7.9</b></a></li> 4939 <li><tt>subtype</tt> <a href="#rfc.iref.g.26"><b>6.5</b></a></li> 4944 4940 <li><tt>time-of-day</tt> <a href="#rfc.iref.g.6"><b>6.1</b></a></li> 4945 <li><tt>type</tt> <a href="#rfc.iref.g. 40"><b>D.1.3</b></a></li>4946 <li><tt>User-Agent</tt> <a href="#rfc.iref.g. 35"><b>7.10</b></a></li>4947 <li><tt>value</tt> <a href="#rfc.iref.g. 44"><b>D.1.3</b></a></li>4941 <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> 4943 <li><tt>value</tt> <a href="#rfc.iref.g.29"><b>6.5</b></a></li> 4948 4944 <li><tt>year</tt> <a href="#rfc.iref.g.14"><b>6.1</b></a></li> 4949 4945 </ul> 4950 4946 </li> 4951 <li>gzip (Coding Format) <a href="#rfc.iref.g. 38">D.1.2</a></li>4947 <li>gzip (Coding Format) <a href="#rfc.iref.g.23">6.4</a></li> 4952 4948 </ul> 4953 4949 </li> … … 4956 4952 <li>Header Fields 4957 4953 <ul> 4958 <li>Accept <a href="#rfc.xref.header.accept.1">3.2</a>, <a href="#rfc.xref.header.accept.2"> 8.3</a>, <a href="#rfc.xref.header.accept.3">D.1.3</a>, <a href="#rfc.xref.header.accept.4">D.4.1</a>, <a href="#rfc.iref.h.12"><b>D.5.1</b></a></li>4959 <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. 4.1</a>, <a href="#rfc.iref.h.13"><b>D.5.2</b></a>, <a href="#rfc.xref.header.accept-charset.4">D.10</a></li>4960 <li>Accept-Encoding <a href="#rfc.xref.header.accept-encoding.1">3.2</a>, <a href="#rfc.xref.header.accept-encoding.2"> 8.3</a>, <a href="#rfc.xref.header.accept-encoding.3">D.1.2</a>, <a href="#rfc.xref.header.accept-encoding.4">D.4.1</a>, <a href="#rfc.iref.h.14"><b>D.5.3</b></a>, <a href="#rfc.xref.header.accept-encoding.5">D.6.1</a></li>4961 <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. 4.1</a>, <a href="#rfc.iref.h.15"><b>D.5.4</b></a></li>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> 4962 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> 4963 <li>Content-Encoding <a href="#rfc.xref.header.content-encoding.1"> 8.3</a>, <a href="#rfc.xref.header.content-encoding.2">D.1.2</a>, <a href="#rfc.xref.header.content-encoding.3">D.3.1</a>, <a href="#rfc.iref.h.16"><b>D.5.5</b></a>, <a href="#rfc.xref.header.content-encoding.4">D.5.5</a></li>4964 <li>Content-Language <a href="#rfc.xref.header.content-language.1">8.3</a>, <a href="#rfc.xref.header.content-language.2">D. 3.1</a>, <a href="#rfc.iref.h.17"><b>D.5.6</b></a></li>4965 <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. 3.1</a>, <a href="#rfc.iref.h.18"><b>D.5.7</b></a>, <a href="#rfc.xref.header.content-location.5">D.10</a></li>4966 <li>Content-Transfer-Encoding <a href="#rfc.iref.h.21">D. 8.5</a>, <a href="#rfc.xref.no.content-transfer-encoding.1">D.10</a></li>4967 <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"> 8.3</a>, <a href="#rfc.xref.header.content-type.4">D.1.3</a>, <a href="#rfc.xref.header.content-type.5">D.3.1</a>, <a href="#rfc.iref.h.19"><b>D.5.8</b></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> 4968 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> 4969 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> … … 4971 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> 4972 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> 4973 <li>MIME-Version <a href="#rfc.xref.mime-version.1">8.3</a>, <a href="#rfc.iref.h.20"><b>D. 8.1</b></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> 4974 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> 4975 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> 4976 4972 <li>Server <a href="#rfc.xref.header.server.1">3.3</a>, <a href="#rfc.iref.h.10"><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> 4977 <li>User-Agent <a href="#rfc.xref.header.user-agent.1">3.2</a>, <a href="#rfc.iref.h.11"><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. 4.1</a></li>4973 <li>User-Agent <a href="#rfc.xref.header.user-agent.1">3.2</a>, <a href="#rfc.iref.h.11"><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> 4978 4974 </ul> 4979 4975 </li> … … 5002 4998 </ul> 5003 4999 </li> 5004 <li>MIME-Version header field <a href="#rfc.xref.mime-version.1">8.3</a>, <a href="#rfc.iref.m.10"><b>D. 8.1</b></a></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> 5005 5001 </ul> 5006 5002 </li> … … 5010 5006 </li> 5011 5007 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 5012 <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"> 7.3</a>, <a href="#rfc.xref.Part1.40">7.9</a>, <a href="#rfc.xref.Part1.41">7.9</a>, <a href="#rfc.xref.Part1.42">7.10</a>, <a href="#rfc.xref.Part1.43">10</a>, <a href="#Part1"><b>11.1</b></a>, <a href="#rfc.xref.Part1.44">A</a>, <a href="#rfc.xref.Part1.45">D.1.2</a>, <a href="#rfc.xref.Part1.46">D.1.2</a>, <a href="#rfc.xref.Part1.47">D.1.2</a>, <a href="#rfc.xref.Part1.48">D.1.2.1</a>, <a href="#rfc.xref.Part1.49">D.1.2.1</a>, <a href="#rfc.xref.Part1.50">D.2.1</a>, <a href="#rfc.xref.Part1.51">D.2.2</a>, <a href="#rfc.xref.Part1.52">D.4.1</a>, <a href="#rfc.xref.Part1.53">D.5.1</a>, <a href="#rfc.xref.Part1.54">D.5.3</a>, <a href="#rfc.xref.Part1.55">D.5.7</a>, <a href="#rfc.xref.Part1.56">D.6.1</a>, <a href="#rfc.xref.Part1.57">D.6.1</a>, <a href="#rfc.xref.Part1.58">D.6.1</a>, <a href="#rfc.xref.Part1.59">D.8.6</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> 5013 5009 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.3">1.3</a></li> 5014 5010 <li><em>Section 2</em> <a href="#rfc.xref.Part1.2">1.2</a></li> … … 5017 5013 <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> 5018 5014 <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> 5019 <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 0">7.9</a>, <a href="#rfc.xref.Part1.42">7.10</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.45">7.9</a>, <a href="#rfc.xref.Part1.47">7.10</a></li> 5020 5016 <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> 5021 5017 <li><em>Section 3.2.5</em> <a href="#rfc.xref.Part1.23">3.1</a></li> 5022 <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.51">D. 2.2</a></li>5023 <li><em>Section 3.3.1</em> <a href="#rfc.xref.Part1.59">D. 8.6</a></li>5024 <li><em>Section 3.3.2</em> <a href="#rfc.xref.Part1.50">D. 2.1</a></li>5025 <li><em>Section 4</em> <a href="#rfc.xref.Part1.4 8">D.1.2.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.51">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.50">D.1.1</a></li> 5021 <li><em>Section 4</em> <a href="#rfc.xref.Part1.42">6.4.1</a></li> 5026 5022 <li><em>Section 4.1</em> <a href="#rfc.xref.Part1.27">3.1</a></li> 5027 <li><em>Section 4.2.1</em> <a href="#rfc.xref.Part1. 45">D.1.2</a>, <a href="#rfc.xref.Part1.56">D.6.1</a></li>5028 <li><em>Section 4.2</em> <a href="#rfc.xref.Part1.4 9">D.1.2.1</a></li>5029 <li><em>Section 4.2.2</em> <a href="#rfc.xref.Part1.4 6">D.1.2</a>, <a href="#rfc.xref.Part1.57">D.6.1</a></li>5030 <li><em>Section 4.2.3</em> <a href="#rfc.xref.Part1.4 7">D.1.2</a>, <a href="#rfc.xref.Part1.58">D.6.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> 5024 <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> 5031 5027 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.29">3.2</a></li> 5032 <li><em>Section 4.3.1</em> <a href="#rfc.xref.Part1.52">D. 4.1</a>, <a href="#rfc.xref.Part1.53">D.5.1</a>, <a href="#rfc.xref.Part1.54">D.5.3</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> 5033 5029 <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> 5034 5030 <li><em>Section 5.4</em> <a href="#rfc.xref.Part1.28">3.2</a></li> 5035 <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. 5.7</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> 5036 5032 <li><em>Section 6.1</em> <a href="#rfc.xref.Part1.26">3.1</a></li> 5037 <li><em>Section 6.2</em> <a href="#rfc.xref.Part1.19">2.3.7</a>, <a href="#rfc.xref.Part1.4 1">7.9</a>, <a href="#rfc.xref.Part1.44">A</a></li>5038 <li><em>Section 6.4.3</em> <a href="#rfc.xref.Part1.31">4.3.1</a>, <a href="#rfc.xref.Part1. 39">7.3</a></li>5033 <li><em>Section 6.2</em> <a href="#rfc.xref.Part1.19">2.3.7</a>, <a href="#rfc.xref.Part1.46">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.44">7.3</a></li> 5039 5035 <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> 5040 5036 <li><em>Section 7.3.1</em> <a href="#rfc.xref.Part1.20">2.3.7</a></li> 5041 <li><em>Section 9</em> <a href="#rfc.xref.Part1.4 3">10</a></li>5037 <li><em>Section 9</em> <a href="#rfc.xref.Part1.48">10</a></li> 5042 5038 </ul> 5043 5039 </li> 5044 <li><em>Part4</em> <a href="#rfc.xref.Part4.1">3.2</a>, <a href="#rfc.xref.Part4.2">3.2</a>, <a href="#rfc.xref.Part4.3">3.2</a>, <a href="#rfc.xref.Part4.4">3.2</a>, <a href="#rfc.xref.Part4.5">3.3</a>, <a href="#rfc.xref.Part4.6">4.1</a>, <a href="#rfc.xref.Part4.7">4.1</a>, <a href="#rfc.xref.Part4.8">4.1</a>, <a href="#rfc.xref.Part4.9">4.4.2</a>, <a href="#rfc.xref.Part4.10">4.5</a>, <a href="#Part4"><b>11.1</b></a>, <a href="#rfc.xref.Part4.11">C.2</a>, <a href="#rfc.xref.Part4.12">D. 3.1</a>, <a href="#rfc.xref.Part4.13">D.3.1</a><ul>5045 <li><em>Section 2.2</em> <a href="#rfc.xref.Part4.13">D. 3.1</a></li>5046 <li><em>Section 2.3</em> <a href="#rfc.xref.Part4.5">3.3</a>, <a href="#rfc.xref.Part4.9">4.4.2</a>, <a href="#rfc.xref.Part4.12">D. 3.1</a></li>5040 <li><em>Part4</em> <a href="#rfc.xref.Part4.1">3.2</a>, <a href="#rfc.xref.Part4.2">3.2</a>, <a href="#rfc.xref.Part4.3">3.2</a>, <a href="#rfc.xref.Part4.4">3.2</a>, <a href="#rfc.xref.Part4.5">3.3</a>, <a href="#rfc.xref.Part4.6">4.1</a>, <a href="#rfc.xref.Part4.7">4.1</a>, <a href="#rfc.xref.Part4.8">4.1</a>, <a href="#rfc.xref.Part4.9">4.4.2</a>, <a href="#rfc.xref.Part4.10">4.5</a>, <a href="#Part4"><b>11.1</b></a>, <a href="#rfc.xref.Part4.11">C.2</a>, <a href="#rfc.xref.Part4.12">D.2.1</a>, <a href="#rfc.xref.Part4.13">D.2.1</a><ul> 5041 <li><em>Section 2.2</em> <a href="#rfc.xref.Part4.13">D.2.1</a></li> 5042 <li><em>Section 2.3</em> <a href="#rfc.xref.Part4.5">3.3</a>, <a href="#rfc.xref.Part4.9">4.4.2</a>, <a href="#rfc.xref.Part4.12">D.2.1</a></li> 5047 5043 <li><em>Section 3.1</em> <a href="#rfc.xref.Part4.1">3.2</a></li> 5048 5044 <li><em>Section 3.2</em> <a href="#rfc.xref.Part4.3">3.2</a></li> … … 5054 5050 </ul> 5055 5051 </li> 5056 <li><em>Part5</em> <a href="#rfc.xref.Part5.1">2.3.2</a>, <a href="#rfc.xref.Part5.2">3.2</a>, <a href="#rfc.xref.Part5.3">3.2</a>, <a href="#rfc.xref.Part5.4">3.3</a>, <a href="#rfc.xref.Part5.5">4.1</a>, <a href="#rfc.xref.Part5.6">4.1</a>, <a href="#rfc.xref.Part5.7">4.1</a>, <a href="#Part5"><b>11.1</b></a>, <a href="#rfc.xref.Part5.8">D. 2.1</a><ul>5052 <li><em>Part5</em> <a href="#rfc.xref.Part5.1">2.3.2</a>, <a href="#rfc.xref.Part5.2">3.2</a>, <a href="#rfc.xref.Part5.3">3.2</a>, <a href="#rfc.xref.Part5.4">3.3</a>, <a href="#rfc.xref.Part5.5">4.1</a>, <a href="#rfc.xref.Part5.6">4.1</a>, <a href="#rfc.xref.Part5.7">4.1</a>, <a href="#Part5"><b>11.1</b></a>, <a href="#rfc.xref.Part5.8">D.1.1</a><ul> 5057 5053 <li><em>Section 3</em> <a href="#rfc.xref.Part5.5">4.1</a></li> 5058 5054 <li><em>Section 3.1</em> <a href="#rfc.xref.Part5.6">4.1</a></li> 5059 5055 <li><em>Section 3.2</em> <a href="#rfc.xref.Part5.7">4.1</a></li> 5060 5056 <li><em>Section 5.1</em> <a href="#rfc.xref.Part5.4">3.3</a></li> 5061 <li><em>Section 5.2</em> <a href="#rfc.xref.Part5.8">D. 2.1</a></li>5057 <li><em>Section 5.2</em> <a href="#rfc.xref.Part5.8">D.1.1</a></li> 5062 5058 <li><em>Section 5.3</em> <a href="#rfc.xref.Part5.2">3.2</a></li> 5063 5059 <li><em>Section 5.4</em> <a href="#rfc.xref.Part5.1">2.3.2</a>, <a href="#rfc.xref.Part5.3">3.2</a></li> 5064 5060 </ul> 5065 5061 </li> 5066 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">2.2.1</a>, <a href="#rfc.xref.Part6.2">2.3.2</a>, <a href="#rfc.xref.Part6.3">2.3.3</a>, <a href="#rfc.xref.Part6.4">2.3.4</a>, <a href="#rfc.xref.Part6.5">2.3.5</a>, <a href="#rfc.xref.Part6.6">2.3.6</a>, <a href="#rfc.xref.Part6.7">3.1</a>, <a href="#rfc.xref.Part6.8">3.3</a>, <a href="#rfc.xref.Part6.9">3.3</a>, <a href="#rfc.xref.Part6.10">4.2.1</a>, <a href="#rfc.xref.Part6.11">4.4.1</a>, <a href="#rfc.xref.Part6.12">4.4.4</a>, <a href="#rfc.xref.Part6.13">4.4.4</a>, <a href="#rfc.xref.Part6.14">4.4.4</a>, <a href="#rfc.xref.Part6.15">4.5.1</a>, <a href="#rfc.xref.Part6.16">4.5.2</a>, <a href="#rfc.xref.Part6.17">4.6.9</a>, <a href="#Part6"><b>11.1</b></a>, <a href="#rfc.xref.Part6.18">D. 3.1</a>, <a href="#rfc.xref.Part6.19">D.4.1</a><ul>5062 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">2.2.1</a>, <a href="#rfc.xref.Part6.2">2.3.2</a>, <a href="#rfc.xref.Part6.3">2.3.3</a>, <a href="#rfc.xref.Part6.4">2.3.4</a>, <a href="#rfc.xref.Part6.5">2.3.5</a>, <a href="#rfc.xref.Part6.6">2.3.6</a>, <a href="#rfc.xref.Part6.7">3.1</a>, <a href="#rfc.xref.Part6.8">3.3</a>, <a href="#rfc.xref.Part6.9">3.3</a>, <a href="#rfc.xref.Part6.10">4.2.1</a>, <a href="#rfc.xref.Part6.11">4.4.1</a>, <a href="#rfc.xref.Part6.12">4.4.4</a>, <a href="#rfc.xref.Part6.13">4.4.4</a>, <a href="#rfc.xref.Part6.14">4.4.4</a>, <a href="#rfc.xref.Part6.15">4.5.1</a>, <a href="#rfc.xref.Part6.16">4.5.2</a>, <a href="#rfc.xref.Part6.17">4.6.9</a>, <a href="#Part6"><b>11.1</b></a>, <a href="#rfc.xref.Part6.18">D.2.1</a>, <a href="#rfc.xref.Part6.19">D.3.1</a><ul> 5067 5063 <li><em>Section 2.3.1</em> <a href="#rfc.xref.Part6.4">2.3.4</a></li> 5068 5064 <li><em>Section 2.3.1.1</em> <a href="#rfc.xref.Part6.11">4.4.1</a>, <a href="#rfc.xref.Part6.14">4.4.4</a>, <a href="#rfc.xref.Part6.15">4.5.1</a>, <a href="#rfc.xref.Part6.16">4.5.2</a>, <a href="#rfc.xref.Part6.17">4.6.9</a></li> … … 5071 5067 <li><em>Section 3.1</em> <a href="#rfc.xref.Part6.8">3.3</a></li> 5072 5068 <li><em>Section 3.2</em> <a href="#rfc.xref.Part6.12">4.4.4</a></li> 5073 <li><em>Section 3.3</em> <a href="#rfc.xref.Part6.18">D. 3.1</a></li>5074 <li><em>Section 3.5</em> <a href="#rfc.xref.Part6.9">3.3</a>, <a href="#rfc.xref.Part6.19">D. 4.1</a></li>5069 <li><em>Section 3.3</em> <a href="#rfc.xref.Part6.18">D.2.1</a></li> 5070 <li><em>Section 3.5</em> <a href="#rfc.xref.Part6.9">3.3</a>, <a href="#rfc.xref.Part6.19">D.3.1</a></li> 5075 5071 <li><em>Section 3.6</em> <a href="#rfc.xref.Part6.13">4.4.4</a></li> 5076 5072 </ul> … … 5086 5082 </ul> 5087 5083 </li> 5088 <li>payload <a href="#rfc.iref.p.3">D. 2</a></li>5084 <li>payload <a href="#rfc.iref.p.3">D.1</a></li> 5089 5085 <li>POST method <a href="#rfc.iref.p.1"><b>2.3.4</b></a>, <a href="#rfc.xref.POST.1">8.1</a>, <a href="#rfc.xref.POST.2">A</a></li> 5090 5086 <li>PUT method <a href="#rfc.iref.p.2"><b>2.3.5</b></a>, <a href="#rfc.xref.PUT.1">8.1</a>, <a href="#rfc.xref.PUT.2">A</a></li> … … 5093 5089 <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul> 5094 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> 5095 <li>representation <a href="#rfc.iref.r.3">D. 3</a></li>5091 <li>representation <a href="#rfc.iref.r.3">D.2</a></li> 5096 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> 5097 5093 <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> … … 5099 5095 </ul> 5100 5096 </li> 5101 <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. 9</a><ul>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> 5102 5098 <li><em>Section 9.3</em> <a href="#rfc.xref.RFC1945.1">4.5</a></li> 5103 5099 </ul> 5104 5100 </li> 5105 <li><em>RFC1950</em> <a href="#RFC1950"><b>11.1</b></a>, <a href="#rfc.xref.RFC1950.1">D. 6.1</a></li>5106 <li><em>RFC1951</em> <a href="#RFC1951"><b>11.1</b></a>, <a href="#rfc.xref.RFC1951.1">D. 6.1</a></li>5107 <li><em>RFC1952</em> <a href="#RFC1952"><b>11.1</b></a>, <a href="#rfc.xref.RFC1952.1">D. 6.1</a></li>5108 <li><em>RFC2045</em> <a href="#RFC2045"><b>11.1</b></a>, <a href="#rfc.xref.RFC2045.1">D. 8</a>, <a href="#rfc.xref.RFC2045.2">D.8.1</a></li>5109 <li><em>RFC2046</em> <a href="# RFC2046"><b>11.1</b></a>, <a href="#rfc.xref.RFC2046.1">D.1.3</a>, <a href="#rfc.xref.RFC2046.2">D.1.3.2</a>, <a href="#rfc.xref.RFC2046.3">D.3.2</a>, <a href="#rfc.xref.RFC2046.4">D.8.2</a><ul>5110 <li><em>Section 4.5.1</em> <a href="#rfc.xref.RFC2046.3">D. 3.2</a></li>5111 <li><em>Section 5.1.1</em> <a href="#rfc.xref.RFC2046.2"> D.1.3.2</a></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> 5106 <li><em>Section 4.5.1</em> <a href="#rfc.xref.RFC2046.3">D.2.2</a></li> 5107 <li><em>Section 5.1.1</em> <a href="#rfc.xref.RFC2046.2">6.5.2</a></li> 5112 5108 </ul> 5113 5109 </li> 5114 <li><em>RFC2049</em> <a href="#RFC2049"><b>11.2</b></a>, <a href="#rfc.xref.RFC2049.1">D. 8.2</a><ul>5115 <li><em>Section 4</em> <a href="#rfc.xref.RFC2049.1">D. 8.2</a></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> 5116 5112 </ul> 5117 5113 </li> 5118 <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. 9</a><ul>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> 5119 5115 <li><em>Section 10.3</em> <a href="#rfc.xref.RFC2068.2">4.5</a></li> 5120 5116 <li><em>Section 10.3.4</em> <a href="#rfc.xref.RFC2068.1">4.5</a></li> 5121 5117 </ul> 5122 5118 </li> 5123 <li><em>RFC2076</em> <a href="#RFC2076"><b>11.2</b></a>, <a href="#rfc.xref.RFC2076.1">D. 9</a></li>5119 <li><em>RFC2076</em> <a href="#RFC2076"><b>11.2</b></a>, <a href="#rfc.xref.RFC2076.1">D.8</a></li> 5124 5120 <li><em>RFC2119</em> <a href="#rfc.xref.RFC2119.1">1.2</a>, <a href="#RFC2119"><b>11.1</b></a></li> 5125 <li><em>RFC2277</em> <a href="# RFC2277"><b>11.2</b></a>, <a href="#rfc.xref.RFC2277.1">D.1.1</a></li>5126 <li><em>RFC2295</em> <a href="#RFC2295"><b>11.2</b></a>, <a href="#rfc.xref.RFC2295.1">D. 4</a></li>5127 <li><em>RFC2388</em> <a href="# RFC2388"><b>11.2</b></a>, <a href="#rfc.xref.RFC2388.1">D.1.3.2</a></li>5128 <li><em>RFC2557</em> <a href="#RFC2557"><b>11.2</b></a>, <a href="#rfc.xref.RFC2557.1">D. 5.7</a>, <a href="#rfc.xref.RFC2557.2">D.8.7</a><ul>5129 <li><em>Section 4</em> <a href="#rfc.xref.RFC2557.1">D. 5.7</a></li>5121 <li><em>RFC2277</em> <a href="#rfc.xref.RFC2277.1">6.3</a>, <a href="#RFC2277"><b>11.2</b></a></li> 5122 <li><em>RFC2295</em> <a href="#RFC2295"><b>11.2</b></a>, <a href="#rfc.xref.RFC2295.1">D.3</a></li> 5123 <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> 5130 5126 </ul> 5131 5127 </li> 5132 <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. 5.4</a>, <a href="#rfc.xref.RFC2616.5">D.11.1</a><ul>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> 5133 5129 <li><em>Section 10.3.8</em> <a href="#rfc.xref.RFC2616.2">4.5</a></li> 5134 <li><em>Section 14.4</em> <a href="#rfc.xref.RFC2616.4">D. 5.4</a></li>5130 <li><em>Section 14.4</em> <a href="#rfc.xref.RFC2616.4">D.4.4</a></li> 5135 5131 </ul> 5136 5132 </li> … … 5139 5135 </ul> 5140 5136 </li> 5141 <li><em>RFC3629</em> <a href="# RFC3629"><b>11.2</b></a>, <a href="#rfc.xref.RFC3629.1">D.1.1</a></li>5137 <li><em>RFC3629</em> <a href="#rfc.xref.RFC3629.1">6.3</a>, <a href="#RFC3629"><b>11.2</b></a></li> 5142 5138 <li><em>RFC3864</em> <a href="#rfc.xref.RFC3864.1">3.1</a>, <a href="#rfc.xref.RFC3864.2">3.1</a>, <a href="#rfc.xref.RFC3864.3">8.3</a>, <a href="#RFC3864"><b>11.2</b></a><ul> 5143 5139 <li><em>Section 4.1</em> <a href="#rfc.xref.RFC3864.2">3.1</a></li> … … 5149 5145 </ul> 5150 5146 </li> 5151 <li><em>RFC4288</em> <a href="# RFC4288"><b>11.2</b></a>, <a href="#rfc.xref.RFC4288.1">D.1.3</a></li>5152 <li><em>RFC4647</em> <a href="#RFC4647"><b>11.1</b></a>, <a href="#rfc.xref.RFC4647.1">D. 5.4</a>, <a href="#rfc.xref.RFC4647.2">D.5.4</a>, <a href="#rfc.xref.RFC4647.3">D.5.4</a>, <a href="#rfc.xref.RFC4647.4">D.5.4</a><ul>5153 <li><em>Section 2.1</em> <a href="#rfc.xref.RFC4647.1">D. 5.4</a></li>5154 <li><em>Section 2.3</em> <a href="#rfc.xref.RFC4647.2">D. 5.4</a></li>5155 <li><em>Section 3</em> <a href="#rfc.xref.RFC4647.3">D. 5.4</a></li>5156 <li><em>Section 3.3.1</em> <a href="#rfc.xref.RFC4647.4">D. 5.4</a></li>5147 <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> 5157 5153 </ul> 5158 5154 </li> 5159 <li><em>RFC5226</em> <a href="#rfc.xref.RFC5226.1">2.2</a>, <a href="#rfc.xref.RFC5226.2">4.2</a>, <a href="# RFC5226"><b>11.2</b></a>, <a href="#rfc.xref.RFC5226.3">D.1.2.1</a><ul>5160 <li><em>Section 4.1</em> <a href="#rfc.xref.RFC5226.1">2.2</a>, <a href="#rfc.xref.RFC5226.2">4.2</a>, <a href="#rfc.xref.RFC5226.3"> D.1.2.1</a></li>5155 <li><em>RFC5226</em> <a href="#rfc.xref.RFC5226.1">2.2</a>, <a href="#rfc.xref.RFC5226.2">4.2</a>, <a href="#rfc.xref.RFC5226.3">6.4.1</a>, <a href="#RFC5226"><b>11.2</b></a><ul> 5156 <li><em>Section 4.1</em> <a href="#rfc.xref.RFC5226.1">2.2</a>, <a href="#rfc.xref.RFC5226.2">4.2</a>, <a href="#rfc.xref.RFC5226.3">6.4.1</a></li> 5161 5157 </ul> 5162 5158 </li> … … 5165 5161 </ul> 5166 5162 </li> 5167 <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. 8</a><ul>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> 5168 5164 <li><em>Section 3.3</em> <a href="#rfc.xref.RFC5322.1">6.1</a></li> 5169 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> … … 5171 5167 </ul> 5172 5168 </li> 5173 <li><em>RFC5646</em> <a href="# RFC5646"><b>11.1</b></a>, <a href="#rfc.xref.RFC5646.1">D.1.4</a>, <a href="#rfc.xref.RFC5646.2">D.1.4</a>, <a href="#rfc.xref.RFC5646.3">D.1.4</a><ul>5174 <li><em>Section 2.1</em> <a href="#rfc.xref.RFC5646.2"> D.1.4</a></li>5169 <li><em>RFC5646</em> <a href="#rfc.xref.RFC5646.1">6.6</a>, <a href="#rfc.xref.RFC5646.2">6.6</a>, <a href="#rfc.xref.RFC5646.3">6.6</a>, <a href="#RFC5646"><b>11.1</b></a><ul> 5170 <li><em>Section 2.1</em> <a href="#rfc.xref.RFC5646.2">6.6</a></li> 5175 5171 </ul> 5176 5172 </li> 5177 5173 <li><em>RFC5789</em> <a href="#rfc.xref.RFC5789.1">2.3.5</a>, <a href="#RFC5789"><b>11.2</b></a></li> 5178 5174 <li><em>RFC5987</em> <a href="#rfc.xref.RFC5987.1">3.1</a>, <a href="#RFC5987"><b>11.2</b></a></li> 5179 <li><em>RFC6151</em> <a href="#RFC6151"><b>11.2</b></a>, <a href="#rfc.xref.RFC6151.1">D. 10</a></li>5180 <li><em>RFC6266</em> <a href="#RFC6266"><b>11.2</b></a>, <a href="#rfc.xref.RFC6266.1">D. 9</a>, <a href="#rfc.xref.RFC6266.2">D.10</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> 5181 5177 </ul> 5182 5178 </li> … … 5232 5228 </li> 5233 5229 <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul> 5234 <li>User-Agent header field <a href="#rfc.xref.header.user-agent.1">3.2</a>, <a href="#rfc.iref.u.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. 4.1</a></li>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.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> 5235 5231 </ul> 5236 5232 </li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1643 r1644 2164 2164 2165 2165 2166 <section title=" Common Protocol Parameters" anchor="common.protocol.parameters">2166 <section title="Protocol Parameters" anchor="protocol.parameters"> 2167 2167 <section title="Date/Time Formats" anchor="http.date"> 2168 2168 <x:anchor-alias value="HTTP-date"/> … … 2340 2340 the same product &SHOULD; only differ in the product-version portion of 2341 2341 the product value). 2342 </t> 2343 </section> 2344 2345 <section title="Character Encodings (charset)" anchor="character.sets"> 2346 <t> 2347 HTTP uses charset names to indicate the character encoding of a 2348 textual representation. 2349 </t> 2350 <t anchor="rule.charset"> 2351 <x:anchor-alias value="charset"/> 2352 A character encoding is identified by a case-insensitive token. The 2353 complete set of tokens is defined by the IANA Character Set registry 2354 (<eref target="http://www.iana.org/assignments/character-sets"/>). 2355 </t> 2356 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="charset"/> 2357 <x:ref>charset</x:ref> = <x:ref>token</x:ref> 2358 </artwork></figure> 2359 <t> 2360 Although HTTP allows an arbitrary token to be used as a charset 2361 value, any token that has a predefined value within the IANA 2362 Character Set registry &MUST; represent the character encoding defined 2363 by that registry. Applications &SHOULD; limit their use of character 2364 encodings to those defined within the IANA registry. 2365 </t> 2366 <t> 2367 HTTP uses charset in two contexts: within an Accept-Charset request 2368 header field (in which the charset value is an unquoted token) and as the 2369 value of a parameter in a Content-Type header field (within a request or 2370 response), in which case the parameter value of the charset parameter 2371 can be quoted. 2372 </t> 2373 <t> 2374 Implementors need to be aware of IETF character set requirements <xref target="RFC3629"/> 2375 <xref target="RFC2277"/>. 2376 </t> 2377 </section> 2378 2379 <section title="Content Codings" anchor="content.codings"> 2380 <x:anchor-alias value="content-coding"/> 2381 <t> 2382 Content coding values indicate an encoding transformation that has 2383 been or can be applied to a representation. Content codings are primarily 2384 used to allow a representation to be compressed or otherwise usefully 2385 transformed without losing the identity of its underlying media type 2386 and without loss of information. Frequently, the representation is stored in 2387 coded form, transmitted directly, and only decoded by the recipient. 2388 </t> 2389 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="content-coding"/> 2390 <x:ref>content-coding</x:ref> = <x:ref>token</x:ref> 2391 </artwork></figure> 2392 <t> 2393 All content-coding values are case-insensitive. HTTP/1.1 uses 2394 content-coding values in the Accept-Encoding (<xref target="header.accept-encoding"/>) and 2395 Content-Encoding (<xref target="header.content-encoding"/>) header fields. Although the value 2396 describes the content-coding, what is more important is that it 2397 indicates what decoding mechanism will be required to remove the 2398 encoding. 2399 </t> 2400 <t> 2401 compress<iref item="compress (Coding Format)"/><iref item="Coding Format" subitem="compress"/> 2402 <list> 2403 <t> 2404 See &compress-coding;. 2405 </t> 2406 </list> 2407 </t> 2408 <t> 2409 deflate<iref item="deflate (Coding Format)"/><iref item="Coding Format" subitem="deflate"/> 2410 <list> 2411 <t> 2412 See &deflate-coding;. 2413 </t> 2414 </list> 2415 </t> 2416 <t> 2417 gzip<iref item="gzip (Coding Format)"/><iref item="Coding Format" subitem="gzip"/> 2418 <list> 2419 <t> 2420 See &gzip-coding;. 2421 </t> 2422 </list> 2423 </t> 2424 2425 <section title="Content Coding Registry" anchor="content.coding.registry"> 2426 <t> 2427 The HTTP Content Coding Registry defines the name space for the content 2428 coding names. 2429 </t> 2430 <t> 2431 Registrations &MUST; include the following fields: 2432 <list style="symbols"> 2433 <t>Name</t> 2434 <t>Description</t> 2435 <t>Pointer to specification text</t> 2436 </list> 2437 </t> 2438 <t> 2439 Names of content codings &MUST-NOT; overlap with names of transfer codings 2440 (&transfer-codings;), unless the encoding transformation is identical (as 2441 is the case for the compression codings defined in 2442 &compression-codings;). 2443 </t> 2444 <t> 2445 Values to be added to this name space require IETF Review 2446 (see <xref target="RFC5226" x:fmt="of" x:sec="4.1"/>), and &MUST; 2447 conform to the purpose of content coding defined in this section. 2448 </t> 2449 <t> 2450 The registry itself is maintained at 2451 <eref target="http://www.iana.org/assignments/http-parameters"/>. 2452 </t> 2453 </section> 2454 2455 </section> 2456 2457 <section title="Media Types" anchor="media.types"> 2458 <x:anchor-alias value="media-type"/> 2459 <x:anchor-alias value="type"/> 2460 <x:anchor-alias value="subtype"/> 2461 <t> 2462 HTTP uses Internet Media Types <xref target="RFC2046"/> in the Content-Type (<xref target="header.content-type"/>) 2463 and Accept (<xref target="header.accept"/>) header fields in order to provide 2464 open and extensible data typing and type negotiation. 2465 </t> 2466 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="media-type"/><iref primary="true" item="Grammar" subitem="type"/><iref primary="true" item="Grammar" subitem="subtype"/> 2467 <x:ref>media-type</x:ref> = <x:ref>type</x:ref> "/" <x:ref>subtype</x:ref> *( <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> <x:ref>parameter</x:ref> ) 2468 <x:ref>type</x:ref> = <x:ref>token</x:ref> 2469 <x:ref>subtype</x:ref> = <x:ref>token</x:ref> 2470 </artwork></figure> 2471 <t anchor="rule.parameter"> 2472 <x:anchor-alias value="attribute"/> 2473 <x:anchor-alias value="parameter"/> 2474 <x:anchor-alias value="value"/> 2475 The type/subtype &MAY; be followed by parameters in the form of 2476 attribute/value pairs. 2477 </t> 2478 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="parameter"/><iref primary="true" item="Grammar" subitem="attribute"/><iref primary="true" item="Grammar" subitem="value"/> 2479 <x:ref>parameter</x:ref> = <x:ref>attribute</x:ref> "=" <x:ref>value</x:ref> 2480 <x:ref>attribute</x:ref> = <x:ref>token</x:ref> 2481 <x:ref>value</x:ref> = <x:ref>word</x:ref> 2482 </artwork></figure> 2483 <t> 2484 The type, subtype, and parameter attribute names are case-insensitive. 2485 Parameter values might or might not be case-sensitive, depending on the 2486 semantics of the parameter name. The presence or absence of a parameter might 2487 be significant to the processing of a media-type, depending on its 2488 definition within the media type registry. 2489 </t> 2490 <t> 2491 A parameter value that matches the <x:ref>token</x:ref> production can be 2492 transmitted as either a token or within a quoted-string. The quoted and 2493 unquoted values are equivalent. 2494 </t> 2495 <t> 2496 Note that some older HTTP applications do not recognize media type 2497 parameters. When sending data to older HTTP applications, 2498 implementations &SHOULD; only use media type parameters when they are 2499 required by that type/subtype definition. 2500 </t> 2501 <t> 2502 Media-type values are registered with the Internet Assigned Number 2503 Authority (IANA). The media type registration process is 2504 outlined in <xref target="RFC4288"/>. Use of non-registered media types is 2505 discouraged. 2506 </t> 2507 2508 <section title="Canonicalization and Text Defaults" anchor="canonicalization.and.text.defaults"> 2509 <t> 2510 Internet media types are registered with a canonical form. A 2511 representation transferred via HTTP messages &MUST; be in the 2512 appropriate canonical form prior to its transmission except for 2513 "text" types, as defined in the next paragraph. 2514 </t> 2515 <t> 2516 When in canonical form, media subtypes of the "text" type use CRLF as 2517 the text line break. HTTP relaxes this requirement and allows the 2518 transport of text media with plain CR or LF alone representing a line 2519 break when it is done consistently for an entire representation. HTTP 2520 applications &MUST; accept CRLF, bare CR, and bare LF as indicating 2521 a line break in text media received via HTTP. In 2522 addition, if the text is in a character encoding that does not 2523 use octets 13 and 10 for CR and LF respectively, as is the case for 2524 some multi-byte character encodings, HTTP allows the use of whatever octet 2525 sequences are defined by that character encoding to represent the 2526 equivalent of CR and LF for line breaks. This flexibility regarding 2527 line breaks applies only to text media in the payload body; a bare CR 2528 or LF &MUST-NOT; be substituted for CRLF within any of the HTTP control 2529 structures (such as header fields and multipart boundaries). 2530 </t> 2531 <t> 2532 If a representation is encoded with a content-coding, the underlying 2533 data &MUST; be in a form defined above prior to being encoded. 2534 </t> 2535 </section> 2536 2537 <section title="Multipart Types" anchor="multipart.types"> 2538 <t> 2539 MIME provides for a number of "multipart" types — encapsulations of 2540 one or more representations within a single message body. All multipart 2541 types share a common syntax, as defined in <xref target="RFC2046" x:sec="5.1.1" x:fmt="of"/>, 2542 and &MUST; include a boundary parameter as part of the media type 2543 value. The message body is itself a protocol element and &MUST; 2544 therefore use only CRLF to represent line breaks between body-parts. 2545 </t> 2546 <t> 2547 In general, HTTP treats a multipart message body no differently than 2548 any other media type: strictly as payload. HTTP does not use the 2549 multipart boundary as an indicator of message body length. 2550 <!-- jre: re-insert removed text pointing to caching? --> 2551 In all other respects, an HTTP user agent &SHOULD; follow the same or similar 2552 behavior as a MIME user agent would upon receipt of a multipart type. 2553 The MIME header fields within each body-part of a multipart message body 2554 do not have any significance to HTTP beyond that defined by 2555 their MIME semantics. 2556 </t> 2557 <t> 2558 If an application receives an unrecognized multipart subtype, the 2559 application &MUST; treat it as being equivalent to "multipart/mixed". 2560 </t> 2561 <x:note> 2562 <t> 2563 <x:h>Note:</x:h> The "multipart/form-data" type has been specifically defined 2564 for carrying form data suitable for processing via the POST 2565 request method, as described in <xref target="RFC2388"/>. 2566 </t> 2567 </x:note> 2568 </section> 2569 </section> 2570 2571 <section title="Language Tags" anchor="language.tags"> 2572 <x:anchor-alias value="language-tag"/> 2573 <t> 2574 A language tag, as defined in <xref target="RFC5646"/>, identifies a 2575 natural language spoken, written, or otherwise conveyed by human beings for 2576 communication of information to other human beings. Computer languages are 2577 explicitly excluded. HTTP uses language tags within the Accept-Language and 2578 Content-Language fields. 2579 </t> 2580 <t> 2581 In summary, a language tag is composed of one or more parts: A primary 2582 language subtag followed by a possibly empty series of subtags: 2583 </t> 2584 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="language-tag"/> 2585 <x:ref>language-tag</x:ref> = <Language-Tag, defined in <xref target="RFC5646" x:sec="2.1"/>> 2586 </artwork></figure> 2587 <t> 2588 White space is not allowed within the tag and all tags are case-insensitive. 2589 The name space of language subtags is administered by the IANA (see 2590 <eref target="http://www.iana.org/assignments/language-subtag-registry"/>). 2591 </t> 2592 <figure> 2593 <preamble>Example tags include:</preamble> 2594 <artwork type="example"> 2595 en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN 2596 </artwork> 2597 </figure> 2598 <t> 2599 See <xref target="RFC5646"/> for further information. 2342 2600 </t> 2343 2601 </section> … … 4931 5189 4932 5190 <section title="THE TEXT FORMERLY KNOWN AS PART3"> 4933 <section title="Protocol Parameters" anchor="protocol.parameters">4934 4935 <section title="Character Encodings (charset)" anchor="character.sets">4936 <t>4937 HTTP uses charset names to indicate the character encoding of a4938 textual representation.4939 </t>4940 <t anchor="rule.charset">4941 <x:anchor-alias value="charset"/>4942 A character encoding is identified by a case-insensitive token. The4943 complete set of tokens is defined by the IANA Character Set registry4944 (<eref target="http://www.iana.org/assignments/character-sets"/>).4945 </t>4946 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="charset"/>4947 <x:ref>charset</x:ref> = <x:ref>token</x:ref>4948 </artwork></figure>4949 <t>4950 Although HTTP allows an arbitrary token to be used as a charset4951 value, any token that has a predefined value within the IANA4952 Character Set registry &MUST; represent the character encoding defined4953 by that registry. Applications &SHOULD; limit their use of character4954 encodings to those defined within the IANA registry.4955 </t>4956 <t>4957 HTTP uses charset in two contexts: within an Accept-Charset request4958 header field (in which the charset value is an unquoted token) and as the4959 value of a parameter in a Content-Type header field (within a request or4960 response), in which case the parameter value of the charset parameter4961 can be quoted.4962 </t>4963 <t>4964 Implementors need to be aware of IETF character set requirements <xref target="RFC3629"/>4965 <xref target="RFC2277"/>.4966 </t>4967 </section>4968 4969 <section title="Content Codings" anchor="content.codings">4970 <x:anchor-alias value="content-coding"/>4971 <t>4972 Content coding values indicate an encoding transformation that has4973 been or can be applied to a representation. Content codings are primarily4974 used to allow a representation to be compressed or otherwise usefully4975 transformed without losing the identity of its underlying media type4976 and without loss of information. Frequently, the representation is stored in4977 coded form, transmitted directly, and only decoded by the recipient.4978 </t>4979 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="content-coding"/>4980 <x:ref>content-coding</x:ref> = <x:ref>token</x:ref>4981 </artwork></figure>4982 <t>4983 All content-coding values are case-insensitive. HTTP/1.1 uses4984 content-coding values in the Accept-Encoding (<xref target="header.accept-encoding"/>) and4985 Content-Encoding (<xref target="header.content-encoding"/>) header fields. Although the value4986 describes the content-coding, what is more important is that it4987 indicates what decoding mechanism will be required to remove the4988 encoding.4989 </t>4990 <t>4991 compress<iref item="compress (Coding Format)"/><iref item="Coding Format" subitem="compress"/>4992 <list>4993 <t>4994 See &compress-coding;.4995 </t>4996 </list>4997 </t>4998 <t>4999 deflate<iref item="deflate (Coding Format)"/><iref item="Coding Format" subitem="deflate"/>5000 <list>5001 <t>5002 See &deflate-coding;.5003 </t>5004 </list>5005 </t>5006 <t>5007 gzip<iref item="gzip (Coding Format)"/><iref item="Coding Format" subitem="gzip"/>5008 <list>5009 <t>5010 See &gzip-coding;.5011 </t>5012 </list>5013 </t>5014 5015 <section title="Content Coding Registry" anchor="content.coding.registry">5016 <t>5017 The HTTP Content Coding Registry defines the name space for the content5018 coding names.5019 </t>5020 <t>5021 Registrations &MUST; include the following fields:5022 <list style="symbols">5023 <t>Name</t>5024 <t>Description</t>5025 <t>Pointer to specification text</t>5026 </list>5027 </t>5028 <t>5029 Names of content codings &MUST-NOT; overlap with names of transfer codings5030 (&transfer-codings;), unless the encoding transformation is identical (as5031 is the case for the compression codings defined in5032 &compression-codings;).5033 </t>5034 <t>5035 Values to be added to this name space require IETF Review5036 (see <xref target="RFC5226" x:fmt="of" x:sec="4.1"/>), and &MUST;5037 conform to the purpose of content coding defined in this section.5038 </t>5039 <t>5040 The registry itself is maintained at5041 <eref target="http://www.iana.org/assignments/http-parameters"/>.5042 </t>5043 </section>5044 5045 </section>5046 5047 <section title="Media Types" anchor="media.types">5048 <x:anchor-alias value="media-type"/>5049 <x:anchor-alias value="type"/>5050 <x:anchor-alias value="subtype"/>5051 <t>5052 HTTP uses Internet Media Types <xref target="RFC2046"/> in the Content-Type (<xref target="header.content-type"/>)5053 and Accept (<xref target="header.accept"/>) header fields in order to provide5054 open and extensible data typing and type negotiation.5055 </t>5056 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="media-type"/><iref primary="true" item="Grammar" subitem="type"/><iref primary="true" item="Grammar" subitem="subtype"/>5057 <x:ref>media-type</x:ref> = <x:ref>type</x:ref> "/" <x:ref>subtype</x:ref> *( <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> <x:ref>parameter</x:ref> )5058 <x:ref>type</x:ref> = <x:ref>token</x:ref>5059 <x:ref>subtype</x:ref> = <x:ref>token</x:ref>5060 </artwork></figure>5061 <t anchor="rule.parameter">5062 <x:anchor-alias value="attribute"/>5063 <x:anchor-alias value="parameter"/>5064 <x:anchor-alias value="value"/>5065 The type/subtype &MAY; be followed by parameters in the form of5066 attribute/value pairs.5067 </t>5068 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="parameter"/><iref primary="true" item="Grammar" subitem="attribute"/><iref primary="true" item="Grammar" subitem="value"/>5069 <x:ref>parameter</x:ref> = <x:ref>attribute</x:ref> "=" <x:ref>value</x:ref>5070 <x:ref>attribute</x:ref> = <x:ref>token</x:ref>5071 <x:ref>value</x:ref> = <x:ref>word</x:ref>5072 </artwork></figure>5073 <t>5074 The type, subtype, and parameter attribute names are case-insensitive.5075 Parameter values might or might not be case-sensitive, depending on the5076 semantics of the parameter name. The presence or absence of a parameter might5077 be significant to the processing of a media-type, depending on its5078 definition within the media type registry.5079 </t>5080 <t>5081 A parameter value that matches the <x:ref>token</x:ref> production can be5082 transmitted as either a token or within a quoted-string. The quoted and5083 unquoted values are equivalent.5084 </t>5085 <t>5086 Note that some older HTTP applications do not recognize media type5087 parameters. When sending data to older HTTP applications,5088 implementations &SHOULD; only use media type parameters when they are5089 required by that type/subtype definition.5090 </t>5091 <t>5092 Media-type values are registered with the Internet Assigned Number5093 Authority (IANA). The media type registration process is5094 outlined in <xref target="RFC4288"/>. Use of non-registered media types is5095 discouraged.5096 </t>5097 5098 <section title="Canonicalization and Text Defaults" anchor="canonicalization.and.text.defaults">5099 <t>5100 Internet media types are registered with a canonical form. A5101 representation transferred via HTTP messages &MUST; be in the5102 appropriate canonical form prior to its transmission except for5103 "text" types, as defined in the next paragraph.5104 </t>5105 <t>5106 When in canonical form, media subtypes of the "text" type use CRLF as5107 the text line break. HTTP relaxes this requirement and allows the5108 transport of text media with plain CR or LF alone representing a line5109 break when it is done consistently for an entire representation. HTTP5110 applications &MUST; accept CRLF, bare CR, and bare LF as indicating5111 a line break in text media received via HTTP. In5112 addition, if the text is in a character encoding that does not5113 use octets 13 and 10 for CR and LF respectively, as is the case for5114 some multi-byte character encodings, HTTP allows the use of whatever octet5115 sequences are defined by that character encoding to represent the5116 equivalent of CR and LF for line breaks. This flexibility regarding5117 line breaks applies only to text media in the payload body; a bare CR5118 or LF &MUST-NOT; be substituted for CRLF within any of the HTTP control5119 structures (such as header fields and multipart boundaries).5120 </t>5121 <t>5122 If a representation is encoded with a content-coding, the underlying5123 data &MUST; be in a form defined above prior to being encoded.5124 </t>5125 </section>5126 5127 <section title="Multipart Types" anchor="multipart.types">5128 <t>5129 MIME provides for a number of "multipart" types — encapsulations of5130 one or more representations within a single message body. All multipart5131 types share a common syntax, as defined in <xref target="RFC2046" x:sec="5.1.1" x:fmt="of"/>,5132 and &MUST; include a boundary parameter as part of the media type5133 value. The message body is itself a protocol element and &MUST;5134 therefore use only CRLF to represent line breaks between body-parts.5135 </t>5136 <t>5137 In general, HTTP treats a multipart message body no differently than5138 any other media type: strictly as payload. HTTP does not use the5139 multipart boundary as an indicator of message body length.5140 <!-- jre: re-insert removed text pointing to caching? -->5141 In all other respects, an HTTP user agent &SHOULD; follow the same or similar5142 behavior as a MIME user agent would upon receipt of a multipart type.5143 The MIME header fields within each body-part of a multipart message body5144 do not have any significance to HTTP beyond that defined by5145 their MIME semantics.5146 </t>5147 <t>5148 If an application receives an unrecognized multipart subtype, the5149 application &MUST; treat it as being equivalent to "multipart/mixed".5150 </t>5151 <x:note>5152 <t>5153 <x:h>Note:</x:h> The "multipart/form-data" type has been specifically defined5154 for carrying form data suitable for processing via the POST5155 request method, as described in <xref target="RFC2388"/>.5156 </t>5157 </x:note>5158 </section>5159 </section>5160 5161 <section title="Language Tags" anchor="language.tags">5162 <x:anchor-alias value="language-tag"/>5163 <t>5164 A language tag, as defined in <xref target="RFC5646"/>, identifies a5165 natural language spoken, written, or otherwise conveyed by human beings for5166 communication of information to other human beings. Computer languages are5167 explicitly excluded. HTTP uses language tags within the Accept-Language and5168 Content-Language fields.5169 </t>5170 <t>5171 In summary, a language tag is composed of one or more parts: A primary5172 language subtag followed by a possibly empty series of subtags:5173 </t>5174 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="language-tag"/>5175 <x:ref>language-tag</x:ref> = <Language-Tag, defined in <xref target="RFC5646" x:sec="2.1"/>>5176 </artwork></figure>5177 <t>5178 White space is not allowed within the tag and all tags are case-insensitive.5179 The name space of language subtags is administered by the IANA (see5180 <eref target="http://www.iana.org/assignments/language-subtag-registry"/>).5181 </t>5182 <figure>5183 <preamble>Example tags include:</preamble>5184 <artwork type="example">5185 en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN5186 </artwork>5187 </figure>5188 <t>5189 See <xref target="RFC5646"/> for further information.5190 </t>5191 </section>5192 </section>5193 5191 5194 5192 <section title="Payload" anchor="payload"> -
draft-ietf-httpbis/latest/p3-payload.html
r1643 r1644 481 481 </ul> 482 482 <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="introduction" href="#introduction">Introduction</a></h1> 483 <p id="rfc.section.1.p.1">This part is now obsolete. Please see HTTPbis, Part 2.</p> 483 <p id="rfc.section.1.p.1">This part is now obsolete. Please see HTTPbis, Part 2. See also <<a href="http://trac.tools.ietf.org/wg/httpbis/trac/ticket/351">http://trac.tools.ietf.org/wg/httpbis/trac/ticket/351</a>>. 484 </p> 484 485 <div class="avoidbreak"> 485 486 <h1 id="rfc.authors"><a href="#rfc.authors">Authors' Addresses</a></h1> -
draft-ietf-httpbis/latest/p3-payload.xml
r1643 r1644 96 96 <t> 97 97 This part is now obsolete. Please see HTTPbis, Part 2. 98 See also <eref target="http://trac.tools.ietf.org/wg/httpbis/trac/ticket/351"/>. 98 99 </t> 99 100 </section>
Note: See TracChangeset
for help on using the changeset viewer.