Changeset 205 for draft-ietf-httpbis/latest/p3-payload.html
- Timestamp:
- 06/02/08 19:15:29 (14 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p3-payload.html
r204 r205 333 333 <link rel="Index" href="#rfc.index"> 334 334 <link rel="Chapter" title="1 Introduction" href="#rfc.section.1"> 335 <link rel="Chapter" title="2 Protocol Parameters" href="#rfc.section.2"> 336 <link rel="Chapter" title="3 Entity" href="#rfc.section.3"> 337 <link rel="Chapter" title="4 Content Negotiation" href="#rfc.section.4"> 338 <link rel="Chapter" title="5 Header Field Definitions" href="#rfc.section.5"> 339 <link rel="Chapter" title="6 IANA Considerations" href="#rfc.section.6"> 340 <link rel="Chapter" title="7 Security Considerations" href="#rfc.section.7"> 341 <link rel="Chapter" title="8 Acknowledgments" href="#rfc.section.8"> 342 <link rel="Chapter" href="#rfc.section.9" title="9 References"> 335 <link rel="Chapter" title="2 Notational Conventions and Generic Grammar" href="#rfc.section.2"> 336 <link rel="Chapter" title="3 Protocol Parameters" href="#rfc.section.3"> 337 <link rel="Chapter" title="4 Entity" href="#rfc.section.4"> 338 <link rel="Chapter" title="5 Content Negotiation" href="#rfc.section.5"> 339 <link rel="Chapter" title="6 Header Field Definitions" href="#rfc.section.6"> 340 <link rel="Chapter" title="7 IANA Considerations" href="#rfc.section.7"> 341 <link rel="Chapter" title="8 Security Considerations" href="#rfc.section.8"> 342 <link rel="Chapter" title="9 Acknowledgments" href="#rfc.section.9"> 343 <link rel="Chapter" href="#rfc.section.10" title="10 References"> 343 344 <link rel="Appendix" title="A Differences Between HTTP Entities and RFC 2045 Entities" href="#rfc.section.A"> 344 345 <link rel="Appendix" title="B Additional Features" href="#rfc.section.B"> … … 483 484 </ul> 484 485 </li> 485 <li class="tocline0">2. <a href="#protocol.parameters">Protocol Parameters</a><ul class="toc"> 486 <li class="tocline1">2.1 <a href="#character.sets">Character Sets</a><ul class="toc"> 487 <li class="tocline1">2.1.1 <a href="#missing.charset">Missing Charset</a></li> 486 <li class="tocline0">2. <a href="#notation">Notational Conventions and Generic Grammar</a></li> 487 <li class="tocline0">3. <a href="#protocol.parameters">Protocol Parameters</a><ul class="toc"> 488 <li class="tocline1">3.1 <a href="#character.sets">Character Sets</a><ul class="toc"> 489 <li class="tocline1">3.1.1 <a href="#missing.charset">Missing Charset</a></li> 488 490 </ul> 489 491 </li> 490 <li class="tocline1"> 2.2 <a href="#content.codings">Content Codings</a></li>491 <li class="tocline1"> 2.3 <a href="#media.types">Media Types</a><ul class="toc">492 <li class="tocline1"> 2.3.1 <a href="#canonicalization.and.text.defaults">Canonicalization and Text Defaults</a></li>493 <li class="tocline1"> 2.3.2 <a href="#multipart.types">Multipart Types</a></li>492 <li class="tocline1">3.2 <a href="#content.codings">Content Codings</a></li> 493 <li class="tocline1">3.3 <a href="#media.types">Media Types</a><ul class="toc"> 494 <li class="tocline1">3.3.1 <a href="#canonicalization.and.text.defaults">Canonicalization and Text Defaults</a></li> 495 <li class="tocline1">3.3.2 <a href="#multipart.types">Multipart Types</a></li> 494 496 </ul> 495 497 </li> 496 <li class="tocline1"> 2.4 <a href="#quality.values">Quality Values</a></li>497 <li class="tocline1"> 2.5 <a href="#language.tags">Language Tags</a></li>498 <li class="tocline1">3.4 <a href="#quality.values">Quality Values</a></li> 499 <li class="tocline1">3.5 <a href="#language.tags">Language Tags</a></li> 498 500 </ul> 499 501 </li> 500 <li class="tocline0"> 3. <a href="#entity">Entity</a><ul class="toc">501 <li class="tocline1"> 3.1 <a href="#entity.header.fields">Entity Header Fields</a></li>502 <li class="tocline1"> 3.2 <a href="#entity.body">Entity Body</a><ul class="toc">503 <li class="tocline1"> 3.2.1 <a href="#type">Type</a></li>504 <li class="tocline1"> 3.2.2 <a href="#entity.length">Entity Length</a></li>502 <li class="tocline0">4. <a href="#entity">Entity</a><ul class="toc"> 503 <li class="tocline1">4.1 <a href="#entity.header.fields">Entity Header Fields</a></li> 504 <li class="tocline1">4.2 <a href="#entity.body">Entity Body</a><ul class="toc"> 505 <li class="tocline1">4.2.1 <a href="#type">Type</a></li> 506 <li class="tocline1">4.2.2 <a href="#entity.length">Entity Length</a></li> 505 507 </ul> 506 508 </li> 507 509 </ul> 508 510 </li> 509 <li class="tocline0"> 4. <a href="#content.negotiation">Content Negotiation</a><ul class="toc">510 <li class="tocline1"> 4.1 <a href="#server-driven.negotiation">Server-driven Negotiation</a></li>511 <li class="tocline1"> 4.2 <a href="#agent-driven.negotiation">Agent-driven Negotiation</a></li>512 <li class="tocline1"> 4.3 <a href="#transparent.negotiation">Transparent Negotiation</a></li>511 <li class="tocline0">5. <a href="#content.negotiation">Content Negotiation</a><ul class="toc"> 512 <li class="tocline1">5.1 <a href="#server-driven.negotiation">Server-driven Negotiation</a></li> 513 <li class="tocline1">5.2 <a href="#agent-driven.negotiation">Agent-driven Negotiation</a></li> 514 <li class="tocline1">5.3 <a href="#transparent.negotiation">Transparent Negotiation</a></li> 513 515 </ul> 514 516 </li> 515 <li class="tocline0"> 5. <a href="#header.fields">Header Field Definitions</a><ul class="toc">516 <li class="tocline1"> 5.1 <a href="#header.accept">Accept</a></li>517 <li class="tocline1"> 5.2 <a href="#header.accept-charset">Accept-Charset</a></li>518 <li class="tocline1"> 5.3 <a href="#header.accept-encoding">Accept-Encoding</a></li>519 <li class="tocline1"> 5.4 <a href="#header.accept-language">Accept-Language</a></li>520 <li class="tocline1"> 5.5 <a href="#header.content-encoding">Content-Encoding</a></li>521 <li class="tocline1"> 5.6 <a href="#header.content-language">Content-Language</a></li>522 <li class="tocline1"> 5.7 <a href="#header.content-location">Content-Location</a></li>523 <li class="tocline1"> 5.8 <a href="#header.content-md5">Content-MD5</a></li>524 <li class="tocline1"> 5.9 <a href="#header.content-type">Content-Type</a></li>517 <li class="tocline0">6. <a href="#header.fields">Header Field Definitions</a><ul class="toc"> 518 <li class="tocline1">6.1 <a href="#header.accept">Accept</a></li> 519 <li class="tocline1">6.2 <a href="#header.accept-charset">Accept-Charset</a></li> 520 <li class="tocline1">6.3 <a href="#header.accept-encoding">Accept-Encoding</a></li> 521 <li class="tocline1">6.4 <a href="#header.accept-language">Accept-Language</a></li> 522 <li class="tocline1">6.5 <a href="#header.content-encoding">Content-Encoding</a></li> 523 <li class="tocline1">6.6 <a href="#header.content-language">Content-Language</a></li> 524 <li class="tocline1">6.7 <a href="#header.content-location">Content-Location</a></li> 525 <li class="tocline1">6.8 <a href="#header.content-md5">Content-MD5</a></li> 526 <li class="tocline1">6.9 <a href="#header.content-type">Content-Type</a></li> 525 527 </ul> 526 528 </li> 527 <li class="tocline0"> 6. <a href="#IANA.considerations">IANA Considerations</a></li>528 <li class="tocline0"> 7. <a href="#security.considerations">Security Considerations</a><ul class="toc">529 <li class="tocline1"> 7.1 <a href="#privacy.issues.connected.to.accept.headers">Privacy Issues Connected to Accept Headers</a></li>530 <li class="tocline1"> 7.2 <a href="#content-disposition.issues">Content-Disposition Issues</a></li>529 <li class="tocline0">7. <a href="#IANA.considerations">IANA Considerations</a></li> 530 <li class="tocline0">8. <a href="#security.considerations">Security Considerations</a><ul class="toc"> 531 <li class="tocline1">8.1 <a href="#privacy.issues.connected.to.accept.headers">Privacy Issues Connected to Accept Headers</a></li> 532 <li class="tocline1">8.2 <a href="#content-disposition.issues">Content-Disposition Issues</a></li> 531 533 </ul> 532 534 </li> 533 <li class="tocline0"> 8. <a href="#ack">Acknowledgments</a></li>534 <li class="tocline0"> 9. <a href="#rfc.references">References</a><ul class="toc">535 <li class="tocline1"> 9.1 <a href="#rfc.references.1">Normative References</a></li>536 <li class="tocline1"> 9.2 <a href="#rfc.references.2">Informative References</a></li>535 <li class="tocline0">9. <a href="#ack">Acknowledgments</a></li> 536 <li class="tocline0">10. <a href="#rfc.references">References</a><ul class="toc"> 537 <li class="tocline1">10.1 <a href="#rfc.references.1">Normative References</a></li> 538 <li class="tocline1">10.2 <a href="#rfc.references.2">Informative References</a></li> 537 539 </ul> 538 540 </li> … … 582 584 <p id="rfc.section.1.1.p.2">An implementation is not compliant if it fails to satisfy one or more of the <em class="bcp14">MUST</em> or <em class="bcp14">REQUIRED</em> level requirements for the protocols it implements. An implementation that satisfies all the <em class="bcp14">MUST</em> or <em class="bcp14">REQUIRED</em> level and all the <em class="bcp14">SHOULD</em> level requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the <em class="bcp14">MUST</em> level requirements but not all the <em class="bcp14">SHOULD</em> level requirements for its protocols is said to be "conditionally compliant." 583 585 </p> 584 <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1> 585 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> <a id="character.sets" href="#character.sets">Character Sets</a></h2> 586 <p id="rfc.section.2.1.p.1">HTTP uses the same definition of the term "character set" as that described for MIME:</p> 587 <p id="rfc.section.2.1.p.2">The term "character set" is used in this document to refer to a method used with one or more tables to convert a sequence 586 <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="notation" href="#notation">Notational Conventions and Generic Grammar</a></h1> 587 <p id="rfc.section.2.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation.abnf" title="Augmented BNF">Section 2.1</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> and the core rules defined in <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 2.2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>: <span class="comment">[abnf.dep: ABNF syntax and basic rules will be adopted from RFC 5234, see <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>>.]</span> 588 </p> 589 <div id="rfc.figure.u.1"></div><pre class="inline"> ALPHA = <ALPHA, defined in <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 2.2</a>> 590 DIGIT = <DIGIT, defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 2.2</a>> 591 OCTET = <OCTET, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 2.2</a>> 592 </pre><div id="rfc.figure.u.2"></div><pre class="inline"> quoted-string = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 2.2</a>> 593 token = <token, defined in <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 2.2</a>> 594 </pre><h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1> 595 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="character.sets" href="#character.sets">Character Sets</a></h2> 596 <p id="rfc.section.3.1.p.1">HTTP uses the same definition of the term "character set" as that described for MIME:</p> 597 <p id="rfc.section.3.1.p.2">The term "character set" is used in this document to refer to a method used with one or more tables to convert a sequence 588 598 of octets into a sequence of characters. Note that unconditional conversion in the other direction is not required, in that 589 599 not all characters may be available in a given character set and a character set may provide more than one sequence of octets … … 598 608 </dd> 599 609 </dl> 600 <p id="rfc.section. 2.1.p.4">HTTP character sets are identified by case-insensitive tokens. The complete set of tokens is defined by the IANA Character610 <p id="rfc.section.3.1.p.4">HTTP character sets are identified by case-insensitive tokens. The complete set of tokens is defined by the IANA Character 601 611 Set registry (<<a href="http://www.iana.org/assignments/character-sets">http://www.iana.org/assignments/character-sets</a>>). 602 612 </p> 603 <div id="rfc.figure.u. 1"></div><pre class="inline"><span id="rfc.iref.g.1"></span> charset = token604 </pre><p id="rfc.section. 2.1.p.6">Although HTTP allows an arbitrary token to be used as a charset value, any token that has a predefined value within the IANA613 <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.1"></span> charset = token 614 </pre><p id="rfc.section.3.1.p.6">Although HTTP allows an arbitrary token to be used as a charset value, any token that has a predefined value within the IANA 605 615 Character Set registry <em class="bcp14">MUST</em> represent the character set defined by that registry. Applications <em class="bcp14">SHOULD</em> limit their use of character sets to those defined by the IANA registry. 606 616 </p> 607 <p id="rfc.section. 2.1.p.7">HTTP uses charset in two contexts: within an Accept-Charset request header (in which the charset value is an unquoted token)617 <p id="rfc.section.3.1.p.7">HTTP uses charset in two contexts: within an Accept-Charset request header (in which the charset value is an unquoted token) 608 618 and as the value of a parameter in a Content-Type header (within a request or response), in which case the parameter value 609 619 of the charset parameter may be quoted. 610 620 </p> 611 <p id="rfc.section. 2.1.p.8">Implementors should 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>.612 </p> 613 <h3 id="rfc.section. 2.1.1"><a href="#rfc.section.2.1.1">2.1.1</a> <a id="missing.charset" href="#missing.charset">Missing Charset</a></h3>614 <p id="rfc.section. 2.1.1.p.1">Some HTTP/1.0 software has interpreted a Content-Type header without charset parameter incorrectly to mean "recipient should621 <p id="rfc.section.3.1.p.8">Implementors should 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>. 622 </p> 623 <h3 id="rfc.section.3.1.1"><a href="#rfc.section.3.1.1">3.1.1</a> <a id="missing.charset" href="#missing.charset">Missing Charset</a></h3> 624 <p id="rfc.section.3.1.1.p.1">Some HTTP/1.0 software has interpreted a Content-Type header without charset parameter incorrectly to mean "recipient should 615 625 guess." Senders wishing to defeat this behavior <em class="bcp14">MAY</em> include a charset parameter even when the charset is ISO-8859-1 (<a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a>) and <em class="bcp14">SHOULD</em> do so when it is known that it will not confuse the recipient. 616 626 </p> 617 <p id="rfc.section. 2.1.1.p.2">Unfortunately, some older HTTP/1.0 clients did not deal properly with an explicit charset parameter. HTTP/1.1 recipients <em class="bcp14">MUST</em> respect the charset label provided by the sender; and those user agents that have a provision to "guess" a charset <em class="bcp14">MUST</em> use the charset from the content-type field if they support that charset, rather than the recipient's preference, when initially618 displaying a document. See <a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section 2.3.1</a>.619 </p> 620 <h2 id="rfc.section. 2.2"><a href="#rfc.section.2.2">2.2</a> <a id="content.codings" href="#content.codings">Content Codings</a></h2>621 <p id="rfc.section. 2.2.p.1">Content coding values indicate an encoding transformation that has been or can be applied to an entity. Content codings are627 <p id="rfc.section.3.1.1.p.2">Unfortunately, some older HTTP/1.0 clients did not deal properly with an explicit charset parameter. HTTP/1.1 recipients <em class="bcp14">MUST</em> respect the charset label provided by the sender; and those user agents that have a provision to "guess" a charset <em class="bcp14">MUST</em> use the charset from the content-type field if they support that charset, rather than the recipient's preference, when initially 628 displaying a document. See <a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section 3.3.1</a>. 629 </p> 630 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="content.codings" href="#content.codings">Content Codings</a></h2> 631 <p id="rfc.section.3.2.p.1">Content coding values indicate an encoding transformation that has been or can be applied to an entity. Content codings are 622 632 primarily used to allow a document to be compressed or otherwise usefully transformed without losing the identity of its underlying 623 633 media type and without loss of information. Frequently, the entity is stored in coded form, transmitted directly, and only 624 634 decoded by the recipient. 625 635 </p> 626 <div id="rfc.figure.u. 2"></div><pre class="inline"><span id="rfc.iref.g.2"></span> content-coding = token627 </pre><p id="rfc.section. 2.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.1" title="Accept-Encoding">Section 5.3</a>) and Content-Encoding (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.1" title="Content-Encoding">Section 5.5</a>) header fields. Although the value describes the content-coding, what is more important is that it indicates what decoding636 <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.2"></span> content-coding = token 637 </pre><p id="rfc.section.3.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.1" title="Accept-Encoding">Section 6.3</a>) and Content-Encoding (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.1" title="Content-Encoding">Section 6.5</a>) header fields. Although the value describes the content-coding, what is more important is that it indicates what decoding 628 638 mechanism will be required to remove the encoding. 629 639 </p> 630 <p id="rfc.section. 2.2.p.4">The Internet Assigned Numbers Authority (IANA) acts as a registry for content-coding value tokens. Initially, the registry640 <p id="rfc.section.3.2.p.4">The Internet Assigned Numbers Authority (IANA) acts as a registry for content-coding value tokens. Initially, the registry 631 641 contains the following tokens: 632 642 </p> 633 <p id="rfc.section. 2.2.p.5">gzip<span id="rfc.iref.g.3"></span>643 <p id="rfc.section.3.2.p.5">gzip<span id="rfc.iref.g.3"></span> 634 644 </p> 635 645 <dl class="empty"> … … 637 647 </dd> 638 648 </dl> 639 <p id="rfc.section. 2.2.p.6">compress<span id="rfc.iref.c.1"></span>649 <p id="rfc.section.3.2.p.6">compress<span id="rfc.iref.c.1"></span> 640 650 </p> 641 651 <dl class="empty"> … … 648 658 </dd> 649 659 </dl> 650 <p id="rfc.section. 2.2.p.7">deflate<span id="rfc.iref.d.1"></span>660 <p id="rfc.section.3.2.p.7">deflate<span id="rfc.iref.d.1"></span> 651 661 </p> 652 662 <dl class="empty"> … … 654 664 </dd> 655 665 </dl> 656 <p id="rfc.section. 2.2.p.8">identity<span id="rfc.iref.i.1"></span>666 <p id="rfc.section.3.2.p.8">identity<span id="rfc.iref.i.1"></span> 657 667 </p> 658 668 <dl class="empty"> … … 661 671 </dd> 662 672 </dl> 663 <p id="rfc.section. 2.2.p.9">New content-coding value tokens <em class="bcp14">SHOULD</em> be registered; to allow interoperability between clients and servers, specifications of the content coding algorithms needed673 <p id="rfc.section.3.2.p.9">New content-coding value tokens <em class="bcp14">SHOULD</em> be registered; to allow interoperability between clients and servers, specifications of the content coding algorithms needed 664 674 to implement a new value <em class="bcp14">SHOULD</em> be publicly available and adequate for independent implementation, and conform to the purpose of content coding defined in 665 675 this section. 666 676 </p> 667 <h2 id="rfc.section. 2.3"><a href="#rfc.section.2.3">2.3</a> <a id="media.types" href="#media.types">Media Types</a></h2>668 <p id="rfc.section. 2.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.1" title="Content-Type">Section 5.9</a>) and Accept (<a href="#header.accept" id="rfc.xref.header.accept.1" title="Accept">Section 5.1</a>) header fields in order to provide open and extensible data typing and type negotiation.669 </p> 670 <div id="rfc.figure.u. 3"></div><pre class="inline"><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span> media-type = type "/" subtype *( ";" parameter )677 <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> <a id="media.types" href="#media.types">Media Types</a></h2> 678 <p id="rfc.section.3.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.1" title="Content-Type">Section 6.9</a>) and Accept (<a href="#header.accept" id="rfc.xref.header.accept.1" title="Accept">Section 6.1</a>) header fields in order to provide open and extensible data typing and type negotiation. 679 </p> 680 <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span> media-type = type "/" subtype *( ";" parameter ) 671 681 type = token 672 682 subtype = token 673 </pre><p id="rfc.section. 2.3.p.3">Parameters <em class="bcp14">MAY</em> follow the type/subtype in the form of attribute/value pairs.674 </p> 675 <div id="rfc.figure.u. 4"></div><pre class="inline"><span id="rfc.iref.g.7"></span><span id="rfc.iref.g.8"></span><span id="rfc.iref.g.9"></span> parameter = attribute "=" value683 </pre><p id="rfc.section.3.3.p.3">Parameters <em class="bcp14">MAY</em> follow the type/subtype in the form of attribute/value pairs. 684 </p> 685 <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.7"></span><span id="rfc.iref.g.8"></span><span id="rfc.iref.g.9"></span> parameter = attribute "=" value 676 686 attribute = token 677 687 value = token | quoted-string 678 </pre><p id="rfc.section. 2.3.p.5">The type, subtype, and parameter attribute names are case-insensitive. Parameter values might or might not be case-sensitive,688 </pre><p id="rfc.section.3.3.p.5">The type, subtype, and parameter attribute names are case-insensitive. Parameter values might or might not be case-sensitive, 679 689 depending on the semantics of the parameter name. Linear white space (LWS) <em class="bcp14">MUST NOT</em> be used between the type and subtype, nor between an attribute and its value. The presence or absence of a parameter might 680 690 be significant to the processing of a media-type, depending on its definition within the media type registry. 681 691 </p> 682 <p id="rfc.section. 2.3.p.6">Note that some older HTTP applications do not recognize media type parameters. When sending data to older HTTP applications,692 <p id="rfc.section.3.3.p.6">Note that some older HTTP applications do not recognize media type parameters. When sending data to older HTTP applications, 683 693 implementations <em class="bcp14">SHOULD</em> only use media type parameters when they are required by that type/subtype definition. 684 694 </p> 685 <p id="rfc.section. 2.3.p.7">Media-type values are registered with the Internet Assigned Number Authority (IANA). The media type registration process is695 <p id="rfc.section.3.3.p.7">Media-type values are registered with the Internet Assigned Number Authority (IANA). The media type registration process is 686 696 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. 687 697 </p> 688 <h3 id="rfc.section. 2.3.1"><a href="#rfc.section.2.3.1">2.3.1</a> <a id="canonicalization.and.text.defaults" href="#canonicalization.and.text.defaults">Canonicalization and Text Defaults</a></h3>689 <p id="rfc.section. 2.3.1.p.1">Internet media types are registered with a canonical form. An entity-body transferred via HTTP messages <em class="bcp14">MUST</em> be represented in the appropriate canonical form prior to its transmission except for "text" types, as defined in the next698 <h3 id="rfc.section.3.3.1"><a href="#rfc.section.3.3.1">3.3.1</a> <a id="canonicalization.and.text.defaults" href="#canonicalization.and.text.defaults">Canonicalization and Text Defaults</a></h3> 699 <p id="rfc.section.3.3.1.p.1">Internet media types are registered with a canonical form. An entity-body transferred via HTTP messages <em class="bcp14">MUST</em> be represented in the appropriate canonical form prior to its transmission except for "text" types, as defined in the next 690 700 paragraph. 691 701 </p> 692 <p id="rfc.section. 2.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 and702 <p id="rfc.section.3.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 693 703 allows the transport of text media with plain CR or LF alone representing a line break when it is done consistently for an 694 704 entire entity-body. HTTP applications <em class="bcp14">MUST</em> accept CRLF, bare CR, and bare LF as being representative of a line break in text media received via HTTP. In addition, if … … 698 708 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). 699 709 </p> 700 <p id="rfc.section. 2.3.1.p.3">If an entity-body is encoded with a content-coding, the underlying data <em class="bcp14">MUST</em> be in a form defined above prior to being encoded.701 </p> 702 <p id="rfc.section. 2.3.1.p.4">The "charset" parameter is used with some media types to define the character set (<a href="#character.sets" title="Character Sets">Section 2.1</a>) of the data. When no explicit charset parameter is provided by the sender, media subtypes of the "text" type are defined710 <p id="rfc.section.3.3.1.p.3">If an entity-body is encoded with a content-coding, the underlying data <em class="bcp14">MUST</em> be in a form defined above prior to being encoded. 711 </p> 712 <p id="rfc.section.3.3.1.p.4">The "charset" parameter is used with some media types to define the character set (<a href="#character.sets" title="Character Sets">Section 3.1</a>) of the data. When no explicit charset parameter is provided by the sender, media subtypes of the "text" type are defined 703 713 to have a default charset value of "ISO-8859-1" when received via HTTP. Data in character sets other than "ISO-8859-1" or 704 its subsets <em class="bcp14">MUST</em> be labeled with an appropriate charset value. See <a href="#missing.charset" title="Missing Charset">Section 2.1.1</a> for compatibility problems.705 </p> 706 <h3 id="rfc.section. 2.3.2"><a href="#rfc.section.2.3.2">2.3.2</a> <a id="multipart.types" href="#multipart.types">Multipart Types</a></h3>707 <p id="rfc.section. 2.3.2.p.1">MIME provides for a number of "multipart" types -- encapsulations of one or more entities within a single message-body. All714 its subsets <em class="bcp14">MUST</em> be labeled with an appropriate charset value. See <a href="#missing.charset" title="Missing Charset">Section 3.1.1</a> for compatibility problems. 715 </p> 716 <h3 id="rfc.section.3.3.2"><a href="#rfc.section.3.3.2">3.3.2</a> <a id="multipart.types" href="#multipart.types">Multipart Types</a></h3> 717 <p id="rfc.section.3.3.2.p.1">MIME provides for a number of "multipart" types -- encapsulations of one or more entities within a single message-body. All 708 718 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. Unlike in RFC 2046, the epilogue of any multipart message <em class="bcp14">MUST</em> be empty; HTTP applications <em class="bcp14">MUST NOT</em> transmit the epilogue (even if the original multipart contains an epilogue). These restrictions exist in order to preserve 709 719 the self-delimiting nature of a multipart message-body, wherein the "end" of the message-body is indicated by the ending multipart 710 720 boundary. 711 721 </p> 712 <p id="rfc.section. 2.3.2.p.2">In general, HTTP treats a multipart message-body no differently than any other media type: strictly as payload. The one exception722 <p id="rfc.section.3.3.2.p.2">In general, HTTP treats a multipart message-body no differently than any other media type: strictly as payload. The one exception 713 723 is the "multipart/byteranges" type (<a href="p5-range.html#internet.media.type.multipart.byteranges" title="Internet Media Type multipart/byteranges">Appendix A</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) when it appears in a 206 (Partial Content) response. 714 724 </p> 715 <p id="rfc.section. 2.3.2.p.3">In general, an HTTP user agent <em class="bcp14">SHOULD</em> follow the same or similar behavior as a MIME user agent would upon receipt of a multipart type. If an application receives725 <p id="rfc.section.3.3.2.p.3">In general, an HTTP user agent <em class="bcp14">SHOULD</em> follow the same or similar behavior as a MIME user agent would upon receipt of a multipart type. If an application receives 716 726 an unrecognized multipart subtype, the application <em class="bcp14">MUST</em> treat it as being equivalent to "multipart/mixed". 717 727 </p> … … 721 731 </dd> 722 732 </dl> 723 <h2 id="rfc.section. 2.4"><a href="#rfc.section.2.4">2.4</a> <a id="quality.values" href="#quality.values">Quality Values</a></h2>724 <p id="rfc.section. 2.4.p.1">HTTP content negotiation (<a href="#content.negotiation" title="Content Negotiation">Section 4</a>) uses short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight733 <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a> <a id="quality.values" href="#quality.values">Quality Values</a></h2> 734 <p id="rfc.section.3.4.p.1">HTTP content negotiation (<a href="#content.negotiation" title="Content Negotiation">Section 5</a>) uses short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight 725 735 is normalized to a real number in the range 0 through 1, where 0 is the minimum and 1 the maximum value. If a parameter has 726 736 a quality value of 0, then content with this parameter is `not acceptable' for the client. HTTP/1.1 applications <em class="bcp14">MUST NOT</em> generate more than three digits after the decimal point. User configuration of these values <em class="bcp14">SHOULD</em> also be limited in this fashion. 727 737 </p> 728 <div id="rfc.figure.u. 5"></div><pre class="inline"><span id="rfc.iref.g.10"></span> qvalue = ( "0" [ "." 0*3DIGIT ] )738 <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.10"></span> qvalue = ( "0" [ "." 0*3DIGIT ] ) 729 739 | ( "1" [ "." 0*3("0") ] ) 730 </pre><p id="rfc.section. 2.4.p.3">"Quality values" is a misnomer, since these values merely represent relative degradation in desired quality.</p>731 <h2 id="rfc.section. 2.5"><a href="#rfc.section.2.5">2.5</a> <a id="language.tags" href="#language.tags">Language Tags</a></h2>732 <p id="rfc.section. 2.5.p.1">A language tag identifies a natural language spoken, written, or otherwise conveyed by human beings for communication of information740 </pre><p id="rfc.section.3.4.p.3">"Quality values" is a misnomer, since these values merely represent relative degradation in desired quality.</p> 741 <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a> <a id="language.tags" href="#language.tags">Language Tags</a></h2> 742 <p id="rfc.section.3.5.p.1">A language tag identifies a natural language spoken, written, or otherwise conveyed by human beings for communication of information 733 743 to other human beings. Computer languages are explicitly excluded. HTTP uses language tags within the Accept-Language and 734 744 Content-Language fields. 735 745 </p> 736 <p id="rfc.section. 2.5.p.2">The syntax and registry of HTTP language tags is the same as that defined by <a href="#RFC1766" id="rfc.xref.RFC1766.1"><cite title="Tags for the Identification of Languages">[RFC1766]</cite></a>. In summary, a language tag is composed of 1 or more parts: A primary language tag and a possibly empty series of subtags:737 </p> 738 <div id="rfc.figure.u. 6"></div><pre class="inline"><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span><span id="rfc.iref.g.13"></span> language-tag = primary-tag *( "-" subtag )746 <p id="rfc.section.3.5.p.2">The syntax and registry of HTTP language tags is the same as that defined by <a href="#RFC1766" id="rfc.xref.RFC1766.1"><cite title="Tags for the Identification of Languages">[RFC1766]</cite></a>. In summary, a language tag is composed of 1 or more parts: A primary language tag and a possibly empty series of subtags: 747 </p> 748 <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span><span id="rfc.iref.g.13"></span> language-tag = primary-tag *( "-" subtag ) 739 749 primary-tag = 1*8ALPHA 740 750 subtag = 1*8ALPHA 741 </pre><p id="rfc.section. 2.5.p.4">White space is not allowed within the tag and all tags are case-insensitive. The name space of language tags is administered751 </pre><p id="rfc.section.3.5.p.4">White space is not allowed within the tag and all tags are case-insensitive. The name space of language tags is administered 742 752 by the IANA. Example tags include: 743 753 </p> 744 <div id="rfc.figure.u. 7"></div><pre class="text"> en, en-US, en-cockney, i-cherokee, x-pig-latin745 </pre><p id="rfc.section. 2.5.p.6">where any two-letter primary-tag is an ISO-639 language abbreviation and any two-letter initial subtag is an ISO-3166 country754 <div id="rfc.figure.u.9"></div><pre class="text"> en, en-US, en-cockney, i-cherokee, x-pig-latin 755 </pre><p id="rfc.section.3.5.p.6">where any two-letter primary-tag is an ISO-639 language abbreviation and any two-letter initial subtag is an ISO-3166 country 746 756 code. (The last three tags above are not registered tags; all but the last are examples of tags which could be registered 747 757 in future.) 748 758 </p> 749 <h1 id="rfc.section. 3"><a href="#rfc.section.3">3.</a> <a id="entity" href="#entity">Entity</a></h1>750 <p id="rfc.section. 3.p.1">Request and Response messages <em class="bcp14">MAY</em> transfer an entity if not otherwise restricted by the request method or response status code. An entity consists of entity-header759 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="entity" href="#entity">Entity</a></h1> 760 <p id="rfc.section.4.p.1">Request and Response messages <em class="bcp14">MAY</em> transfer an entity if not otherwise restricted by the request method or response status code. An entity consists of entity-header 751 761 fields and an entity-body, although some responses will only include the entity-headers. 752 762 </p> 753 <p id="rfc.section. 3.p.2">In this section, both sender and recipient refer to either the client or the server, depending on who sends and who receives763 <p id="rfc.section.4.p.2">In this section, both sender and recipient refer to either the client or the server, depending on who sends and who receives 754 764 the entity. 755 765 </p> 756 <h2 id="rfc.section. 3.1"><a href="#rfc.section.3.1">3.1</a> <a id="entity.header.fields" href="#entity.header.fields">Entity Header Fields</a></h2>757 <p id="rfc.section. 3.1.p.1">Entity-header fields define metainformation about the entity-body or, if no body is present, about the resource identified766 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="entity.header.fields" href="#entity.header.fields">Entity Header Fields</a></h2> 767 <p id="rfc.section.4.1.p.1">Entity-header fields define metainformation about the entity-body or, if no body is present, about the resource identified 758 768 by the request. 759 769 </p> 760 <div id="rfc.figure.u. 8"></div><pre class="inline"><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span> entity-header = Allow ; <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#header.allow" title="Allow">Section 9.1</a>761 | Content-Encoding ; <a href="#header.content-encoding" id="rfc.xref.header.content-encoding.2" title="Content-Encoding">Section 5.5</a>762 | Content-Language ; <a href="#header.content-language" id="rfc.xref.header.content-language.1" title="Content-Language">Section 5.6</a>763 | Content-Length ; <a href="#Part1" id="rfc.xref.Part1. 1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.content-length" title="Content-Length">Section 8.2</a>764 | Content-Location ; <a href="#header.content-location" id="rfc.xref.header.content-location.1" title="Content-Location">Section 5.7</a>765 | Content-MD5 ; <a href="#header.content-md5" id="rfc.xref.header.content-md5.1" title="Content-MD5">Section 5.8</a>766 | Content-Range ; <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a>767 | Content-Type ; <a href="#header.content-type" id="rfc.xref.header.content-type.2" title="Content-Type">Section 5.9</a>768 | Expires ; <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.expires" title="Expires">Section 1 5.3</a>769 | Last-Modified ; <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 6.6</a>770 <div id="rfc.figure.u.10"></div><pre class="inline"><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span> entity-header = Allow ; <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#header.allow" title="Allow">Section 10.1</a> 771 | Content-Encoding ; <a href="#header.content-encoding" id="rfc.xref.header.content-encoding.2" title="Content-Encoding">Section 6.5</a> 772 | Content-Language ; <a href="#header.content-language" id="rfc.xref.header.content-language.1" title="Content-Language">Section 6.6</a> 773 | Content-Length ; <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.content-length" title="Content-Length">Section 8.2</a> 774 | Content-Location ; <a href="#header.content-location" id="rfc.xref.header.content-location.1" title="Content-Location">Section 6.7</a> 775 | Content-MD5 ; <a href="#header.content-md5" id="rfc.xref.header.content-md5.1" title="Content-MD5">Section 6.8</a> 776 | Content-Range ; <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.content-range" title="Content-Range">Section 6.2</a> 777 | Content-Type ; <a href="#header.content-type" id="rfc.xref.header.content-type.2" title="Content-Type">Section 6.9</a> 778 | Expires ; <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.expires" title="Expires">Section 16.3</a> 779 | Last-Modified ; <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 7.6</a> 770 780 | extension-header 771 781 772 782 extension-header = message-header 773 </pre><p id="rfc.section. 3.1.p.3">The extension-header mechanism allows additional entity-header fields to be defined without changing the protocol, but these783 </pre><p id="rfc.section.4.1.p.3">The extension-header mechanism allows additional entity-header fields to be defined without changing the protocol, but these 774 784 fields cannot be assumed to be recognizable by the recipient. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by the recipient and <em class="bcp14">MUST</em> be forwarded by transparent proxies. 775 785 </p> 776 <h2 id="rfc.section. 3.2"><a href="#rfc.section.3.2">3.2</a> <a id="entity.body" href="#entity.body">Entity Body</a></h2>777 <p id="rfc.section. 3.2.p.1">The entity-body (if any) sent with an HTTP request or response is in a format and encoding defined by the entity-header fields.</p>778 <div id="rfc.figure.u. 9"></div><pre class="inline"><span id="rfc.iref.g.16"></span> entity-body = *OCTET779 </pre><p id="rfc.section. 3.2.p.3">An entity-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 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The entity-body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied to ensure786 <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="entity.body" href="#entity.body">Entity Body</a></h2> 787 <p id="rfc.section.4.2.p.1">The entity-body (if any) sent with an HTTP request or response is in a format and encoding defined by the entity-header fields.</p> 788 <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.16"></span> entity-body = *OCTET 789 </pre><p id="rfc.section.4.2.p.3">An entity-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 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The entity-body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied to ensure 780 790 safe and proper transfer of the message. 781 791 </p> 782 <h3 id="rfc.section. 3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a> <a id="type" href="#type">Type</a></h3>783 <p id="rfc.section. 3.2.1.p.1">When an entity-body is included with a message, the data type of that body is determined via the header fields Content-Type792 <h3 id="rfc.section.4.2.1"><a href="#rfc.section.4.2.1">4.2.1</a> <a id="type" href="#type">Type</a></h3> 793 <p id="rfc.section.4.2.1.p.1">When an entity-body is included with a message, the data type of that body is determined via the header fields Content-Type 784 794 and Content-Encoding. These define a two-layer, ordered encoding model: 785 795 </p> 786 <div id="rfc.figure.u.1 0"></div><pre class="text"> entity-body := Content-Encoding( Content-Type( data ) )787 </pre><p id="rfc.section. 3.2.1.p.3">Content-Type specifies the media type of the underlying data. Content-Encoding may be used to indicate any additional content796 <div id="rfc.figure.u.12"></div><pre class="text"> entity-body := Content-Encoding( Content-Type( data ) ) 797 </pre><p id="rfc.section.4.2.1.p.3">Content-Type specifies the media type of the underlying data. Content-Encoding may be used to indicate any additional content 788 798 codings applied to the data, usually for the purpose of data compression, that are a property of the requested resource. There 789 799 is no default encoding. 790 800 </p> 791 <p id="rfc.section. 3.2.1.p.4">Any HTTP/1.1 message containing an entity-body <em class="bcp14">SHOULD</em> include a Content-Type header field defining the media type of that body. If and only if the media type is not given by a801 <p id="rfc.section.4.2.1.p.4">Any HTTP/1.1 message containing an entity-body <em class="bcp14">SHOULD</em> include a Content-Type header field defining the media type of that body. If and only if the media type is not given by a 792 802 Content-Type field, the recipient <em class="bcp14">MAY</em> attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the 793 803 resource. If the media type remains unknown, the recipient <em class="bcp14">SHOULD</em> treat it as type "application/octet-stream". 794 804 </p> 795 <h3 id="rfc.section. 3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a> <a id="entity.length" href="#entity.length">Entity Length</a></h3>796 <p id="rfc.section. 3.2.2.p.1">The entity-length of a message is the length of the message-body before any transfer-codings have been applied. <a href="p1-messaging.html#message.length" title="Message Length">Section 4.4</a> of <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> defines how the transfer-length of a message-body is determined.797 </p> 798 <h1 id="rfc.section. 4"><a href="#rfc.section.4">4.</a> <a id="content.negotiation" href="#content.negotiation">Content Negotiation</a></h1>799 <p id="rfc.section. 4.p.1">Most HTTP responses include an entity which contains information for interpretation by a human user. Naturally, it is desirable805 <h3 id="rfc.section.4.2.2"><a href="#rfc.section.4.2.2">4.2.2</a> <a id="entity.length" href="#entity.length">Entity Length</a></h3> 806 <p id="rfc.section.4.2.2.p.1">The entity-length of a message is the length of the message-body before any transfer-codings have been applied. <a href="p1-messaging.html#message.length" title="Message Length">Section 4.4</a> of <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> defines how the transfer-length of a message-body is determined. 807 </p> 808 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="content.negotiation" href="#content.negotiation">Content Negotiation</a></h1> 809 <p id="rfc.section.5.p.1">Most HTTP responses include an entity which contains information for interpretation by a human user. Naturally, it is desirable 800 810 to supply the user with the "best available" entity corresponding to the request. Unfortunately for servers and caches, not 801 811 all users have the same preferences for what is "best," and not all user agents are equally capable of rendering all entity … … 808 818 </dd> 809 819 </dl> 810 <p id="rfc.section. 4.p.2">Any response containing an entity-body <em class="bcp14">MAY</em> be subject to negotiation, including error responses.811 </p> 812 <p id="rfc.section. 4.p.3">There are two kinds of content negotiation which are possible in HTTP: server-driven and agent-driven negotiation. These two820 <p id="rfc.section.5.p.2">Any response containing an entity-body <em class="bcp14">MAY</em> be subject to negotiation, including error responses. 821 </p> 822 <p id="rfc.section.5.p.3">There are two kinds of content negotiation which are possible in HTTP: server-driven and agent-driven negotiation. These two 813 823 kinds of negotiation are orthogonal and thus may be used separately or in combination. One method of combination, referred 814 824 to as transparent negotiation, occurs when a cache uses the agent-driven negotiation information provided by the origin server 815 825 in order to provide server-driven negotiation for subsequent requests. 816 826 </p> 817 <h2 id="rfc.section. 4.1"><a href="#rfc.section.4.1">4.1</a> <a id="server-driven.negotiation" href="#server-driven.negotiation">Server-driven Negotiation</a></h2>818 <p id="rfc.section. 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-driven827 <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a> <a id="server-driven.negotiation" href="#server-driven.negotiation">Server-driven Negotiation</a></h2> 828 <p id="rfc.section.5.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 819 829 negotiation. Selection is based on the available representations of the response (the dimensions over which it can vary; e.g. 820 830 language, content-coding, etc.) and the contents of particular header fields in the request message or on other information 821 831 pertaining to the request (such as the network address of the client). 822 832 </p> 823 <p id="rfc.section. 4.1.p.2">Server-driven negotiation is advantageous when the algorithm for selecting from among the available representations is difficult833 <p id="rfc.section.5.1.p.2">Server-driven negotiation is advantageous when the algorithm for selecting from among the available representations is difficult 824 834 to describe to the user agent, or when the server desires to send its "best guess" to the client along with the first response 825 835 (hoping to avoid the round-trip delay of a subsequent request if the "best guess" is good enough for the user). In order to 826 836 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. 827 837 </p> 828 <p id="rfc.section. 4.1.p.3">Server-driven negotiation has disadvantages: </p>838 <p id="rfc.section.5.1.p.3">Server-driven negotiation has disadvantages: </p> 829 839 <ol> 830 840 <li>It is impossible for the server to accurately determine what might be "best" for any given user, since that would require … … 838 848 <li>It may limit a public cache's ability to use the same response for multiple user's requests.</li> 839 849 </ol> 840 <p id="rfc.section. 4.1.p.4">HTTP/1.1 includes the following request-header fields for enabling server-driven negotiation through description of user agent841 capabilities and user preferences: Accept (<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section 5.1</a>), Accept-Charset (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section 5.2</a>), Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section 5.3</a>), Accept-Language (<a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section 5.4</a>), and User-Agent (<a href="p2-semantics.html#header.user-agent" title="User-Agent">Section 9.9</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></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 information outside the request-header fields or within extension850 <p id="rfc.section.5.1.p.4">HTTP/1.1 includes the following request-header fields for enabling server-driven negotiation through description of user agent 851 capabilities and user preferences: Accept (<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section 6.1</a>), Accept-Charset (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section 6.2</a>), Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section 6.3</a>), Accept-Language (<a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section 6.4</a>), and User-Agent (<a href="p2-semantics.html#header.user-agent" title="User-Agent">Section 10.9</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></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 information outside the request-header fields or within extension 842 852 header fields not defined by this specification. 843 853 </p> 844 <p id="rfc.section. 4.1.p.5">The Vary header field (<a href="p6-cache.html#header.vary" title="Vary">Section 15.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><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.845 </p> 846 <h2 id="rfc.section. 4.2"><a href="#rfc.section.4.2">4.2</a> <a id="agent-driven.negotiation" href="#agent-driven.negotiation">Agent-driven Negotiation</a></h2>847 <p id="rfc.section. 4.2.p.1">With agent-driven negotiation, selection of the best representation for a response is performed by the user agent after receiving854 <p id="rfc.section.5.1.p.5">The Vary header field (<a href="p6-cache.html#header.vary" title="Vary">Section 16.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><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. 855 </p> 856 <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a> <a id="agent-driven.negotiation" href="#agent-driven.negotiation">Agent-driven Negotiation</a></h2> 857 <p id="rfc.section.5.2.p.1">With agent-driven negotiation, selection of the best representation for a response is performed by the user agent after receiving 848 858 an initial response from the origin server. Selection is based on a list of the available representations of the response 849 859 included within the header fields or entity-body of the initial response, with each representation identified by its own URI. … … 851 861 by the user selecting from a generated (possibly hypertext) menu. 852 862 </p> 853 <p id="rfc.section. 4.2.p.2">Agent-driven negotiation is advantageous when the response would vary over commonly-used dimensions (such as type, language,863 <p id="rfc.section.5.2.p.2">Agent-driven negotiation is advantageous when the response would vary over commonly-used dimensions (such as type, language, 854 864 or encoding), when the origin server is unable to determine a user agent's capabilities from examining the request, and generally 855 865 when public caches are used to distribute server load and reduce network usage. 856 866 </p> 857 <p id="rfc.section. 4.2.p.3">Agent-driven negotiation suffers from the disadvantage of needing a second request to obtain the best alternate representation.867 <p id="rfc.section.5.2.p.3">Agent-driven negotiation suffers from the disadvantage of needing a second request to obtain the best alternate representation. 858 868 This second request is only efficient when caching is used. In addition, this specification does not define any mechanism 859 869 for supporting automatic selection, though it also does not prevent any such mechanism from being developed as an extension 860 870 and used within HTTP/1.1. 861 871 </p> 862 <p id="rfc.section. 4.2.p.4">HTTP/1.1 defines the 300 (Multiple Choices) and 406 (Not Acceptable) status codes for enabling agent-driven negotiation when872 <p id="rfc.section.5.2.p.4">HTTP/1.1 defines the 300 (Multiple Choices) and 406 (Not Acceptable) status codes for enabling agent-driven negotiation when 863 873 the server is unwilling or unable to provide a varying response using server-driven negotiation. 864 874 </p> 865 <h2 id="rfc.section. 4.3"><a href="#rfc.section.4.3">4.3</a> <a id="transparent.negotiation" href="#transparent.negotiation">Transparent Negotiation</a></h2>866 <p id="rfc.section. 4.3.p.1">Transparent negotiation is a combination of both server-driven and agent-driven negotiation. When a cache is supplied with875 <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a> <a id="transparent.negotiation" href="#transparent.negotiation">Transparent Negotiation</a></h2> 876 <p id="rfc.section.5.3.p.1">Transparent negotiation is a combination of both server-driven and agent-driven negotiation. When a cache is supplied with 867 877 a form of the list of available representations of the response (as in agent-driven negotiation) and the dimensions of variance 868 878 are completely understood by the cache, then the cache becomes capable of performing server-driven negotiation on behalf of 869 879 the origin server for subsequent requests on that resource. 870 880 </p> 871 <p id="rfc.section. 4.3.p.2">Transparent negotiation has the advantage of distributing the negotiation work that would otherwise be required of the origin881 <p id="rfc.section.5.3.p.2">Transparent negotiation has the advantage of distributing the negotiation work that would otherwise be required of the origin 872 882 server and also removing the second request delay of agent-driven negotiation when the cache is able to correctly guess the 873 883 right response. 874 884 </p> 875 <p id="rfc.section. 4.3.p.3">This specification does not define any mechanism for transparent negotiation, though it also does not prevent any such mechanism885 <p id="rfc.section.5.3.p.3">This specification does not define any mechanism for transparent negotiation, though it also does not prevent any such mechanism 876 886 from being developed as an extension that could be used within HTTP/1.1. 877 887 </p> 878 <h1 id="rfc.section. 5"><a href="#rfc.section.5">5.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>879 <p id="rfc.section. 5.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to the payload of messages.</p>880 <p id="rfc.section. 5.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who888 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> 889 <p id="rfc.section.6.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to the payload of messages.</p> 890 <p id="rfc.section.6.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who 881 891 receives the entity. 882 892 </p> 883 893 <div id="rfc.iref.a.1"></div> 884 894 <div id="rfc.iref.h.1"></div> 885 <h2 id="rfc.section. 5.1"><a href="#rfc.section.5.1">5.1</a> <a id="header.accept" href="#header.accept">Accept</a></h2>886 <p id="rfc.section. 5.1.p.1">The Accept request-header field can be used to specify certain media types which are acceptable for the response. Accept headers895 <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a> <a id="header.accept" href="#header.accept">Accept</a></h2> 896 <p id="rfc.section.6.1.p.1">The Accept request-header field can be used to specify certain media types which are acceptable for the response. Accept headers 887 897 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 888 898 for an in-line image. 889 899 </p> 890 <div id="rfc.figure.u.1 1"></div><pre class="inline"><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span><span id="rfc.iref.g.20"></span> Accept = "Accept" ":"900 <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span><span id="rfc.iref.g.20"></span> Accept = "Accept" ":" 891 901 #( media-range [ accept-params ] ) 892 902 … … 897 907 accept-params = ";" "q" "=" qvalue *( accept-extension ) 898 908 accept-extension = ";" token [ "=" ( token | quoted-string ) ] 899 </pre><p id="rfc.section. 5.1.p.3">The asterisk "*" character is used to group media types into ranges, with "*/*" indicating all media types and "type/*" indicating909 </pre><p id="rfc.section.6.1.p.3">The asterisk "*" character is used to group media types into ranges, with "*/*" indicating all media types and "type/*" indicating 900 910 all subtypes of that type. The media-range <em class="bcp14">MAY</em> include media type parameters that are applicable to that range. 901 911 </p> 902 <p id="rfc.section. 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 first912 <p id="rfc.section.6.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 903 913 "q" parameter (if any) separates the media-range parameter(s) from the accept-params. Quality factors allow the user or user 904 agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (<a href="#quality.values" title="Quality Values">Section 2.4</a>). The default value is q=1.914 agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (<a href="#quality.values" title="Quality Values">Section 3.4</a>). The default value is q=1. 905 915 </p> 906 916 <dl class="empty"> … … 911 921 </dd> 912 922 </dl> 913 <p id="rfc.section. 5.1.p.5">The example</p>914 <div id="rfc.figure.u.1 2"></div><pre class="text"> Accept: audio/*; q=0.2, audio/basic915 </pre><p id="rfc.section. 5.1.p.7"> <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 in923 <p id="rfc.section.6.1.p.5">The example</p> 924 <div id="rfc.figure.u.14"></div><pre class="text"> Accept: audio/*; q=0.2, audio/basic 925 </pre><p id="rfc.section.6.1.p.7"> <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 916 926 quality." 917 927 </p> 918 <p id="rfc.section. 5.1.p.8">If no Accept header field is present, then it is assumed that the client accepts all media types. If an Accept header field928 <p id="rfc.section.6.1.p.8">If no Accept header field is present, then it is assumed that the client accepts all media types. If an Accept header field 919 929 is present, and if the server cannot send a response which is acceptable according to the combined Accept field value, then 920 930 the server <em class="bcp14">SHOULD</em> send a 406 (Not Acceptable) response. 921 931 </p> 922 <p id="rfc.section. 5.1.p.9">A more elaborate example is</p>923 <div id="rfc.figure.u.1 3"></div><pre class="text"> Accept: text/plain; q=0.5, text/html,932 <p id="rfc.section.6.1.p.9">A more elaborate example is</p> 933 <div id="rfc.figure.u.15"></div><pre class="text"> Accept: text/plain; q=0.5, text/html, 924 934 text/x-dvi; q=0.8, text/x-c 925 </pre><p id="rfc.section. 5.1.p.11">Verbally, this would be interpreted as "text/html and text/x-c are the preferred media types, but if they do not exist, then935 </pre><p id="rfc.section.6.1.p.11">Verbally, this would be interpreted as "text/html and text/x-c are the preferred media types, but if they do not exist, then 926 936 send the text/x-dvi entity, and if that does not exist, send the text/plain entity." 927 937 </p> 928 <p id="rfc.section. 5.1.p.12">Media ranges can be overridden by more specific media ranges or specific media types. If more than one media range applies938 <p id="rfc.section.6.1.p.12">Media ranges can be overridden by more specific media ranges or specific media types. If more than one media range applies 929 939 to a given type, the most specific reference has precedence. For example, 930 940 </p> 931 <div id="rfc.figure.u.1 4"></div><pre class="text"> Accept: text/*, text/html, text/html;level=1, */*932 </pre><p id="rfc.section. 5.1.p.14">have the following precedence:</p>933 <div id="rfc.figure.u.1 5"></div><pre class="text"> 1) text/html;level=1941 <div id="rfc.figure.u.16"></div><pre class="text"> Accept: text/*, text/html, text/html;level=1, */* 942 </pre><p id="rfc.section.6.1.p.14">have the following precedence:</p> 943 <div id="rfc.figure.u.17"></div><pre class="text"> 1) text/html;level=1 934 944 2) text/html 935 945 3) text/* 936 946 4) */* 937 </pre><p id="rfc.section. 5.1.p.16">The media type quality factor associated with a given type is determined by finding the media range with the highest precedence947 </pre><p id="rfc.section.6.1.p.16">The media type quality factor associated with a given type is determined by finding the media range with the highest precedence 938 948 which matches that type. For example, 939 949 </p> 940 <div id="rfc.figure.u.1 6"></div><pre class="text"> Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,950 <div id="rfc.figure.u.18"></div><pre class="text"> Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, 941 951 text/html;level=2;q=0.4, */*;q=0.5 942 </pre><p id="rfc.section. 5.1.p.18">would cause the following values to be associated:</p>943 <div id="rfc.figure.u.1 7"></div><pre class="text"> text/html;level=1 = 1952 </pre><p id="rfc.section.6.1.p.18">would cause the following values to be associated:</p> 953 <div id="rfc.figure.u.19"></div><pre class="text"> text/html;level=1 = 1 944 954 text/html = 0.7 945 955 text/plain = 0.3 … … 947 957 text/html;level=2 = 0.4 948 958 text/html;level=3 = 0.7 949 </pre><p id="rfc.section. 5.1.p.20"> <b>Note:</b> A user agent might be provided with a default set of quality values for certain media ranges. However, unless the user agent959 </pre><p id="rfc.section.6.1.p.20"> <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 950 960 is a closed system which cannot interact with other rendering agents, this default set ought to be configurable by the user. 951 961 </p> 952 962 <div id="rfc.iref.a.2"></div> 953 963 <div id="rfc.iref.h.2"></div> 954 <h2 id="rfc.section. 5.2"><a href="#rfc.section.5.2">5.2</a> <a id="header.accept-charset" href="#header.accept-charset">Accept-Charset</a></h2>955 <p id="rfc.section. 5.2.p.1">The Accept-Charset request-header field can be used to indicate what character sets are acceptable for the response. This964 <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a> <a id="header.accept-charset" href="#header.accept-charset">Accept-Charset</a></h2> 965 <p id="rfc.section.6.2.p.1">The Accept-Charset request-header field can be used to indicate what character sets are acceptable for the response. This 956 966 field allows clients capable of understanding more comprehensive or special-purpose character sets to signal that capability 957 967 to a server which is capable of representing documents in those character sets. 958 968 </p> 959 <div id="rfc.figure.u. 18"></div><pre class="inline"><span id="rfc.iref.g.21"></span> Accept-Charset = "Accept-Charset" ":"969 <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.21"></span> Accept-Charset = "Accept-Charset" ":" 960 970 1#( ( charset | "*" ) [ ";" "q" "=" qvalue ] ) 961 </pre><p id="rfc.section. 5.2.p.3">Character set values are described in <a href="#character.sets" title="Character Sets">Section 2.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. An971 </pre><p id="rfc.section.6.2.p.3">Character set values are described in <a href="#character.sets" title="Character Sets">Section 3.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. An 962 972 example is 963 973 </p> 964 <div id="rfc.figure.u. 19"></div><pre class="text"> Accept-Charset: iso-8859-5, unicode-1-1;q=0.8965 </pre><p id="rfc.section. 5.2.p.5">The special value "*", if present in the Accept-Charset field, matches every character set (including ISO-8859-1) which is974 <div id="rfc.figure.u.21"></div><pre class="text"> Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 975 </pre><p id="rfc.section.6.2.p.5">The special value "*", if present in the Accept-Charset field, matches every character set (including ISO-8859-1) which is 966 976 not mentioned elsewhere in the Accept-Charset field. If no "*" is present in an Accept-Charset field, then all character sets 967 977 not explicitly mentioned get a quality value of 0, except for ISO-8859-1, which gets a quality value of 1 if not explicitly 968 978 mentioned. 969 979 </p> 970 <p id="rfc.section. 5.2.p.6">If no Accept-Charset header is present, the default is that any character set is acceptable. If an Accept-Charset header is980 <p id="rfc.section.6.2.p.6">If no Accept-Charset header is present, the default is that any character set is acceptable. If an Accept-Charset header is 971 981 present, and if the server cannot send a response which is acceptable according to the Accept-Charset header, then the server <em class="bcp14">SHOULD</em> send an error response with the 406 (Not Acceptable) status code, though the sending of an unacceptable response is also allowed. 972 982 </p> 973 983 <div id="rfc.iref.a.3"></div> 974 984 <div id="rfc.iref.h.3"></div> 975 <h2 id="rfc.section. 5.3"><a href="#rfc.section.5.3">5.3</a> <a id="header.accept-encoding" href="#header.accept-encoding">Accept-Encoding</a></h2>976 <p id="rfc.section. 5.3.p.1">The Accept-Encoding request-header field is similar to Accept, but restricts the content-codings (<a href="#content.codings" title="Content Codings">Section 2.2</a>) that are acceptable in the response.977 </p> 978 <div id="rfc.figure.u.2 0"></div><pre class="inline"><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span> Accept-Encoding = "Accept-Encoding" ":"985 <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a> <a id="header.accept-encoding" href="#header.accept-encoding">Accept-Encoding</a></h2> 986 <p id="rfc.section.6.3.p.1">The Accept-Encoding request-header field is similar to Accept, but restricts the content-codings (<a href="#content.codings" title="Content Codings">Section 3.2</a>) that are acceptable in the response. 987 </p> 988 <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span> Accept-Encoding = "Accept-Encoding" ":" 979 989 #( codings [ ";" "q" "=" qvalue ] ) 980 990 codings = ( content-coding | "*" ) 981 </pre><p id="rfc.section. 5.3.p.3">Examples of its use are:</p>982 <div id="rfc.figure.u.2 1"></div><pre class="text"> Accept-Encoding: compress, gzip991 </pre><p id="rfc.section.6.3.p.3">Examples of its use are:</p> 992 <div id="rfc.figure.u.23"></div><pre class="text"> Accept-Encoding: compress, gzip 983 993 Accept-Encoding: 984 994 Accept-Encoding: * 985 995 Accept-Encoding: compress;q=0.5, gzip;q=1.0 986 996 Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 987 </pre><p id="rfc.section. 5.3.p.5">A server tests whether a content-coding is acceptable, according to an Accept-Encoding field, using these rules: </p>997 </pre><p id="rfc.section.6.3.p.5">A server tests whether a content-coding is acceptable, according to an Accept-Encoding field, using these rules: </p> 988 998 <ol> 989 999 <li>If the content-coding is one of the content-codings listed in the Accept-Encoding field, then it is acceptable, unless it 990 is accompanied by a qvalue of 0. (As defined in <a href="#quality.values" title="Quality Values">Section 2.4</a>, a qvalue of 0 means "not acceptable.")1000 is accompanied by a qvalue of 0. (As defined in <a href="#quality.values" title="Quality Values">Section 3.4</a>, a qvalue of 0 means "not acceptable.") 991 1001 </li> 992 1002 <li>The special "*" symbol in an Accept-Encoding field matches any available content-coding not explicitly listed in the header … … 999 1009 </li> 1000 1010 </ol> 1001 <p id="rfc.section. 5.3.p.6">If an Accept-Encoding field is present in a request, and if the server cannot send a response which is acceptable according1011 <p id="rfc.section.6.3.p.6">If an Accept-Encoding field is present in a request, and if the server cannot send a response which is acceptable according 1002 1012 to the Accept-Encoding header, then the server <em class="bcp14">SHOULD</em> send an error response with the 406 (Not Acceptable) status code. 1003 1013 </p> 1004 <p id="rfc.section. 5.3.p.7">If no Accept-Encoding field is present in a request, the server <em class="bcp14">MAY</em> assume that the client will accept any content coding. In this case, if "identity" is one of the available content-codings,1014 <p id="rfc.section.6.3.p.7">If no Accept-Encoding field is present in a request, the server <em class="bcp14">MAY</em> assume that the client will accept any content coding. In this case, if "identity" is one of the available content-codings, 1005 1015 then the server <em class="bcp14">SHOULD</em> use the "identity" content-coding, unless it has additional information that a different content-coding is meaningful to the 1006 1016 client. … … 1018 1028 <div id="rfc.iref.a.4"></div> 1019 1029 <div id="rfc.iref.h.4"></div> 1020 <h2 id="rfc.section. 5.4"><a href="#rfc.section.5.4">5.4</a> <a id="header.accept-language" href="#header.accept-language">Accept-Language</a></h2>1021 <p id="rfc.section. 5.4.p.1">The Accept-Language request-header field is similar to Accept, but restricts the set of natural languages that are preferred1022 as a response to the request. Language tags are defined in <a href="#language.tags" title="Language Tags">Section 2.5</a>.1023 </p> 1024 <div id="rfc.figure.u.2 2"></div><pre class="inline"><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span> Accept-Language = "Accept-Language" ":"1030 <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a> <a id="header.accept-language" href="#header.accept-language">Accept-Language</a></h2> 1031 <p id="rfc.section.6.4.p.1">The Accept-Language request-header field is similar to Accept, but restricts the set of natural languages that are preferred 1032 as a response to the request. Language tags are defined in <a href="#language.tags" title="Language Tags">Section 3.5</a>. 1033 </p> 1034 <div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span> Accept-Language = "Accept-Language" ":" 1025 1035 1#( language-range [ ";" "q" "=" qvalue ] ) 1026 1036 language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" ) 1027 </pre><p id="rfc.section. 5.4.p.3">Each language-range <em class="bcp14">MAY</em> be given an associated quality value which represents an estimate of the user's preference for the languages specified by1037 </pre><p id="rfc.section.6.4.p.3">Each language-range <em class="bcp14">MAY</em> be given an associated quality value which represents an estimate of the user's preference for the languages specified by 1028 1038 that range. The quality value defaults to "q=1". For example, 1029 1039 </p> 1030 <div id="rfc.figure.u.2 3"></div><pre class="text"> Accept-Language: da, en-gb;q=0.8, en;q=0.71031 </pre><p id="rfc.section. 5.4.p.5">would mean: "I prefer Danish, but will accept British English and other types of English." A language-range matches a language-tag1040 <div id="rfc.figure.u.25"></div><pre class="text"> Accept-Language: da, en-gb;q=0.8, en;q=0.7 1041 </pre><p id="rfc.section.6.4.p.5">would mean: "I prefer Danish, but will accept British English and other types of English." A language-range matches a language-tag 1032 1042 if it exactly equals the tag, or if it exactly equals a prefix of the tag such that the first tag character following the 1033 1043 prefix is "-". The special range "*", if present in the Accept-Language field, matches every tag not matched by any other … … 1040 1050 </dd> 1041 1051 </dl> 1042 <p id="rfc.section. 5.4.p.6">The language quality factor assigned to a language-tag by the Accept-Language field is the quality value of the longest language-range1052 <p id="rfc.section.6.4.p.6">The language quality factor assigned to a language-tag by the Accept-Language field is the quality value of the longest language-range 1043 1053 in the field that matches the language-tag. If no language-range in the field matches the tag, the language quality factor 1044 1054 assigned is 0. If no Accept-Language header is present in the request, the server <em class="bcp14">SHOULD</em> assume that all languages are equally acceptable. If an Accept-Language header is present, then all languages which are assigned 1045 1055 a quality factor greater than 0 are acceptable. 1046 1056 </p> 1047 <p id="rfc.section. 5.4.p.7">It might be contrary to the privacy expectations of the user to send an Accept-Language header with the complete linguistic1048 preferences of the user in every request. For a discussion of this issue, see <a href="#privacy.issues.connected.to.accept.headers" title="Privacy Issues Connected to Accept Headers">Section 7.1</a>.1049 </p> 1050 <p id="rfc.section. 5.4.p.8">As intelligibility is highly dependent on the individual user, it is recommended that client applications make the choice1057 <p id="rfc.section.6.4.p.7">It might be contrary to the privacy expectations of the user to send an Accept-Language header with the complete linguistic 1058 preferences of the user in every request. For a discussion of this issue, see <a href="#privacy.issues.connected.to.accept.headers" title="Privacy Issues Connected to Accept Headers">Section 8.1</a>. 1059 </p> 1060 <p id="rfc.section.6.4.p.8">As intelligibility is highly dependent on the individual user, it is recommended that client applications make the choice 1051 1061 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. 1052 1062 </p> … … 1060 1070 <div id="rfc.iref.c.2"></div> 1061 1071 <div id="rfc.iref.h.5"></div> 1062 <h2 id="rfc.section. 5.5"><a href="#rfc.section.5.5">5.5</a> <a id="header.content-encoding" href="#header.content-encoding">Content-Encoding</a></h2>1063 <p id="rfc.section. 5.5.p.1">The Content-Encoding entity-header field is used as a modifier to the media-type. When present, its value indicates what additional1072 <h2 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a> <a id="header.content-encoding" href="#header.content-encoding">Content-Encoding</a></h2> 1073 <p id="rfc.section.6.5.p.1">The Content-Encoding entity-header field is used as a modifier to the media-type. When present, its value indicates what additional 1064 1074 content codings have been applied to the entity-body, and thus what decoding mechanisms must be applied in order to obtain 1065 1075 the media-type referenced by the Content-Type header field. Content-Encoding is primarily used to allow a document to be compressed 1066 1076 without losing the identity of its underlying media type. 1067 1077 </p> 1068 <div id="rfc.figure.u.2 4"></div><pre class="inline"><span id="rfc.iref.g.26"></span> Content-Encoding = "Content-Encoding" ":" 1#content-coding1069 </pre><p id="rfc.section. 5.5.p.3">Content codings are defined in <a href="#content.codings" title="Content Codings">Section 2.2</a>. An example of its use is1070 </p> 1071 <div id="rfc.figure.u.2 5"></div><pre class="text"> Content-Encoding: gzip1072 </pre><p id="rfc.section. 5.5.p.5">The content-coding is a characteristic of the entity identified by the Request-URI. Typically, the entity-body is stored with1078 <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.26"></span> Content-Encoding = "Content-Encoding" ":" 1#content-coding 1079 </pre><p id="rfc.section.6.5.p.3">Content codings are defined in <a href="#content.codings" title="Content Codings">Section 3.2</a>. An example of its use is 1080 </p> 1081 <div id="rfc.figure.u.27"></div><pre class="text"> Content-Encoding: gzip 1082 </pre><p id="rfc.section.6.5.p.5">The content-coding is a characteristic of the entity identified by the Request-URI. Typically, the entity-body is stored with 1073 1083 this encoding and is only decoded before rendering or analogous usage. However, a non-transparent proxy <em class="bcp14">MAY</em> modify the content-coding if the new coding is known to be acceptable to the recipient, unless the "no-transform" cache-control 1074 1084 directive is present in the message. 1075 1085 </p> 1076 <p id="rfc.section. 5.5.p.6">If the content-coding of an entity is not "identity", then the response <em class="bcp14">MUST</em> include a Content-Encoding entity-header (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.3" title="Content-Encoding">Section 5.5</a>) that lists the non-identity content-coding(s) used.1077 </p> 1078 <p id="rfc.section. 5.5.p.7">If the content-coding of an entity in a request message is not acceptable to the origin server, the server <em class="bcp14">SHOULD</em> respond with a status code of 415 (Unsupported Media Type).1079 </p> 1080 <p id="rfc.section. 5.5.p.8">If multiple encodings have been applied to an entity, the content codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other entity-header fields not defined by this specification.1086 <p id="rfc.section.6.5.p.6">If the content-coding of an entity is not "identity", then the response <em class="bcp14">MUST</em> include a Content-Encoding entity-header (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.3" title="Content-Encoding">Section 6.5</a>) that lists the non-identity content-coding(s) used. 1087 </p> 1088 <p id="rfc.section.6.5.p.7">If the content-coding of an entity in a request message is not acceptable to the origin server, the server <em class="bcp14">SHOULD</em> respond with a status code of 415 (Unsupported Media Type). 1089 </p> 1090 <p id="rfc.section.6.5.p.8">If multiple encodings have been applied to an entity, the content codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other entity-header fields not defined by this specification. 1081 1091 </p> 1082 1092 <div id="rfc.iref.c.3"></div> 1083 1093 <div id="rfc.iref.h.6"></div> 1084 <h2 id="rfc.section. 5.6"><a href="#rfc.section.5.6">5.6</a> <a id="header.content-language" href="#header.content-language">Content-Language</a></h2>1085 <p id="rfc.section. 5.6.p.1">The Content-Language entity-header field describes the natural language(s) of the intended audience for the enclosed entity.1094 <h2 id="rfc.section.6.6"><a href="#rfc.section.6.6">6.6</a> <a id="header.content-language" href="#header.content-language">Content-Language</a></h2> 1095 <p id="rfc.section.6.6.p.1">The Content-Language entity-header field describes the natural language(s) of the intended audience for the enclosed entity. 1086 1096 Note that this might not be equivalent to all the languages used within the entity-body. 1087 1097 </p> 1088 <div id="rfc.figure.u.2 6"></div><pre class="inline"><span id="rfc.iref.g.27"></span> Content-Language = "Content-Language" ":" 1#language-tag1089 </pre><p id="rfc.section. 5.6.p.3">Language tags are defined in <a href="#language.tags" title="Language Tags">Section 2.5</a>. The primary purpose of Content-Language is to allow a user to identify and differentiate entities according to the user's1098 <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.27"></span> Content-Language = "Content-Language" ":" 1#language-tag 1099 </pre><p id="rfc.section.6.6.p.3">Language tags are defined in <a href="#language.tags" title="Language Tags">Section 3.5</a>. The primary purpose of Content-Language is to allow a user to identify and differentiate entities according to the user's 1090 1100 own preferred language. Thus, if the body content is intended only for a Danish-literate audience, the appropriate field is 1091 1101 </p> 1092 <div id="rfc.figure.u.2 7"></div><pre class="text"> Content-Language: da1093 </pre><p id="rfc.section. 5.6.p.5">If no Content-Language is specified, the default is that the content is intended for all language audiences. This might mean1102 <div id="rfc.figure.u.29"></div><pre class="text"> Content-Language: da 1103 </pre><p id="rfc.section.6.6.p.5">If no Content-Language is specified, the default is that the content is intended for all language audiences. This might mean 1094 1104 that the sender does not consider it to be specific to any natural language, or that the sender does not know for which language 1095 1105 it is intended. 1096 1106 </p> 1097 <p id="rfc.section. 5.6.p.6">Multiple languages <em class="bcp14">MAY</em> be listed for content that is intended for multiple audiences. For example, a rendition of the "Treaty of Waitangi," presented1107 <p id="rfc.section.6.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 1098 1108 simultaneously in the original Maori and English versions, would call for 1099 1109 </p> 1100 <div id="rfc.figure.u. 28"></div><pre class="text"> Content-Language: mi, en1101 </pre><p id="rfc.section. 5.6.p.8">However, just because multiple languages are present within an entity does not mean that it is intended for multiple linguistic1110 <div id="rfc.figure.u.30"></div><pre class="text"> Content-Language: mi, en 1111 </pre><p id="rfc.section.6.6.p.8">However, just because multiple languages are present within an entity does not mean that it is intended for multiple linguistic 1102 1112 audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin," which is clearly intended 1103 1113 to be used by an English-literate audience. In this case, the Content-Language would properly only include "en". 1104 1114 </p> 1105 <p id="rfc.section. 5.6.p.9">Content-Language <em class="bcp14">MAY</em> be applied to any media type -- it is not limited to textual documents.1115 <p id="rfc.section.6.6.p.9">Content-Language <em class="bcp14">MAY</em> be applied to any media type -- it is not limited to textual documents. 1106 1116 </p> 1107 1117 <div id="rfc.iref.c.4"></div> 1108 1118 <div id="rfc.iref.h.7"></div> 1109 <h2 id="rfc.section. 5.7"><a href="#rfc.section.5.7">5.7</a> <a id="header.content-location" href="#header.content-location">Content-Location</a></h2>1110 <p id="rfc.section. 5.7.p.1">The Content-Location entity-header field <em class="bcp14">MAY</em> be used to supply the resource location for the entity enclosed in the message when that entity is accessible from a location1119 <h2 id="rfc.section.6.7"><a href="#rfc.section.6.7">6.7</a> <a id="header.content-location" href="#header.content-location">Content-Location</a></h2> 1120 <p id="rfc.section.6.7.p.1">The Content-Location entity-header field <em class="bcp14">MAY</em> be used to supply the resource location for the entity enclosed in the message when that entity is accessible from a location 1111 1121 separate from the requested resource's URI. A server <em class="bcp14">SHOULD</em> provide a Content-Location for the variant corresponding to the response entity; especially in the case where a resource has 1112 1122 multiple entities associated with it, and those entities actually have separate locations by which they might be individually 1113 1123 accessed, the server <em class="bcp14">SHOULD</em> provide a Content-Location for the particular variant which is returned. 1114 1124 </p> 1115 <div id="rfc.figure.u. 29"></div><pre class="inline"><span id="rfc.iref.g.28"></span> Content-Location = "Content-Location" ":"1125 <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.28"></span> Content-Location = "Content-Location" ":" 1116 1126 ( absoluteURI | relativeURI ) 1117 </pre><p id="rfc.section. 5.7.p.3">The value of Content-Location also defines the base URI for the entity.</p>1118 <p id="rfc.section. 5.7.p.4">The Content-Location value is not a replacement for the original requested URI; it is only a statement of the location of1127 </pre><p id="rfc.section.6.7.p.3">The value of Content-Location also defines the base URI for the entity.</p> 1128 <p id="rfc.section.6.7.p.4">The Content-Location value is not a replacement for the original requested URI; it is only a statement of the location of 1119 1129 the resource corresponding to this particular entity at the time of the request. Future requests <em class="bcp14">MAY</em> specify the Content-Location URI as the request-URI if the desire is to identify the source of that particular entity. 1120 1130 </p> 1121 <p id="rfc.section. 5.7.p.5">A cache cannot assume that an entity with a Content-Location different from the URI used to retrieve it can be used to respond1131 <p id="rfc.section.6.7.p.5">A cache cannot assume that an entity with a Content-Location different from the URI used to retrieve it can be used to respond 1122 1132 to later requests on that Content-Location URI. However, the Content-Location can be used to differentiate between multiple 1123 entities retrieved from a single requested resource, as described in <a href="p6-cache.html#caching.negotiated.responses" title="Caching Negotiated Responses">Section 7</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.1124 </p> 1125 <p id="rfc.section. 5.7.p.6">If the Content-Location is a relative URI, the relative URI is interpreted relative to the Request-URI.</p>1126 <p id="rfc.section. 5.7.p.7">The meaning of the Content-Location header in PUT or POST requests is undefined; servers are free to ignore it in those cases.</p>1133 entities retrieved from a single requested resource, as described in <a href="p6-cache.html#caching.negotiated.responses" title="Caching Negotiated Responses">Section 8</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. 1134 </p> 1135 <p id="rfc.section.6.7.p.6">If the Content-Location is a relative URI, the relative URI is interpreted relative to the Request-URI.</p> 1136 <p id="rfc.section.6.7.p.7">The meaning of the Content-Location header in PUT or POST requests is undefined; servers are free to ignore it in those cases.</p> 1127 1137 <div id="rfc.iref.c.5"></div> 1128 1138 <div id="rfc.iref.h.8"></div> 1129 <h2 id="rfc.section. 5.8"><a href="#rfc.section.5.8">5.8</a> <a id="header.content-md5" href="#header.content-md5">Content-MD5</a></h2>1130 <p id="rfc.section. 5.8.p.1">The Content-MD5 entity-header field, as defined in <a href="#RFC1864" id="rfc.xref.RFC1864.1"><cite title="The Content-MD5 Header Field">[RFC1864]</cite></a>, is an MD5 digest of the entity-body for the purpose of providing an end-to-end message integrity check (MIC) of the entity-body.1139 <h2 id="rfc.section.6.8"><a href="#rfc.section.6.8">6.8</a> <a id="header.content-md5" href="#header.content-md5">Content-MD5</a></h2> 1140 <p id="rfc.section.6.8.p.1">The Content-MD5 entity-header field, as defined in <a href="#RFC1864" id="rfc.xref.RFC1864.1"><cite title="The Content-MD5 Header Field">[RFC1864]</cite></a>, is an MD5 digest of the entity-body for the purpose of providing an end-to-end message integrity check (MIC) of the entity-body. 1131 1141 (Note: a MIC is good for detecting accidental modification of the entity-body in transit, but is not proof against malicious 1132 1142 attacks.) 1133 1143 </p> 1134 <div id="rfc.figure.u.3 0"></div><pre class="inline"><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span> Content-MD5 = "Content-MD5" ":" md5-digest1144 <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span> Content-MD5 = "Content-MD5" ":" md5-digest 1135 1145 md5-digest = <base64 of 128 bit MD5 digest as per <a href="#RFC1864" id="rfc.xref.RFC1864.2"><cite title="The Content-MD5 Header Field">[RFC1864]</cite></a>> 1136 </pre><p id="rfc.section. 5.8.p.3">The Content-MD5 header field <em class="bcp14">MAY</em> be generated by an origin server or client to function as an integrity check of the entity-body. Only origin servers or clients <em class="bcp14">MAY</em> generate the Content-MD5 header field; proxies and gateways <em class="bcp14">MUST NOT</em> generate it, as this would defeat its value as an end-to-end integrity check. Any recipient of the entity-body, including1146 </pre><p id="rfc.section.6.8.p.3">The Content-MD5 header field <em class="bcp14">MAY</em> be generated by an origin server or client to function as an integrity check of the entity-body. Only origin servers or clients <em class="bcp14">MAY</em> generate the Content-MD5 header field; proxies and gateways <em class="bcp14">MUST NOT</em> generate it, as this would defeat its value as an end-to-end integrity check. Any recipient of the entity-body, including 1137 1147 gateways and proxies, <em class="bcp14">MAY</em> check that the digest value in this header field matches that of the entity-body as received. 1138 1148 </p> 1139 <p id="rfc.section. 5.8.p.4">The MD5 digest is computed based on the content of the entity-body, including any content-coding that has been applied, but1149 <p id="rfc.section.6.8.p.4">The MD5 digest is computed based on the content of the entity-body, including any content-coding that has been applied, but 1140 1150 not including any transfer-encoding applied to the message-body. If the message is received with a transfer-encoding, that 1141 1151 encoding <em class="bcp14">MUST</em> be removed prior to checking the Content-MD5 value against the received entity. 1142 1152 </p> 1143 <p id="rfc.section. 5.8.p.5">This has the result that the digest is computed on the octets of the entity-body exactly as, and in the order that, they would1153 <p id="rfc.section.6.8.p.5">This has the result that the digest is computed on the octets of the entity-body exactly as, and in the order that, they would 1144 1154 be sent if no transfer-encoding were being applied. 1145 1155 </p> 1146 <p id="rfc.section. 5.8.p.6">HTTP extends RFC 1864 to permit the digest to be computed for MIME composite media-types (e.g., multipart/* and message/rfc822),1156 <p id="rfc.section.6.8.p.6">HTTP extends RFC 1864 to permit the digest to be computed for MIME composite media-types (e.g., multipart/* and message/rfc822), 1147 1157 but this does not change how the digest is computed as defined in the preceding paragraph. 1148 1158 </p> 1149 <p id="rfc.section. 5.8.p.7">There are several consequences of this. The entity-body for composite types <em class="bcp14">MAY</em> contain many body-parts, each with its own MIME and HTTP headers (including Content-MD5, Content-Transfer-Encoding, and Content-Encoding1159 <p id="rfc.section.6.8.p.7">There are several consequences of this. The entity-body for composite types <em class="bcp14">MAY</em> contain many body-parts, each with its own MIME and HTTP headers (including Content-MD5, Content-Transfer-Encoding, and Content-Encoding 1150 1160 headers). If a body-part has a Content-Transfer-Encoding or Content-Encoding header, it is assumed that the content of the 1151 1161 body-part has had the encoding applied, and the body-part is included in the Content-MD5 digest as is -- i.e., after the application. 1152 1162 The Transfer-Encoding header field is not allowed within body-parts. 1153 1163 </p> 1154 <p id="rfc.section. 5.8.p.8">Conversion of all line breaks to CRLF <em class="bcp14">MUST NOT</em> be done before computing or checking the digest: the line break convention used in the text actually transmitted <em class="bcp14">MUST</em> be left unaltered when computing the digest.1164 <p id="rfc.section.6.8.p.8">Conversion of all line breaks to CRLF <em class="bcp14">MUST NOT</em> be done before computing or checking the digest: the line break convention used in the text actually transmitted <em class="bcp14">MUST</em> be left unaltered when computing the digest. 1155 1165 </p> 1156 1166 <dl class="empty"> … … 1165 1175 <div id="rfc.iref.c.6"></div> 1166 1176 <div id="rfc.iref.h.9"></div> 1167 <h2 id="rfc.section. 5.9"><a href="#rfc.section.5.9">5.9</a> <a id="header.content-type" href="#header.content-type">Content-Type</a></h2>1168 <p id="rfc.section. 5.9.p.1">The Content-Type entity-header field indicates the media type of the entity-body sent to the recipient or, in the case of1177 <h2 id="rfc.section.6.9"><a href="#rfc.section.6.9">6.9</a> <a id="header.content-type" href="#header.content-type">Content-Type</a></h2> 1178 <p id="rfc.section.6.9.p.1">The Content-Type entity-header field indicates the media type of the entity-body sent to the recipient or, in the case of 1169 1179 the HEAD method, the media type that would have been sent had the request been a GET. 1170 1180 </p> 1171 <div id="rfc.figure.u.3 1"></div><pre class="inline"><span id="rfc.iref.g.31"></span> Content-Type = "Content-Type" ":" media-type1172 </pre><p id="rfc.section. 5.9.p.3">Media types are defined in <a href="#media.types" title="Media Types">Section 2.3</a>. An example of the field is1173 </p> 1174 <div id="rfc.figure.u.3 2"></div><pre class="text"> Content-Type: text/html; charset=ISO-8859-41175 </pre><p id="rfc.section. 5.9.p.5">Further discussion of methods for identifying the media type of an entity is provided in <a href="#type" title="Type">Section 3.2.1</a>.1176 </p> 1177 <h1 id="rfc.section. 6"><a href="#rfc.section.6">6.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>1178 <p id="rfc.section. 6.p.1"> <span class="comment">[rfc.comment.1: TBD.]</span>1179 </p> 1180 <h1 id="rfc.section. 7"><a href="#rfc.section.7">7.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>1181 <p id="rfc.section. 7.p.1">This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.11181 <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.31"></span> Content-Type = "Content-Type" ":" media-type 1182 </pre><p id="rfc.section.6.9.p.3">Media types are defined in <a href="#media.types" title="Media Types">Section 3.3</a>. An example of the field is 1183 </p> 1184 <div id="rfc.figure.u.34"></div><pre class="text"> Content-Type: text/html; charset=ISO-8859-4 1185 </pre><p id="rfc.section.6.9.p.5">Further discussion of methods for identifying the media type of an entity is provided in <a href="#type" title="Type">Section 4.2.1</a>. 1186 </p> 1187 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> 1188 <p id="rfc.section.7.p.1"> <span class="comment">[rfc.comment.1: TBD.]</span> 1189 </p> 1190 <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1> 1191 <p id="rfc.section.8.p.1">This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.1 1182 1192 as described by this document. The discussion does not include definitive solutions to the problems revealed, though it does 1183 1193 make some suggestions for reducing security risks. 1184 1194 </p> 1185 <h2 id="rfc.section. 7.1"><a href="#rfc.section.7.1">7.1</a> <a id="privacy.issues.connected.to.accept.headers" href="#privacy.issues.connected.to.accept.headers">Privacy Issues Connected to Accept Headers</a></h2>1186 <p id="rfc.section. 7.1.p.1">Accept request-headers can reveal information about the user to all servers which are accessed. The Accept-Language header1195 <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a> <a id="privacy.issues.connected.to.accept.headers" href="#privacy.issues.connected.to.accept.headers">Privacy Issues Connected to Accept Headers</a></h2> 1196 <p id="rfc.section.8.1.p.1">Accept request-headers can reveal information about the user to all servers which are accessed. The Accept-Language header 1187 1197 in particular can reveal information the user would consider to be of a private nature, because the understanding of particular 1188 1198 languages is often strongly correlated to the membership of a particular ethnic group. User agents which offer the option … … 1190 1200 process include a message which makes the user aware of the loss of privacy involved. 1191 1201 </p> 1192 <p id="rfc.section. 7.1.p.2">An approach that limits the loss of privacy would be for a user agent to omit the sending of Accept-Language headers by default,1202 <p id="rfc.section.8.1.p.2">An approach that limits the loss of privacy would be for a user agent to omit the sending of Accept-Language headers by default, 1193 1203 and to ask the user whether or not to start sending Accept-Language headers to a server if it detects, by looking for any 1194 1204 Vary response-header fields generated by the server, that such sending could improve the quality of service. 1195 1205 </p> 1196 <p id="rfc.section. 7.1.p.3">Elaborate user-customized accept header fields sent in every request, in particular if these include quality values, can be1206 <p id="rfc.section.8.1.p.3">Elaborate user-customized accept header fields sent in every request, in particular if these include quality values, can be 1197 1207 used by servers as relatively reliable and long-lived user identifiers. Such user identifiers would allow content providers 1198 1208 to do click-trail tracking, and would allow collaborating content providers to match cross-server click-trails or form submissions … … 1202 1212 filter the accept headers in relayed requests. General purpose user agents which provide a high degree of header configurability <em class="bcp14">SHOULD</em> warn users about the loss of privacy which can be involved. 1203 1213 </p> 1204 <h2 id="rfc.section. 7.2"><a href="#rfc.section.7.2">7.2</a> <a id="content-disposition.issues" href="#content-disposition.issues">Content-Disposition Issues</a></h2>1205 <p id="rfc.section. 7.2.p.1"> <a href="#RFC1806" id="rfc.xref.RFC1806.1"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header">[RFC1806]</cite></a>, from which the often implemented Content-Disposition (see <a href="#content-disposition" id="rfc.xref.content-disposition.1" title="Content-Disposition">Appendix B.1</a>) header in HTTP is derived, has a number of very serious security considerations. Content-Disposition is not part of the1214 <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a> <a id="content-disposition.issues" href="#content-disposition.issues">Content-Disposition Issues</a></h2> 1215 <p id="rfc.section.8.2.p.1"> <a href="#RFC1806" id="rfc.xref.RFC1806.1"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header">[RFC1806]</cite></a>, from which the often implemented Content-Disposition (see <a href="#content-disposition" id="rfc.xref.content-disposition.1" title="Content-Disposition">Appendix B.1</a>) header in HTTP is derived, has a number of very serious security considerations. Content-Disposition is not part of the 1206 1216 HTTP standard, but since it is widely implemented, we are documenting its use and risks for implementors. See <a href="#RFC2183" id="rfc.xref.RFC2183.1"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a> (which updates <a href="#RFC1806" id="rfc.xref.RFC1806.2"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header">[RFC1806]</cite></a>) for details. 1207 1217 </p> 1208 <h1 id="rfc.section. 8"><a href="#rfc.section.8">8.</a> <a id="ack" href="#ack">Acknowledgments</a></h1>1209 <h1 id="rfc.references"><a id="rfc.section. 9" href="#rfc.section.9">9.</a> References1218 <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a id="ack" href="#ack">Acknowledgments</a></h1> 1219 <h1 id="rfc.references"><a id="rfc.section.10" href="#rfc.section.10">10.</a> References 1210 1220 </h1> 1211 <h2 id="rfc.references.1"><a href="#rfc.section. 9.1" id="rfc.section.9.1">9.1</a> Normative References1221 <h2 id="rfc.references.1"><a href="#rfc.section.10.1" id="rfc.section.10.1">10.1</a> Normative References 1212 1222 </h2> 1213 1223 <table summary="Normative References"> … … 1288 1298 </tr> 1289 1299 </table> 1290 <h2 id="rfc.references.2"><a href="#rfc.section. 9.2" id="rfc.section.9.2">9.2</a> Informative References1300 <h2 id="rfc.references.2"><a href="#rfc.section.10.2" id="rfc.section.10.2">10.2</a> Informative References 1291 1301 </h2> 1292 1302 <table summary="Informative References"> … … 1388 1398 environments. 1389 1399 </p> 1390 <div id="rfc.figure.u.3 3"></div><pre class="inline"><span id="rfc.iref.g.32"></span> MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT1400 <div id="rfc.figure.u.35"></div><pre class="inline"><span id="rfc.iref.g.32"></span> MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT 1391 1401 </pre><p id="rfc.section.A.1.p.3">MIME version "1.0" is the default for use in HTTP/1.1. However, HTTP/1.1 message parsing and semantics are defined by this 1392 1402 document and not the MIME specification. 1393 1403 </p> 1394 1404 <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a> <a id="conversion.to.canonical.form" href="#conversion.to.canonical.form">Conversion to Canonical Form</a></h2> 1395 <p id="rfc.section.A.2.p.1"> <a href="#RFC2045" id="rfc.xref.RFC2045.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> requires that an Internet mail entity be converted to canonical form prior to being transferred, as described in <a href="http://tools.ietf.org/html/rfc2049#section-4">Section 4</a> of <a href="#RFC2049" id="rfc.xref.RFC2049.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples">[RFC2049]</cite></a>. <a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section 2.3.1</a> of this document describes the forms allowed for subtypes of the "text" media type when transmitted over HTTP. <a href="#RFC2046" id="rfc.xref.RFC2046.3"><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 line1405 <p id="rfc.section.A.2.p.1"> <a href="#RFC2045" id="rfc.xref.RFC2045.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> requires that an Internet mail entity be converted to canonical form prior to being transferred, as described in <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 3.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.3"><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 1396 1406 break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a line break within text content when a message is transmitted 1397 1407 over HTTP. 1398 1408 </p> 1399 <p id="rfc.section.A.2.p.2">Where it is possible, a proxy or gateway from HTTP to a strict MIME environment <em class="bcp14">SHOULD</em> translate all line breaks within the text media types described in <a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section 2.3.1</a> of this document to the RFC 2049 canonical form of CRLF. Note, however, that this might be complicated by the presence of1409 <p id="rfc.section.A.2.p.2">Where it is possible, a proxy or gateway from HTTP to a strict MIME environment <em class="bcp14">SHOULD</em> translate all line breaks within the text media types described in <a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section 3.3.1</a> of this document to the RFC 2049 canonical form of CRLF. Note, however, that this might be complicated by the presence of 1400 1410 a Content-Encoding and by the fact that HTTP allows the use of some character sets which do not use octets 13 and 10 to represent 1401 1411 CR and LF, as is the case for some multi-byte character sets. … … 1420 1430 </p> 1421 1431 <h2 id="rfc.section.A.5"><a href="#rfc.section.A.5">A.5</a> <a id="introduction.of.transfer-encoding" href="#introduction.of.transfer-encoding">Introduction of Transfer-Encoding</a></h2> 1422 <p id="rfc.section.A.5.p.1">HTTP/1.1 introduces the Transfer-Encoding header field (<a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 8.7</a> of <a href="#Part1" id="rfc.xref.Part1. 4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Proxies/gateways <em class="bcp14">MUST</em> remove any transfer-coding prior to forwarding a message via a MIME-compliant protocol.1432 <p id="rfc.section.A.5.p.1">HTTP/1.1 introduces the Transfer-Encoding header field (<a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 8.7</a> of <a href="#Part1" id="rfc.xref.Part1.11"><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. 1423 1433 </p> 1424 1434 <h2 id="rfc.section.A.6"><a href="#rfc.section.A.6">A.6</a> <a id="mhtml.line.length" href="#mhtml.line.length">MHTML and Line Length Limitations</a></h2> 1425 1435 <p id="rfc.section.A.6.p.1">HTTP implementations which share code with MHTML <a href="#RFC2557" id="rfc.xref.RFC2557.1"><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 1426 1436 fold long lines. MHTML messages being transported by HTTP follow all conventions of MHTML, including line length limitations 1427 and folding, canonicalization, etc., since HTTP transports all message-bodies as payload (see <a href="#multipart.types" title="Multipart Types">Section 2.3.2</a>) and does not interpret the content or any MIME header lines that might be contained therein.1437 and folding, canonicalization, etc., since HTTP transports all message-bodies as payload (see <a href="#multipart.types" title="Multipart Types">Section 3.3.2</a>) and does not interpret the content or any MIME header lines that might be contained therein. 1428 1438 </p> 1429 1439 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="additional.features" href="#additional.features">Additional Features</a></h1> … … 1442 1452 in <a href="#RFC1806" id="rfc.xref.RFC1806.3"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header">[RFC1806]</cite></a>. 1443 1453 </p> 1444 <div id="rfc.figure.u.3 4"></div><pre class="inline"><span id="rfc.iref.g.33"></span><span id="rfc.iref.g.34"></span><span id="rfc.iref.g.35"></span><span id="rfc.iref.g.36"></span><span id="rfc.iref.g.37"></span><span id="rfc.iref.g.38"></span> content-disposition = "Content-Disposition" ":"1454 <div id="rfc.figure.u.36"></div><pre class="inline"><span id="rfc.iref.g.33"></span><span id="rfc.iref.g.34"></span><span id="rfc.iref.g.35"></span><span id="rfc.iref.g.36"></span><span id="rfc.iref.g.37"></span><span id="rfc.iref.g.38"></span> content-disposition = "Content-Disposition" ":" 1445 1455 disposition-type *( ";" disposition-parm ) 1446 1456 disposition-type = "attachment" | disp-extension-token … … 1450 1460 disp-extension-parm = token "=" ( token | quoted-string ) 1451 1461 </pre><p id="rfc.section.B.1.p.3">An example is</p> 1452 <div id="rfc.figure.u.3 5"></div><pre class="text"> Content-Disposition: attachment; filename="fname.ext"1462 <div id="rfc.figure.u.37"></div><pre class="text"> Content-Disposition: attachment; filename="fname.ext" 1453 1463 </pre><p id="rfc.section.B.1.p.5">The receiving user agent <em class="bcp14">SHOULD NOT</em> respect any directory path information present in the filename-parm parameter, which is the only parameter believed to apply 1454 1464 to HTTP implementations at this time. The filename <em class="bcp14">SHOULD</em> be treated as a terminal component only. … … 1457 1467 agent should not display the response, but directly enter a `save response as...' dialog. 1458 1468 </p> 1459 <p id="rfc.section.B.1.p.7">See <a href="#content-disposition.issues" title="Content-Disposition Issues">Section 7.2</a> for Content-Disposition security issues.1469 <p id="rfc.section.B.1.p.7">See <a href="#content-disposition.issues" title="Content-Disposition Issues">Section 8.2</a> for Content-Disposition security issues. 1460 1470 </p> 1461 1471 <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a> <a id="compatibility" href="#compatibility">Compatibility with Previous Versions</a></h1> … … 1463 1473 <p id="rfc.section.C.1.p.1">Transfer-coding and message lengths all interact in ways that required fixing exactly when chunked encoding is used (to allow 1464 1474 for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are 1465 computed. (<a href="#entity.length" title="Entity Length">Section 3.2.2</a>, see also <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a> and <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).1466 </p> 1467 <p id="rfc.section.C.1.p.2">Charset wildcarding is introduced to avoid explosion of character set names in accept headers. (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.2" title="Accept-Charset">Section 5.2</a>)1475 computed. (<a href="#entity.length" title="Entity Length">Section 4.2.2</a>, see also <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a> and <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1476 </p> 1477 <p id="rfc.section.C.1.p.2">Charset wildcarding is introduced to avoid explosion of character set names in accept headers. (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.2" title="Accept-Charset">Section 6.2</a>) 1468 1478 </p> 1469 1479 <p id="rfc.section.C.1.p.3">Content-Base was deleted from the specification: it was not implemented widely, and there is no simple, safe way to introduce 1470 1480 it without a robust extension mechanism. In addition, it is used in a similar, but not identical fashion in MHTML <a href="#RFC2557" id="rfc.xref.RFC2557.2"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a>. 1471 1481 </p> 1472 <p id="rfc.section.C.1.p.4">A content-coding of "identity" was introduced, to solve problems discovered in caching. (<a href="#content.codings" title="Content Codings">Section 2.2</a>)1473 </p> 1474 <p id="rfc.section.C.1.p.5">Quality Values of zero should indicate that "I don't want something" to allow clients to refuse a representation. (<a href="#quality.values" title="Quality Values">Section 2.4</a>)1482 <p id="rfc.section.C.1.p.4">A content-coding of "identity" was introduced, to solve problems discovered in caching. (<a href="#content.codings" title="Content Codings">Section 3.2</a>) 1483 </p> 1484 <p id="rfc.section.C.1.p.5">Quality Values of zero should indicate that "I don't want something" to allow clients to refuse a representation. (<a href="#quality.values" title="Quality Values">Section 3.4</a>) 1475 1485 </p> 1476 1486 <p id="rfc.section.C.1.p.6">The Alternates<span id="rfc.iref.a.5"></span><span id="rfc.iref.h.11"></span>, Content-Version<span id="rfc.iref.c.8"></span><span id="rfc.iref.h.12"></span>, Derived-From<span id="rfc.iref.d.2"></span><span id="rfc.iref.h.13"></span>, Link<span id="rfc.iref.l.1"></span><span id="rfc.iref.h.14"></span>, URI<span id="rfc.iref.u.1"></span><span id="rfc.iref.h.15"></span>, Public<span id="rfc.iref.p.1"></span><span id="rfc.iref.h.16"></span> and Content-Base<span id="rfc.iref.c.9"></span><span id="rfc.iref.h.17"></span> header fields were defined in previous versions of this specification, but not commonly implemented. See <a href="#RFC2068" id="rfc.xref.RFC2068.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>. 1477 1487 </p> 1478 1488 <h2 id="rfc.section.C.2"><a href="#rfc.section.C.2">C.2</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2> 1479 <p id="rfc.section.C.2.p.1">Clarify contexts that charset is used in. (<a href="#character.sets" title="Character Sets">Section 2.1</a>)1489 <p id="rfc.section.C.2.p.1">Clarify contexts that charset is used in. (<a href="#character.sets" title="Character Sets">Section 3.1</a>) 1480 1490 </p> 1481 1491 <p id="rfc.section.C.2.p.2">Remove reference to non-existant identity transfer-coding value tokens. (<a href="#no.content-transfer-encoding" title="No Content-Transfer-Encoding">Appendix A.4</a>) … … 1516 1526 <h2 id="rfc.section.D.3"><a href="#rfc.section.D.3">D.3</a> Since draft-ietf-httpbis-p3-payload-01 1517 1527 </h2> 1528 <p id="rfc.section.D.3.p.1">Ongoing work on ABNF conversion (<<a href="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36">http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36</a>>): 1529 </p> 1530 <ul> 1531 <li>Add explicit references to BNF syntax and rules imported from other parts of the specification.</li> 1532 </ul> 1518 1533 <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1> 1519 1534 <p>Copyright © The IETF Trust (2008).</p> … … 1549 1564 <ul class="ind"> 1550 1565 <li class="indline0"><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul class="ind"> 1551 <li class="indline1">Accept header <a class="iref" href="#rfc.xref.header.accept.1"> 2.3</a>, <a class="iref" href="#rfc.xref.header.accept.2">4.1</a>, <a class="iref" href="#rfc.iref.a.1"><b>5.1</b></a></li>1552 <li class="indline1">Accept-Charset header <a class="iref" href="#rfc.xref.header.accept-charset.1"> 4.1</a>, <a class="iref" href="#rfc.iref.a.2"><b>5.2</b></a>, <a class="iref" href="#rfc.xref.header.accept-charset.2">C.1</a></li>1553 <li class="indline1">Accept-Encoding header <a class="iref" href="#rfc.xref.header.accept-encoding.1"> 2.2</a>, <a class="iref" href="#rfc.xref.header.accept-encoding.2">4.1</a>, <a class="iref" href="#rfc.iref.a.3"><b>5.3</b></a></li>1554 <li class="indline1">Accept-Language header <a class="iref" href="#rfc.xref.header.accept-language.1"> 4.1</a>, <a class="iref" href="#rfc.iref.a.4"><b>5.4</b></a></li>1566 <li class="indline1">Accept header <a class="iref" href="#rfc.xref.header.accept.1">3.3</a>, <a class="iref" href="#rfc.xref.header.accept.2">5.1</a>, <a class="iref" href="#rfc.iref.a.1"><b>6.1</b></a></li> 1567 <li class="indline1">Accept-Charset header <a class="iref" href="#rfc.xref.header.accept-charset.1">5.1</a>, <a class="iref" href="#rfc.iref.a.2"><b>6.2</b></a>, <a class="iref" href="#rfc.xref.header.accept-charset.2">C.1</a></li> 1568 <li class="indline1">Accept-Encoding header <a class="iref" href="#rfc.xref.header.accept-encoding.1">3.2</a>, <a class="iref" href="#rfc.xref.header.accept-encoding.2">5.1</a>, <a class="iref" href="#rfc.iref.a.3"><b>6.3</b></a></li> 1569 <li class="indline1">Accept-Language header <a class="iref" href="#rfc.xref.header.accept-language.1">5.1</a>, <a class="iref" href="#rfc.iref.a.4"><b>6.4</b></a></li> 1555 1570 <li class="indline1">Alternates header <a class="iref" href="#rfc.iref.a.5"><b>C.1</b></a></li> 1556 1571 </ul> 1557 1572 </li> 1558 1573 <li class="indline0"><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul class="ind"> 1559 <li class="indline1">compress <a class="iref" href="#rfc.iref.c.1"> 2.2</a></li>1574 <li class="indline1">compress <a class="iref" href="#rfc.iref.c.1">3.2</a></li> 1560 1575 <li class="indline1">Content-Base header <a class="iref" href="#rfc.iref.c.9"><b>C.1</b></a></li> 1561 <li class="indline1">Content-Disposition header <a class="iref" href="#rfc.xref.content-disposition.1"> 7.2</a>, <a class="iref" href="#rfc.iref.c.7"><b>B.1</b></a></li>1562 <li class="indline1">Content-Encoding header <a class="iref" href="#rfc.xref.header.content-encoding.1"> 2.2</a>, <a class="iref" href="#rfc.xref.header.content-encoding.2">3.1</a>, <a class="iref" href="#rfc.iref.c.2"><b>5.5</b></a>, <a class="iref" href="#rfc.xref.header.content-encoding.3">5.5</a></li>1563 <li class="indline1">Content-Language header <a class="iref" href="#rfc.xref.header.content-language.1"> 3.1</a>, <a class="iref" href="#rfc.iref.c.3"><b>5.6</b></a></li>1564 <li class="indline1">Content-Location header <a class="iref" href="#rfc.xref.header.content-location.1"> 3.1</a>, <a class="iref" href="#rfc.iref.c.4"><b>5.7</b></a></li>1565 <li class="indline1">Content-MD5 header <a class="iref" href="#rfc.xref.header.content-md5.1"> 3.1</a>, <a class="iref" href="#rfc.iref.c.5"><b>5.8</b></a></li>1566 <li class="indline1">Content-Type header <a class="iref" href="#rfc.xref.header.content-type.1"> 2.3</a>, <a class="iref" href="#rfc.xref.header.content-type.2">3.1</a>, <a class="iref" href="#rfc.iref.c.6"><b>5.9</b></a></li>1576 <li class="indline1">Content-Disposition header <a class="iref" href="#rfc.xref.content-disposition.1">8.2</a>, <a class="iref" href="#rfc.iref.c.7"><b>B.1</b></a></li> 1577 <li class="indline1">Content-Encoding header <a class="iref" href="#rfc.xref.header.content-encoding.1">3.2</a>, <a class="iref" href="#rfc.xref.header.content-encoding.2">4.1</a>, <a class="iref" href="#rfc.iref.c.2"><b>6.5</b></a>, <a class="iref" href="#rfc.xref.header.content-encoding.3">6.5</a></li> 1578 <li class="indline1">Content-Language header <a class="iref" href="#rfc.xref.header.content-language.1">4.1</a>, <a class="iref" href="#rfc.iref.c.3"><b>6.6</b></a></li> 1579 <li class="indline1">Content-Location header <a class="iref" href="#rfc.xref.header.content-location.1">4.1</a>, <a class="iref" href="#rfc.iref.c.4"><b>6.7</b></a></li> 1580 <li class="indline1">Content-MD5 header <a class="iref" href="#rfc.xref.header.content-md5.1">4.1</a>, <a class="iref" href="#rfc.iref.c.5"><b>6.8</b></a></li> 1581 <li class="indline1">Content-Type header <a class="iref" href="#rfc.xref.header.content-type.1">3.3</a>, <a class="iref" href="#rfc.xref.header.content-type.2">4.1</a>, <a class="iref" href="#rfc.iref.c.6"><b>6.9</b></a></li> 1567 1582 <li class="indline1">Content-Version header <a class="iref" href="#rfc.iref.c.8"><b>C.1</b></a></li> 1568 1583 </ul> 1569 1584 </li> 1570 1585 <li class="indline0"><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul class="ind"> 1571 <li class="indline1">deflate <a class="iref" href="#rfc.iref.d.1"> 2.2</a></li>1586 <li class="indline1">deflate <a class="iref" href="#rfc.iref.d.1">3.2</a></li> 1572 1587 <li class="indline1">Derived-From header <a class="iref" href="#rfc.iref.d.2"><b>C.1</b></a></li> 1573 1588 </ul> … … 1576 1591 <li class="indline1"><tt>Grammar</tt> 1577 1592 <ul class="ind"> 1578 <li class="indline1"><tt>Accept</tt> <a class="iref" href="#rfc.iref.g.17"><b> 5.1</b></a></li>1579 <li class="indline1"><tt>Accept-Charset</tt> <a class="iref" href="#rfc.iref.g.21"><b> 5.2</b></a></li>1580 <li class="indline1"><tt>Accept-Encoding</tt> <a class="iref" href="#rfc.iref.g.22"><b> 5.3</b></a></li>1581 <li class="indline1"><tt>accept-extension</tt> <a class="iref" href="#rfc.iref.g.20"><b> 5.1</b></a></li>1582 <li class="indline1"><tt>Accept-Language</tt> <a class="iref" href="#rfc.iref.g.24"><b> 5.4</b></a></li>1583 <li class="indline1"><tt>accept-params</tt> <a class="iref" href="#rfc.iref.g.19"><b> 5.1</b></a></li>1584 <li class="indline1"><tt>attribute</tt> <a class="iref" href="#rfc.iref.g.8"><b> 2.3</b></a></li>1585 <li class="indline1"><tt>charset</tt> <a class="iref" href="#rfc.iref.g.1"><b> 2.1</b></a></li>1586 <li class="indline1"><tt>codings</tt> <a class="iref" href="#rfc.iref.g.23"><b> 5.3</b></a></li>1587 <li class="indline1"><tt>content-coding</tt> <a class="iref" href="#rfc.iref.g.2"><b> 2.2</b></a></li>1593 <li class="indline1"><tt>Accept</tt> <a class="iref" href="#rfc.iref.g.17"><b>6.1</b></a></li> 1594 <li class="indline1"><tt>Accept-Charset</tt> <a class="iref" href="#rfc.iref.g.21"><b>6.2</b></a></li> 1595 <li class="indline1"><tt>Accept-Encoding</tt> <a class="iref" href="#rfc.iref.g.22"><b>6.3</b></a></li> 1596 <li class="indline1"><tt>accept-extension</tt> <a class="iref" href="#rfc.iref.g.20"><b>6.1</b></a></li> 1597 <li class="indline1"><tt>Accept-Language</tt> <a class="iref" href="#rfc.iref.g.24"><b>6.4</b></a></li> 1598 <li class="indline1"><tt>accept-params</tt> <a class="iref" href="#rfc.iref.g.19"><b>6.1</b></a></li> 1599 <li class="indline1"><tt>attribute</tt> <a class="iref" href="#rfc.iref.g.8"><b>3.3</b></a></li> 1600 <li class="indline1"><tt>charset</tt> <a class="iref" href="#rfc.iref.g.1"><b>3.1</b></a></li> 1601 <li class="indline1"><tt>codings</tt> <a class="iref" href="#rfc.iref.g.23"><b>6.3</b></a></li> 1602 <li class="indline1"><tt>content-coding</tt> <a class="iref" href="#rfc.iref.g.2"><b>3.2</b></a></li> 1588 1603 <li class="indline1"><tt>content-disposition</tt> <a class="iref" href="#rfc.iref.g.33"><b>B.1</b></a></li> 1589 <li class="indline1"><tt>Content-Encoding</tt> <a class="iref" href="#rfc.iref.g.26"><b> 5.5</b></a></li>1590 <li class="indline1"><tt>Content-Language</tt> <a class="iref" href="#rfc.iref.g.27"><b> 5.6</b></a></li>1591 <li class="indline1"><tt>Content-Location</tt> <a class="iref" href="#rfc.iref.g.28"><b> 5.7</b></a></li>1592 <li class="indline1"><tt>Content-MD5</tt> <a class="iref" href="#rfc.iref.g.29"><b> 5.8</b></a></li>1593 <li class="indline1"><tt>Content-Type</tt> <a class="iref" href="#rfc.iref.g.31"><b> 5.9</b></a></li>1604 <li class="indline1"><tt>Content-Encoding</tt> <a class="iref" href="#rfc.iref.g.26"><b>6.5</b></a></li> 1605 <li class="indline1"><tt>Content-Language</tt> <a class="iref" href="#rfc.iref.g.27"><b>6.6</b></a></li> 1606 <li class="indline1"><tt>Content-Location</tt> <a class="iref" href="#rfc.iref.g.28"><b>6.7</b></a></li> 1607 <li class="indline1"><tt>Content-MD5</tt> <a class="iref" href="#rfc.iref.g.29"><b>6.8</b></a></li> 1608 <li class="indline1"><tt>Content-Type</tt> <a class="iref" href="#rfc.iref.g.31"><b>6.9</b></a></li> 1594 1609 <li class="indline1"><tt>disp-extension-parm</tt> <a class="iref" href="#rfc.iref.g.38"><b>B.1</b></a></li> 1595 1610 <li class="indline1"><tt>disp-extension-token</tt> <a class="iref" href="#rfc.iref.g.37"><b>B.1</b></a></li> 1596 1611 <li class="indline1"><tt>disposition-parm</tt> <a class="iref" href="#rfc.iref.g.35"><b>B.1</b></a></li> 1597 1612 <li class="indline1"><tt>disposition-type</tt> <a class="iref" href="#rfc.iref.g.34"><b>B.1</b></a></li> 1598 <li class="indline1"><tt>entity-body</tt> <a class="iref" href="#rfc.iref.g.16"><b> 3.2</b></a></li>1599 <li class="indline1"><tt>entity-header</tt> <a class="iref" href="#rfc.iref.g.14"><b> 3.1</b></a></li>1600 <li class="indline1"><tt>extension-header</tt> <a class="iref" href="#rfc.iref.g.15"><b> 3.1</b></a></li>1613 <li class="indline1"><tt>entity-body</tt> <a class="iref" href="#rfc.iref.g.16"><b>4.2</b></a></li> 1614 <li class="indline1"><tt>entity-header</tt> <a class="iref" href="#rfc.iref.g.14"><b>4.1</b></a></li> 1615 <li class="indline1"><tt>extension-header</tt> <a class="iref" href="#rfc.iref.g.15"><b>4.1</b></a></li> 1601 1616 <li class="indline1"><tt>filename-parm</tt> <a class="iref" href="#rfc.iref.g.36"><b>B.1</b></a></li> 1602 <li class="indline1"><tt>language-range</tt> <a class="iref" href="#rfc.iref.g.25"><b> 5.4</b></a></li>1603 <li class="indline1"><tt>language-tag</tt> <a class="iref" href="#rfc.iref.g.11"><b> 2.5</b></a></li>1604 <li class="indline1"><tt>md5-digest</tt> <a class="iref" href="#rfc.iref.g.30"><b> 5.8</b></a></li>1605 <li class="indline1"><tt>media-range</tt> <a class="iref" href="#rfc.iref.g.18"><b> 5.1</b></a></li>1606 <li class="indline1"><tt>media-type</tt> <a class="iref" href="#rfc.iref.g.4"><b> 2.3</b></a></li>1617 <li class="indline1"><tt>language-range</tt> <a class="iref" href="#rfc.iref.g.25"><b>6.4</b></a></li> 1618 <li class="indline1"><tt>language-tag</tt> <a class="iref" href="#rfc.iref.g.11"><b>3.5</b></a></li> 1619 <li class="indline1"><tt>md5-digest</tt> <a class="iref" href="#rfc.iref.g.30"><b>6.8</b></a></li> 1620 <li class="indline1"><tt>media-range</tt> <a class="iref" href="#rfc.iref.g.18"><b>6.1</b></a></li> 1621 <li class="indline1"><tt>media-type</tt> <a class="iref" href="#rfc.iref.g.4"><b>3.3</b></a></li> 1607 1622 <li class="indline1"><tt>MIME-Version</tt> <a class="iref" href="#rfc.iref.g.32"><b>A.1</b></a></li> 1608 <li class="indline1"><tt>parameter</tt> <a class="iref" href="#rfc.iref.g.7"><b> 2.3</b></a></li>1609 <li class="indline1"><tt>primary-tag</tt> <a class="iref" href="#rfc.iref.g.12"><b> 2.5</b></a></li>1610 <li class="indline1"><tt>qvalue</tt> <a class="iref" href="#rfc.iref.g.10"><b> 2.4</b></a></li>1611 <li class="indline1"><tt>subtag</tt> <a class="iref" href="#rfc.iref.g.13"><b> 2.5</b></a></li>1612 <li class="indline1"><tt>subtype</tt> <a class="iref" href="#rfc.iref.g.6"><b> 2.3</b></a></li>1613 <li class="indline1"><tt>type</tt> <a class="iref" href="#rfc.iref.g.5"><b> 2.3</b></a></li>1614 <li class="indline1"><tt>value</tt> <a class="iref" href="#rfc.iref.g.9"><b> 2.3</b></a></li>1623 <li class="indline1"><tt>parameter</tt> <a class="iref" href="#rfc.iref.g.7"><b>3.3</b></a></li> 1624 <li class="indline1"><tt>primary-tag</tt> <a class="iref" href="#rfc.iref.g.12"><b>3.5</b></a></li> 1625 <li class="indline1"><tt>qvalue</tt> <a class="iref" href="#rfc.iref.g.10"><b>3.4</b></a></li> 1626 <li class="indline1"><tt>subtag</tt> <a class="iref" href="#rfc.iref.g.13"><b>3.5</b></a></li> 1627 <li class="indline1"><tt>subtype</tt> <a class="iref" href="#rfc.iref.g.6"><b>3.3</b></a></li> 1628 <li class="indline1"><tt>type</tt> <a class="iref" href="#rfc.iref.g.5"><b>3.3</b></a></li> 1629 <li class="indline1"><tt>value</tt> <a class="iref" href="#rfc.iref.g.9"><b>3.3</b></a></li> 1615 1630 </ul> 1616 1631 </li> 1617 <li class="indline1">gzip <a class="iref" href="#rfc.iref.g.3"> 2.2</a></li>1632 <li class="indline1">gzip <a class="iref" href="#rfc.iref.g.3">3.2</a></li> 1618 1633 </ul> 1619 1634 </li> … … 1621 1636 <li class="indline1">Headers 1622 1637 <ul class="ind"> 1623 <li class="indline1">Accept <a class="iref" href="#rfc.xref.header.accept.1"> 2.3</a>, <a class="iref" href="#rfc.xref.header.accept.2">4.1</a>, <a class="iref" href="#rfc.iref.h.1"><b>5.1</b></a></li>1624 <li class="indline1">Accept-Charset <a class="iref" href="#rfc.xref.header.accept-charset.1"> 4.1</a>, <a class="iref" href="#rfc.iref.h.2"><b>5.2</b></a>, <a class="iref" href="#rfc.xref.header.accept-charset.2">C.1</a></li>1625 <li class="indline1">Accept-Encoding <a class="iref" href="#rfc.xref.header.accept-encoding.1"> 2.2</a>, <a class="iref" href="#rfc.xref.header.accept-encoding.2">4.1</a>, <a class="iref" href="#rfc.iref.h.3"><b>5.3</b></a></li>1626 <li class="indline1">Accept-Language <a class="iref" href="#rfc.xref.header.accept-language.1"> 4.1</a>, <a class="iref" href="#rfc.iref.h.4"><b>5.4</b></a></li>1638 <li class="indline1">Accept <a class="iref" href="#rfc.xref.header.accept.1">3.3</a>, <a class="iref" href="#rfc.xref.header.accept.2">5.1</a>, <a class="iref" href="#rfc.iref.h.1"><b>6.1</b></a></li> 1639 <li class="indline1">Accept-Charset <a class="iref" href="#rfc.xref.header.accept-charset.1">5.1</a>, <a class="iref" href="#rfc.iref.h.2"><b>6.2</b></a>, <a class="iref" href="#rfc.xref.header.accept-charset.2">C.1</a></li> 1640 <li class="indline1">Accept-Encoding <a class="iref" href="#rfc.xref.header.accept-encoding.1">3.2</a>, <a class="iref" href="#rfc.xref.header.accept-encoding.2">5.1</a>, <a class="iref" href="#rfc.iref.h.3"><b>6.3</b></a></li> 1641 <li class="indline1">Accept-Language <a class="iref" href="#rfc.xref.header.accept-language.1">5.1</a>, <a class="iref" href="#rfc.iref.h.4"><b>6.4</b></a></li> 1627 1642 <li class="indline1">Alternate <a class="iref" href="#rfc.iref.h.11"><b>C.1</b></a></li> 1628 1643 <li class="indline1">Content-Base <a class="iref" href="#rfc.iref.h.17"><b>C.1</b></a></li> 1629 <li class="indline1">Content-Disposition <a class="iref" href="#rfc.xref.content-disposition.1"> 7.2</a>, <a class="iref" href="#rfc.iref.h.10"><b>B.1</b></a></li>1630 <li class="indline1">Content-Encoding <a class="iref" href="#rfc.xref.header.content-encoding.1"> 2.2</a>, <a class="iref" href="#rfc.xref.header.content-encoding.2">3.1</a>, <a class="iref" href="#rfc.iref.h.5"><b>5.5</b></a>, <a class="iref" href="#rfc.xref.header.content-encoding.3">5.5</a></li>1631 <li class="indline1">Content-Language <a class="iref" href="#rfc.xref.header.content-language.1"> 3.1</a>, <a class="iref" href="#rfc.iref.h.6"><b>5.6</b></a></li>1632 <li class="indline1">Content-Location <a class="iref" href="#rfc.xref.header.content-location.1"> 3.1</a>, <a class="iref" href="#rfc.iref.h.7"><b>5.7</b></a></li>1633 <li class="indline1">Content-MD5 <a class="iref" href="#rfc.xref.header.content-md5.1"> 3.1</a>, <a class="iref" href="#rfc.iref.h.8"><b>5.8</b></a></li>1634 <li class="indline1">Content-Type <a class="iref" href="#rfc.xref.header.content-type.1"> 2.3</a>, <a class="iref" href="#rfc.xref.header.content-type.2">3.1</a>, <a class="iref" href="#rfc.iref.h.9"><b>5.9</b></a></li>1644 <li class="indline1">Content-Disposition <a class="iref" href="#rfc.xref.content-disposition.1">8.2</a>, <a class="iref" href="#rfc.iref.h.10"><b>B.1</b></a></li> 1645 <li class="indline1">Content-Encoding <a class="iref" href="#rfc.xref.header.content-encoding.1">3.2</a>, <a class="iref" href="#rfc.xref.header.content-encoding.2">4.1</a>, <a class="iref" href="#rfc.iref.h.5"><b>6.5</b></a>, <a class="iref" href="#rfc.xref.header.content-encoding.3">6.5</a></li> 1646 <li class="indline1">Content-Language <a class="iref" href="#rfc.xref.header.content-language.1">4.1</a>, <a class="iref" href="#rfc.iref.h.6"><b>6.6</b></a></li> 1647 <li class="indline1">Content-Location <a class="iref" href="#rfc.xref.header.content-location.1">4.1</a>, <a class="iref" href="#rfc.iref.h.7"><b>6.7</b></a></li> 1648 <li class="indline1">Content-MD5 <a class="iref" href="#rfc.xref.header.content-md5.1">4.1</a>, <a class="iref" href="#rfc.iref.h.8"><b>6.8</b></a></li> 1649 <li class="indline1">Content-Type <a class="iref" href="#rfc.xref.header.content-type.1">3.3</a>, <a class="iref" href="#rfc.xref.header.content-type.2">4.1</a>, <a class="iref" href="#rfc.iref.h.9"><b>6.9</b></a></li> 1635 1650 <li class="indline1">Content-Version <a class="iref" href="#rfc.iref.h.12"><b>C.1</b></a></li> 1636 1651 <li class="indline1">Derived-From <a class="iref" href="#rfc.iref.h.13"><b>C.1</b></a></li> … … 1643 1658 </li> 1644 1659 <li class="indline0"><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul class="ind"> 1645 <li class="indline1">identity <a class="iref" href="#rfc.iref.i.1"> 2.2</a></li>1646 <li class="indline1"><em>ISO-8859-1</em> <a class="iref" href="#rfc.xref.ISO-8859-1.1"> 2.1.1</a>, <a class="iref" href="#ISO-8859-1"><b>9.1</b></a></li>1660 <li class="indline1">identity <a class="iref" href="#rfc.iref.i.1">3.2</a></li> 1661 <li class="indline1"><em>ISO-8859-1</em> <a class="iref" href="#rfc.xref.ISO-8859-1.1">3.1.1</a>, <a class="iref" href="#ISO-8859-1"><b>10.1</b></a></li> 1647 1662 </ul> 1648 1663 </li> … … 1652 1667 </li> 1653 1668 <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind"> 1654 <li class="indline1"><em>Part1</em> <a class="iref" href="#rfc.xref.Part1.1">3.1</a>, <a class="iref" href="#rfc.xref.Part1.2">3.2</a>, <a class="iref" href="#rfc.xref.Part1.3">3.2.2</a>, <a class="iref" href="#Part1"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.Part1.4">A.5</a>, <a class="iref" href="#rfc.xref.Part1.5">C.1</a><ul class="ind"> 1655 <li class="indline1"><em>Section 4.3</em> <a class="iref" href="#rfc.xref.Part1.2">3.2</a></li> 1656 <li class="indline1"><em>Section 4.4</em> <a class="iref" href="#rfc.xref.Part1.3">3.2.2</a></li> 1657 <li class="indline1"><em>Section 8.2</em> <a class="iref" href="#rfc.xref.Part1.1">3.1</a></li> 1658 <li class="indline1"><em>Section 8.7</em> <a class="iref" href="#rfc.xref.Part1.4">A.5</a></li> 1669 <li class="indline1"><em>Part1</em> <a class="iref" href="#rfc.xref.Part1.1">2</a>, <a class="iref" href="#rfc.xref.Part1.2">2</a>, <a class="iref" href="#rfc.xref.Part1.3">2</a>, <a class="iref" href="#rfc.xref.Part1.4">2</a>, <a class="iref" href="#rfc.xref.Part1.5">2</a>, <a class="iref" href="#rfc.xref.Part1.6">2</a>, <a class="iref" href="#rfc.xref.Part1.7">2</a>, <a class="iref" href="#rfc.xref.Part1.8">4.1</a>, <a class="iref" href="#rfc.xref.Part1.9">4.2</a>, <a class="iref" href="#rfc.xref.Part1.10">4.2.2</a>, <a class="iref" href="#Part1"><b>10.1</b></a>, <a class="iref" href="#rfc.xref.Part1.11">A.5</a>, <a class="iref" href="#rfc.xref.Part1.12">C.1</a><ul class="ind"> 1670 <li class="indline1"><em>Section 2.1</em> <a class="iref" href="#rfc.xref.Part1.1">2</a></li> 1671 <li class="indline1"><em>Section 2.2</em> <a class="iref" href="#rfc.xref.Part1.2">2</a>, <a class="iref" href="#rfc.xref.Part1.3">2</a>, <a class="iref" href="#rfc.xref.Part1.4">2</a>, <a class="iref" href="#rfc.xref.Part1.5">2</a>, <a class="iref" href="#rfc.xref.Part1.6">2</a>, <a class="iref" href="#rfc.xref.Part1.7">2</a></li> 1672 <li class="indline1"><em>Section 4.3</em> <a class="iref" href="#rfc.xref.Part1.9">4.2</a></li> 1673 <li class="indline1"><em>Section 4.4</em> <a class="iref" href="#rfc.xref.Part1.10">4.2.2</a></li> 1674 <li class="indline1"><em>Section 8.2</em> <a class="iref" href="#rfc.xref.Part1.8">4.1</a></li> 1675 <li class="indline1"><em>Section 8.7</em> <a class="iref" href="#rfc.xref.Part1.11">A.5</a></li> 1659 1676 </ul> 1660 1677 </li> 1661 <li class="indline1"><em>Part2</em> <a class="iref" href="#rfc.xref.Part2.1"> 3.1</a>, <a class="iref" href="#rfc.xref.Part2.2">4.1</a>, <a class="iref" href="#Part2"><b>9.1</b></a><ul class="ind">1662 <li class="indline1"><em>Section 9.1</em> <a class="iref" href="#rfc.xref.Part2.1">3.1</a></li>1663 <li class="indline1"><em>Section 9.9</em> <a class="iref" href="#rfc.xref.Part2.2">4.1</a></li>1678 <li class="indline1"><em>Part2</em> <a class="iref" href="#rfc.xref.Part2.1">4.1</a>, <a class="iref" href="#rfc.xref.Part2.2">5.1</a>, <a class="iref" href="#Part2"><b>10.1</b></a><ul class="ind"> 1679 <li class="indline1"><em>Section 10.1</em> <a class="iref" href="#rfc.xref.Part2.1">4.1</a></li> 1680 <li class="indline1"><em>Section 10.9</em> <a class="iref" href="#rfc.xref.Part2.2">5.1</a></li> 1664 1681 </ul> 1665 1682 </li> 1666 <li class="indline1"><em>Part4</em> <a class="iref" href="#rfc.xref.Part4.1"> 3.1</a>, <a class="iref" href="#Part4"><b>9.1</b></a><ul class="ind">1667 <li class="indline1"><em>Section 6.6</em> <a class="iref" href="#rfc.xref.Part4.1">3.1</a></li>1683 <li class="indline1"><em>Part4</em> <a class="iref" href="#rfc.xref.Part4.1">4.1</a>, <a class="iref" href="#Part4"><b>10.1</b></a><ul class="ind"> 1684 <li class="indline1"><em>Section 7.6</em> <a class="iref" href="#rfc.xref.Part4.1">4.1</a></li> 1668 1685 </ul> 1669 1686 </li> 1670 <li class="indline1"><em>Part5</em> <a class="iref" href="#rfc.xref.Part5.1"> 2.3.2</a>, <a class="iref" href="#rfc.xref.Part5.2">3.1</a>, <a class="iref" href="#Part5"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.Part5.3">C.1</a><ul class="ind">1671 <li class="indline1"><em>Section 5.2</em> <a class="iref" href="#rfc.xref.Part5.2">3.1</a></li>1672 <li class="indline1"><em>Section A</em> <a class="iref" href="#rfc.xref.Part5.1"> 2.3.2</a></li>1687 <li class="indline1"><em>Part5</em> <a class="iref" href="#rfc.xref.Part5.1">3.3.2</a>, <a class="iref" href="#rfc.xref.Part5.2">4.1</a>, <a class="iref" href="#Part5"><b>10.1</b></a>, <a class="iref" href="#rfc.xref.Part5.3">C.1</a><ul class="ind"> 1688 <li class="indline1"><em>Section 6.2</em> <a class="iref" href="#rfc.xref.Part5.2">4.1</a></li> 1689 <li class="indline1"><em>Section A</em> <a class="iref" href="#rfc.xref.Part5.1">3.3.2</a></li> 1673 1690 </ul> 1674 1691 </li> 1675 <li class="indline1"><em>Part6</em> <a class="iref" href="#rfc.xref.Part6.1"> 3.1</a>, <a class="iref" href="#rfc.xref.Part6.2">4.1</a>, <a class="iref" href="#rfc.xref.Part6.3">5.7</a>, <a class="iref" href="#Part6"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.Part6.4">C.1</a><ul class="ind">1676 <li class="indline1"><em>Section 7</em> <a class="iref" href="#rfc.xref.Part6.3">5.7</a></li>1677 <li class="indline1"><em>Section 1 5.3</em> <a class="iref" href="#rfc.xref.Part6.1">3.1</a></li>1678 <li class="indline1"><em>Section 1 5.5</em> <a class="iref" href="#rfc.xref.Part6.2">4.1</a></li>1692 <li class="indline1"><em>Part6</em> <a class="iref" href="#rfc.xref.Part6.1">4.1</a>, <a class="iref" href="#rfc.xref.Part6.2">5.1</a>, <a class="iref" href="#rfc.xref.Part6.3">6.7</a>, <a class="iref" href="#Part6"><b>10.1</b></a>, <a class="iref" href="#rfc.xref.Part6.4">C.1</a><ul class="ind"> 1693 <li class="indline1"><em>Section 8</em> <a class="iref" href="#rfc.xref.Part6.3">6.7</a></li> 1694 <li class="indline1"><em>Section 16.3</em> <a class="iref" href="#rfc.xref.Part6.1">4.1</a></li> 1695 <li class="indline1"><em>Section 16.5</em> <a class="iref" href="#rfc.xref.Part6.2">5.1</a></li> 1679 1696 </ul> 1680 1697 </li> … … 1683 1700 </li> 1684 1701 <li class="indline0"><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul class="ind"> 1685 <li class="indline1"><em>RFC1766</em> <a class="iref" href="#rfc.xref.RFC1766.1"> 2.5</a>, <a class="iref" href="#RFC1766"><b>9.1</b></a></li>1686 <li class="indline1"><em>RFC1806</em> <a class="iref" href="#rfc.xref.RFC1806.1"> 7.2</a>, <a class="iref" href="#rfc.xref.RFC1806.2">7.2</a>, <a class="iref" href="#RFC1806"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.RFC1806.3">B.1</a></li>1687 <li class="indline1"><em>RFC1864</em> <a class="iref" href="#rfc.xref.RFC1864.1"> 5.8</a>, <a class="iref" href="#rfc.xref.RFC1864.2">5.8</a>, <a class="iref" href="#RFC1864"><b>9.1</b></a></li>1688 <li class="indline1"><em>RFC1945</em> <a class="iref" href="#RFC1945"><b> 9.2</b></a>, <a class="iref" href="#rfc.xref.RFC1945.1">B</a></li>1689 <li class="indline1"><em>RFC1950</em> <a class="iref" href="#rfc.xref.RFC1950.1"> 2.2</a>, <a class="iref" href="#RFC1950"><b>9.1</b></a></li>1690 <li class="indline1"><em>RFC1951</em> <a class="iref" href="#rfc.xref.RFC1951.1"> 2.2</a>, <a class="iref" href="#RFC1951"><b>9.1</b></a></li>1691 <li class="indline1"><em>RFC1952</em> <a class="iref" href="#rfc.xref.RFC1952.1"> 2.2</a>, <a class="iref" href="#RFC1952"><b>9.1</b></a></li>1692 <li class="indline1"><em>RFC2045</em> <a class="iref" href="#RFC2045"><b> 9.1</b></a>, <a class="iref" href="#rfc.xref.RFC2045.1">A</a>, <a class="iref" href="#rfc.xref.RFC2045.2">A.1</a>, <a class="iref" href="#rfc.xref.RFC2045.3">A.2</a></li>1693 <li class="indline1"><em>RFC2046</em> <a class="iref" href="#rfc.xref.RFC2046.1"> 2.3</a>, <a class="iref" href="#rfc.xref.RFC2046.2">2.3.2</a>, <a class="iref" href="#RFC2046"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.RFC2046.3">A.2</a><ul class="ind">1694 <li class="indline1"><em>Section 5.1.1</em> <a class="iref" href="#rfc.xref.RFC2046.2"> 2.3.2</a></li>1702 <li class="indline1"><em>RFC1766</em> <a class="iref" href="#rfc.xref.RFC1766.1">3.5</a>, <a class="iref" href="#RFC1766"><b>10.1</b></a></li> 1703 <li class="indline1"><em>RFC1806</em> <a class="iref" href="#rfc.xref.RFC1806.1">8.2</a>, <a class="iref" href="#rfc.xref.RFC1806.2">8.2</a>, <a class="iref" href="#RFC1806"><b>10.2</b></a>, <a class="iref" href="#rfc.xref.RFC1806.3">B.1</a></li> 1704 <li class="indline1"><em>RFC1864</em> <a class="iref" href="#rfc.xref.RFC1864.1">6.8</a>, <a class="iref" href="#rfc.xref.RFC1864.2">6.8</a>, <a class="iref" href="#RFC1864"><b>10.1</b></a></li> 1705 <li class="indline1"><em>RFC1945</em> <a class="iref" href="#RFC1945"><b>10.2</b></a>, <a class="iref" href="#rfc.xref.RFC1945.1">B</a></li> 1706 <li class="indline1"><em>RFC1950</em> <a class="iref" href="#rfc.xref.RFC1950.1">3.2</a>, <a class="iref" href="#RFC1950"><b>10.1</b></a></li> 1707 <li class="indline1"><em>RFC1951</em> <a class="iref" href="#rfc.xref.RFC1951.1">3.2</a>, <a class="iref" href="#RFC1951"><b>10.1</b></a></li> 1708 <li class="indline1"><em>RFC1952</em> <a class="iref" href="#rfc.xref.RFC1952.1">3.2</a>, <a class="iref" href="#RFC1952"><b>10.1</b></a></li> 1709 <li class="indline1"><em>RFC2045</em> <a class="iref" href="#RFC2045"><b>10.1</b></a>, <a class="iref" href="#rfc.xref.RFC2045.1">A</a>, <a class="iref" href="#rfc.xref.RFC2045.2">A.1</a>, <a class="iref" href="#rfc.xref.RFC2045.3">A.2</a></li> 1710 <li class="indline1"><em>RFC2046</em> <a class="iref" href="#rfc.xref.RFC2046.1">3.3</a>, <a class="iref" href="#rfc.xref.RFC2046.2">3.3.2</a>, <a class="iref" href="#RFC2046"><b>10.1</b></a>, <a class="iref" href="#rfc.xref.RFC2046.3">A.2</a><ul class="ind"> 1711 <li class="indline1"><em>Section 5.1.1</em> <a class="iref" href="#rfc.xref.RFC2046.2">3.3.2</a></li> 1695 1712 </ul> 1696 1713 </li> 1697 <li class="indline1"><em>RFC2049</em> <a class="iref" href="#RFC2049"><b> 9.2</b></a>, <a class="iref" href="#rfc.xref.RFC2049.1">A.2</a><ul class="ind">1714 <li class="indline1"><em>RFC2049</em> <a class="iref" href="#RFC2049"><b>10.2</b></a>, <a class="iref" href="#rfc.xref.RFC2049.1">A.2</a><ul class="ind"> 1698 1715 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.RFC2049.1">A.2</a></li> 1699 1716 </ul> 1700 1717 </li> 1701 <li class="indline1"><em>RFC2068</em> <a class="iref" href="#rfc.xref.RFC2068.1">§</a>, <a class="iref" href="#rfc.xref.RFC2068.2">§</a>, <a class="iref" href="#rfc.xref.RFC2068.3">§</a>, <a class="iref" href="#RFC2068"><b> 9.2</b></a>, <a class="iref" href="#rfc.xref.RFC2068.4">B</a>, <a class="iref" href="#rfc.xref.RFC2068.5">C.1</a></li>1702 <li class="indline1"><em>RFC2076</em> <a class="iref" href="#RFC2076"><b> 9.2</b></a>, <a class="iref" href="#rfc.xref.RFC2076.1">B</a></li>1703 <li class="indline1"><em>RFC2119</em> <a class="iref" href="#rfc.xref.RFC2119.1">1.1</a>, <a class="iref" href="#RFC2119"><b> 9.1</b></a></li>1704 <li class="indline1"><em>RFC2183</em> <a class="iref" href="#rfc.xref.RFC2183.1"> 7.2</a>, <a class="iref" href="#RFC2183"><b>9.2</b></a></li>1705 <li class="indline1"><em>RFC2277</em> <a class="iref" href="#rfc.xref.RFC2277.1"> 2.1</a>, <a class="iref" href="#RFC2277"><b>9.2</b></a></li>1706 <li class="indline1"><em>RFC2388</em> <a class="iref" href="#rfc.xref.RFC2388.1"> 2.3.2</a>, <a class="iref" href="#RFC2388"><b>9.2</b></a></li>1707 <li class="indline1"><em>RFC2557</em> <a class="iref" href="#RFC2557"><b> 9.2</b></a>, <a class="iref" href="#rfc.xref.RFC2557.1">A.6</a>, <a class="iref" href="#rfc.xref.RFC2557.2">C.1</a></li>1708 <li class="indline1"><em>RFC2616</em> <a class="iref" href="#rfc.xref.RFC2616.1">1</a>, <a class="iref" href="#RFC2616"><b> 9.2</b></a>, <a class="iref" href="#rfc.xref.RFC2616.2">D.1</a></li>1709 <li class="indline1"><em>RFC2822</em> <a class="iref" href="#RFC2822"><b> 9.2</b></a>, <a class="iref" href="#rfc.xref.RFC2822.1">A</a></li>1710 <li class="indline1"><em>RFC3629</em> <a class="iref" href="#rfc.xref.RFC3629.1"> 2.1</a>, <a class="iref" href="#RFC3629"><b>9.2</b></a></li>1711 <li class="indline1"><em>RFC4288</em> <a class="iref" href="#rfc.xref.RFC4288.1"> 2.3</a>, <a class="iref" href="#RFC4288"><b>9.2</b></a></li>1718 <li class="indline1"><em>RFC2068</em> <a class="iref" href="#rfc.xref.RFC2068.1">§</a>, <a class="iref" href="#rfc.xref.RFC2068.2">§</a>, <a class="iref" href="#rfc.xref.RFC2068.3">§</a>, <a class="iref" href="#RFC2068"><b>10.2</b></a>, <a class="iref" href="#rfc.xref.RFC2068.4">B</a>, <a class="iref" href="#rfc.xref.RFC2068.5">C.1</a></li> 1719 <li class="indline1"><em>RFC2076</em> <a class="iref" href="#RFC2076"><b>10.2</b></a>, <a class="iref" href="#rfc.xref.RFC2076.1">B</a></li> 1720 <li class="indline1"><em>RFC2119</em> <a class="iref" href="#rfc.xref.RFC2119.1">1.1</a>, <a class="iref" href="#RFC2119"><b>10.1</b></a></li> 1721 <li class="indline1"><em>RFC2183</em> <a class="iref" href="#rfc.xref.RFC2183.1">8.2</a>, <a class="iref" href="#RFC2183"><b>10.2</b></a></li> 1722 <li class="indline1"><em>RFC2277</em> <a class="iref" href="#rfc.xref.RFC2277.1">3.1</a>, <a class="iref" href="#RFC2277"><b>10.2</b></a></li> 1723 <li class="indline1"><em>RFC2388</em> <a class="iref" href="#rfc.xref.RFC2388.1">3.3.2</a>, <a class="iref" href="#RFC2388"><b>10.2</b></a></li> 1724 <li class="indline1"><em>RFC2557</em> <a class="iref" href="#RFC2557"><b>10.2</b></a>, <a class="iref" href="#rfc.xref.RFC2557.1">A.6</a>, <a class="iref" href="#rfc.xref.RFC2557.2">C.1</a></li> 1725 <li class="indline1"><em>RFC2616</em> <a class="iref" href="#rfc.xref.RFC2616.1">1</a>, <a class="iref" href="#RFC2616"><b>10.2</b></a>, <a class="iref" href="#rfc.xref.RFC2616.2">D.1</a></li> 1726 <li class="indline1"><em>RFC2822</em> <a class="iref" href="#RFC2822"><b>10.2</b></a>, <a class="iref" href="#rfc.xref.RFC2822.1">A</a></li> 1727 <li class="indline1"><em>RFC3629</em> <a class="iref" href="#rfc.xref.RFC3629.1">3.1</a>, <a class="iref" href="#RFC3629"><b>10.2</b></a></li> 1728 <li class="indline1"><em>RFC4288</em> <a class="iref" href="#rfc.xref.RFC4288.1">3.3</a>, <a class="iref" href="#RFC4288"><b>10.2</b></a></li> 1712 1729 </ul> 1713 1730 </li>
Note: See TracChangeset
for help on using the changeset viewer.