Ignore:
Timestamp:
14/06/14 11:20:37 (6 years ago)
Author:
julian.reschke@…
Message:

update to latest version of rfc2629.xslt, regen all HTML

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/14/p3-payload.html

    r1271 r2726  
    22  PUBLIC "-//W3C//DTD HTML 4.01//EN">
    33<html lang="en">
    4    <head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/">
     4   <head profile="http://dublincore.org/documents/2008/08/04/dc-html/">
    55      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    66      <title>HTTP/1.1, part 3: Message Payload and Content Negotiation</title><style type="text/css" title="Xml2Rfc (sans serif)">
     
    2424body {
    2525  color: black;
    26   font-family: verdana, helvetica, arial, sans-serif;
    27   font-size: 10pt;
     26  font-family: cambria, helvetica, arial, sans-serif;
     27  font-size: 11pt;
     28  margin-right: 2em;
    2829}
    2930cite {
     
    3334  margin-left: 2em;
    3435}
    35 dd {
    36   margin-right: 2em;
    37 }
    3836dl {
    3937  margin-left: 2em;
    4038}
    41 
    4239ul.empty {
    4340  list-style-type: none;
     
    5350}
    5451h1 {
    55   font-size: 14pt;
     52  font-size: 130%;
    5653  line-height: 21pt;
    5754  page-break-after: avoid;
     
    6057  page-break-before: always;
    6158}
    62 h1 a {
    63   color: #333333;
    64 }
    6559h2 {
    66   font-size: 12pt;
     60  font-size: 120%;
    6761  line-height: 15pt;
    6862  page-break-after: avoid;
    6963}
    70 h3, h4, h5, h6 {
    71   font-size: 10pt;
     64h3 {
     65  font-size: 110%;
    7266  page-break-after: avoid;
    7367}
    74 h2 a, h3 a, h4 a, h5 a, h6 a {
     68h4, h5, h6 {
     69  page-break-after: avoid;
     70}
     71h1 a, h2 a, h3 a, h4 a, h5 a, h6 a {
    7572  color: black;
    7673}
     
    8077li {
    8178  margin-left: 2em;
    82   margin-right: 2em;
    8379}
    8480ol {
    8581  margin-left: 2em;
    86   margin-right: 2em;
    8782}
    8883ol.la {
     
    9792p {
    9893  margin-left: 2em;
    99   margin-right: 2em;
    10094}
    10195pre {
     
    10397  background-color: lightyellow;
    10498  padding: .25em;
     99  page-break-inside: avoid;
    105100}
    106101pre.text2 {
     
    131126table.tt {
    132127  vertical-align: top;
     128  border-color: gray;
     129}
     130table.tt th {
     131  border-color: gray;
     132}
     133table.tt td {
     134  border-color: gray;
     135}
     136table.all {
     137  border-style: solid;
     138  border-width: 2px;
    133139}
    134140table.full {
    135   border-style: outset;
    136   border-width: 1px;
    137 }
    138 table.headers {
    139   border-style: outset;
    140   border-width: 1px;
     141  border-style: solid;
     142  border-width: 2px;
    141143}
    142144table.tt td {
    143145  vertical-align: top;
    144146}
     147table.all td {
     148  border-style: solid;
     149  border-width: 1px;
     150}
    145151table.full td {
    146   border-style: inset;
     152  border-style: none solid;
    147153  border-width: 1px;
    148154}
     
    150156  vertical-align: top;
    151157}
     158table.all th {
     159  border-style: solid;
     160  border-width: 1px;
     161}
    152162table.full th {
    153   border-style: inset;
    154   border-width: 1px;
     163  border-style: solid;
     164  border-width: 1px 1px 2px 1px;
    155165}
    156166table.headers th {
    157   border-style: none none inset none;
    158   border-width: 1px;
     167  border-style: none none solid none;
     168  border-width: 2px;
    159169}
    160170table.left {
     
    171181  caption-side: bottom;
    172182  font-weight: bold;
    173   font-size: 9pt;
     183  font-size: 10pt;
    174184  margin-top: .5em;
    175185}
     
    178188  border-spacing: 1px;
    179189  width: 95%;
    180   font-size: 10pt;
     190  font-size: 11pt;
    181191  color: white;
    182192}
     
    186196td.topnowrap {
    187197  vertical-align: top;
    188   white-space: nowrap; 
     198  white-space: nowrap;
    189199}
    190200table.header td {
     
    206216  list-style: none;
    207217  margin-left: 1.5em;
    208   margin-right: 0em;
    209218  padding-left: 0em;
    210219}
     
    212221  line-height: 150%;
    213222  font-weight: bold;
    214   font-size: 10pt;
    215223  margin-left: 0em;
    216   margin-right: 0em;
    217224}
    218225ul.toc li li {
    219226  line-height: normal;
    220227  font-weight: normal;
    221   font-size: 9pt;
     228  font-size: 10pt;
    222229  margin-left: 0em;
    223   margin-right: 0em;
    224230}
    225231li.excluded {
     
    228234ul p {
    229235  margin-left: 0em;
     236}
     237.title, .filename, h1, h2, h3, h4 {
     238  font-family: candara, helvetica, arial, sans-serif;
     239}
     240samp, tt, code, pre {
     241  font: consolas, monospace;
    230242}
    231243ul.ind, ul.ind ul {
    232244  list-style: none;
    233245  margin-left: 1.5em;
    234   margin-right: 0em;
    235246  padding-left: 0em;
    236247  page-break-before: avoid;
     
    240251  line-height: 200%;
    241252  margin-left: 0em;
    242   margin-right: 0em;
    243253}
    244254ul.ind li li {
     
    246256  line-height: 150%;
    247257  margin-left: 0em;
    248   margin-right: 0em;
    249258}
    250259.avoidbreak {
     
    270279  font-weight: bold;
    271280  text-align: center;
    272   font-size: 9pt;
     281  font-size: 10pt;
    273282}
    274283.filename {
    275284  color: #333333;
     285  font-size: 75%;
    276286  font-weight: bold;
    277   font-size: 12pt;
    278287  line-height: 21pt;
    279288  text-align: center;
     
    282291  font-weight: bold;
    283292}
    284 .hidden {
    285   display: none;
    286 }
    287293.left {
    288294  text-align: left;
     
    292298}
    293299.title {
    294   color: #990000;
    295   font-size: 18pt;
     300  color: green;
     301  font-size: 150%;
    296302  line-height: 18pt;
    297303  font-weight: bold;
     
    299305  margin-top: 36pt;
    300306}
    301 .vcardline {
    302   display: block;
    303 }
    304307.warning {
    305   font-size: 14pt;
     308  font-size: 130%;
    306309  background-color: yellow;
    307310}
     
    312315    display: none;
    313316  }
    314  
     317
    315318  a {
    316319    color: black;
     
    327330    background-color: white;
    328331    vertical-align: top;
    329     font-size: 12pt;
     332    font-size: 110%;
    330333  }
    331334
    332   ul.toc a::after {
     335  ul.toc a:nth-child(2)::after {
    333336    content: leader('.') target-counter(attr(href), page);
    334337  }
    335  
     338
    336339  ul.ind li li a {
    337340    content: target-counter(attr(href), page);
    338341  }
    339  
     342
    340343  .print2col {
    341344    column-count: 2;
     
    347350@page {
    348351  @top-left {
    349        content: "Internet-Draft"; 
    350   } 
     352       content: "Internet-Draft";
     353  }
    351354  @top-right {
    352        content: "April 2011"; 
    353   } 
     355       content: "April 2011";
     356  }
    354357  @top-center {
    355        content: "HTTP/1.1, Part 3"; 
    356   } 
     358       content: "HTTP/1.1, Part 3";
     359  }
    357360  @bottom-left {
    358        content: "Fielding, et al."; 
    359   } 
     361       content: "Fielding, et al.";
     362  }
    360363  @bottom-center {
    361        content: "Expires October 20, 2011"; 
    362   } 
     364       content: "Expires October 20, 2011";
     365  }
    363366  @bottom-right {
    364        content: "[Page " counter(page) "]"; 
    365   } 
     367       content: "[Page " counter(page) "]";
     368  }
    366369}
    367370
    368 @page:first { 
     371@page:first {
    369372    @top-left {
    370373      content: normal;
     
    396399      <link rel="Appendix" title="D Collected ABNF" href="#rfc.section.D">
    397400      <link rel="Appendix" title="E Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.E">
    398       <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.543, 2011-02-18 21:03:40, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
     401      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.640, 2014/06/13 12:42:58, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
    399402      <link rel="schema.dct" href="http://purl.org/dc/terms/">
    400403      <meta name="dct.creator" content="Fielding, R.">
     
    425428            </tr>
    426429            <tr>
    427                <td class="left">Obsoletes: <a href="http://tools.ietf.org/html/rfc2616">2616</a> (if approved)
     430               <td class="left">Obsoletes: <a href="https://tools.ietf.org/html/rfc2616">2616</a> (if approved)
    428431               </td>
    429432               <td class="right">J. Gettys</td>
     
    496499      </table>
    497500      <p class="title">HTTP/1.1, part 3: Message Payload and Content Negotiation<br><span class="filename">draft-ietf-httpbis-p3-payload-14</span></p>
    498       <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1> 
     501      <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
    499502      <p>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information
    500503         systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 3 of the
    501504         seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part
    502505         3 defines HTTP message content, metadata, and content negotiation.
    503       </p> 
    504       <h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note (To be removed by RFC Editor)</a></h1> 
     506      </p>
     507      <h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note (To be removed by RFC Editor)</a></h1>
    505508      <p>Discussion of this draft should take place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org), which is archived
    506509         at &lt;<a href="http://lists.w3.org/Archives/Public/ietf-http-wg/">http://lists.w3.org/Archives/Public/ietf-http-wg/</a>&gt;.
    507       </p> 
     510      </p>
    508511      <p>The current issues list is at &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/report/3">http://tools.ietf.org/wg/httpbis/trac/report/3</a>&gt; and related documents (including fancy diffs) can be found at &lt;<a href="http://tools.ietf.org/wg/httpbis/">http://tools.ietf.org/wg/httpbis/</a>&gt;.
    509       </p> 
     512      </p>
    510513      <p>The changes in this draft are summarized in <a href="#changes.since.13" title="Since draft-ietf-httpbis-p3-payload-13">Appendix&nbsp;E.15</a>.
    511       </p>
    512       <h1><a id="rfc.status" href="#rfc.status">Status of This Memo</a></h1>
    513       <p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
    514       <p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute
    515          working documents as Internet-Drafts. The list of current Internet-Drafts is at <a href="http://datatracker.ietf.org/drafts/current/">http://datatracker.ietf.org/drafts/current/</a>.
    516514      </p>
    517       <p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other
    518          documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work
    519          in progress”.
    520       </p>
    521       <p>This Internet-Draft will expire on October 20, 2011.</p>
    522       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    523       <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    524       <p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights
    525          and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License
    526          text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified
    527          BSD License.
    528       </p>
    529       <p>This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November
    530          10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to
    531          allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s)
    532          controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative
    533          works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate
    534          it into languages other than English.
    535       </p>
     515      <div id="rfc.status">
     516         <h1><a href="#rfc.status">Status of This Memo</a></h1>
     517         <p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
     518         <p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute
     519            working documents as Internet-Drafts. The list of current Internet-Drafts is at <a href="http://datatracker.ietf.org/drafts/current/">http://datatracker.ietf.org/drafts/current/</a>.
     520         </p>
     521         <p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other
     522            documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work
     523            in progress”.
     524         </p>
     525         <p>This Internet-Draft will expire on October 20, 2011.</p>
     526      </div>
     527      <div id="rfc.copyrightnotice">
     528         <h1><a href="#rfc.copyrightnotice">Copyright Notice</a></h1>
     529         <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     530         <p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights
     531            and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License
     532            text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified
     533            BSD License.
     534         </p>
     535         <p>This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November
     536            10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to
     537            allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s)
     538            controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative
     539            works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate
     540            it into languages other than English.
     541         </p>
     542      </div>
    536543      <hr class="noprint">
    537544      <h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
    538545      <ul class="toc">
    539          <li>1.&nbsp;&nbsp;&nbsp;<a href="#introduction">Introduction</a><ul>
    540                <li>1.1&nbsp;&nbsp;&nbsp;<a href="#terminology">Terminology</a></li>
    541                <li>1.2&nbsp;&nbsp;&nbsp;<a href="#intro.requirements">Requirements</a></li>
    542                <li>1.3&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a><ul>
    543                      <li>1.3.1&nbsp;&nbsp;&nbsp;<a href="#core.rules">Core Rules</a></li>
    544                      <li>1.3.2&nbsp;&nbsp;&nbsp;<a href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></li>
     546         <li><a href="#rfc.section.1">1.</a>&nbsp;&nbsp;&nbsp;<a href="#introduction">Introduction</a><ul>
     547               <li><a href="#rfc.section.1.1">1.1</a>&nbsp;&nbsp;&nbsp;<a href="#terminology">Terminology</a></li>
     548               <li><a href="#rfc.section.1.2">1.2</a>&nbsp;&nbsp;&nbsp;<a href="#intro.requirements">Requirements</a></li>
     549               <li><a href="#rfc.section.1.3">1.3</a>&nbsp;&nbsp;&nbsp;<a href="#notation">Syntax Notation</a><ul>
     550                     <li><a href="#rfc.section.1.3.1">1.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#core.rules">Core Rules</a></li>
     551                     <li><a href="#rfc.section.1.3.2">1.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></li>
    545552                  </ul>
    546553               </li>
    547554            </ul>
    548555         </li>
    549          <li>2.&nbsp;&nbsp;&nbsp;<a href="#protocol.parameters">Protocol Parameters</a><ul>
    550                <li>2.1&nbsp;&nbsp;&nbsp;<a href="#character.sets">Character Encodings (charset)</a></li>
    551                <li>2.2&nbsp;&nbsp;&nbsp;<a href="#content.codings">Content Codings</a><ul>
    552                      <li>2.2.1&nbsp;&nbsp;&nbsp;<a href="#content.coding.registry">Content Coding Registry</a></li>
     556         <li><a href="#rfc.section.2">2.</a>&nbsp;&nbsp;&nbsp;<a href="#protocol.parameters">Protocol Parameters</a><ul>
     557               <li><a href="#rfc.section.2.1">2.1</a>&nbsp;&nbsp;&nbsp;<a href="#character.sets">Character Encodings (charset)</a></li>
     558               <li><a href="#rfc.section.2.2">2.2</a>&nbsp;&nbsp;&nbsp;<a href="#content.codings">Content Codings</a><ul>
     559                     <li><a href="#rfc.section.2.2.1">2.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#content.coding.registry">Content Coding Registry</a></li>
    553560                  </ul>
    554561               </li>
    555                <li>2.3&nbsp;&nbsp;&nbsp;<a href="#media.types">Media Types</a><ul>
    556                      <li>2.3.1&nbsp;&nbsp;&nbsp;<a href="#canonicalization.and.text.defaults">Canonicalization and Text Defaults</a></li>
    557                      <li>2.3.2&nbsp;&nbsp;&nbsp;<a href="#multipart.types">Multipart Types</a></li>
     562               <li><a href="#rfc.section.2.3">2.3</a>&nbsp;&nbsp;&nbsp;<a href="#media.types">Media Types</a><ul>
     563                     <li><a href="#rfc.section.2.3.1">2.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#canonicalization.and.text.defaults">Canonicalization and Text Defaults</a></li>
     564                     <li><a href="#rfc.section.2.3.2">2.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#multipart.types">Multipart Types</a></li>
    558565                  </ul>
    559566               </li>
    560                <li>2.4&nbsp;&nbsp;&nbsp;<a href="#language.tags">Language Tags</a></li>
     567               <li><a href="#rfc.section.2.4">2.4</a>&nbsp;&nbsp;&nbsp;<a href="#language.tags">Language Tags</a></li>
    561568            </ul>
    562569         </li>
    563          <li>3.&nbsp;&nbsp;&nbsp;<a href="#payload">Payload</a><ul>
    564                <li>3.1&nbsp;&nbsp;&nbsp;<a href="#payload.header.fields">Payload Header Fields</a></li>
    565                <li>3.2&nbsp;&nbsp;&nbsp;<a href="#payload.body">Payload Body</a></li>
     570         <li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#payload">Payload</a><ul>
     571               <li><a href="#rfc.section.3.1">3.1</a>&nbsp;&nbsp;&nbsp;<a href="#payload.header.fields">Payload Header Fields</a></li>
     572               <li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#payload.body">Payload Body</a></li>
    566573            </ul>
    567574         </li>
    568          <li>4.&nbsp;&nbsp;&nbsp;<a href="#representation">Representation</a><ul>
    569                <li>4.1&nbsp;&nbsp;&nbsp;<a href="#representation.header.fields">Representation Header Fields</a></li>
    570                <li>4.2&nbsp;&nbsp;&nbsp;<a href="#representation.data">Representation Data</a></li>
     575         <li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#representation">Representation</a><ul>
     576               <li><a href="#rfc.section.4.1">4.1</a>&nbsp;&nbsp;&nbsp;<a href="#representation.header.fields">Representation Header Fields</a></li>
     577               <li><a href="#rfc.section.4.2">4.2</a>&nbsp;&nbsp;&nbsp;<a href="#representation.data">Representation Data</a></li>
    571578            </ul>
    572579         </li>
    573          <li>5.&nbsp;&nbsp;&nbsp;<a href="#content.negotiation">Content Negotiation</a><ul>
    574                <li>5.1&nbsp;&nbsp;&nbsp;<a href="#server-driven.negotiation">Server-driven Negotiation</a></li>
    575                <li>5.2&nbsp;&nbsp;&nbsp;<a href="#agent-driven.negotiation">Agent-driven Negotiation</a></li>
     580         <li><a href="#rfc.section.5">5.</a>&nbsp;&nbsp;&nbsp;<a href="#content.negotiation">Content Negotiation</a><ul>
     581               <li><a href="#rfc.section.5.1">5.1</a>&nbsp;&nbsp;&nbsp;<a href="#server-driven.negotiation">Server-driven Negotiation</a></li>
     582               <li><a href="#rfc.section.5.2">5.2</a>&nbsp;&nbsp;&nbsp;<a href="#agent-driven.negotiation">Agent-driven Negotiation</a></li>
    576583            </ul>
    577584         </li>
    578          <li>6.&nbsp;&nbsp;&nbsp;<a href="#header.fields">Header Field Definitions</a><ul>
    579                <li>6.1&nbsp;&nbsp;&nbsp;<a href="#header.accept">Accept</a></li>
    580                <li>6.2&nbsp;&nbsp;&nbsp;<a href="#header.accept-charset">Accept-Charset</a></li>
    581                <li>6.3&nbsp;&nbsp;&nbsp;<a href="#header.accept-encoding">Accept-Encoding</a></li>
    582                <li>6.4&nbsp;&nbsp;&nbsp;<a href="#header.accept-language">Accept-Language</a></li>
    583                <li>6.5&nbsp;&nbsp;&nbsp;<a href="#header.content-encoding">Content-Encoding</a></li>
    584                <li>6.6&nbsp;&nbsp;&nbsp;<a href="#header.content-language">Content-Language</a></li>
    585                <li>6.7&nbsp;&nbsp;&nbsp;<a href="#header.content-location">Content-Location</a></li>
    586                <li>6.8&nbsp;&nbsp;&nbsp;<a href="#header.content-type">Content-Type</a></li>
     585         <li><a href="#rfc.section.6">6.</a>&nbsp;&nbsp;&nbsp;<a href="#header.fields">Header Field Definitions</a><ul>
     586               <li><a href="#rfc.section.6.1">6.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.accept">Accept</a></li>
     587               <li><a href="#rfc.section.6.2">6.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.accept-charset">Accept-Charset</a></li>
     588               <li><a href="#rfc.section.6.3">6.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.accept-encoding">Accept-Encoding</a></li>
     589               <li><a href="#rfc.section.6.4">6.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.accept-language">Accept-Language</a></li>
     590               <li><a href="#rfc.section.6.5">6.5</a>&nbsp;&nbsp;&nbsp;<a href="#header.content-encoding">Content-Encoding</a></li>
     591               <li><a href="#rfc.section.6.6">6.6</a>&nbsp;&nbsp;&nbsp;<a href="#header.content-language">Content-Language</a></li>
     592               <li><a href="#rfc.section.6.7">6.7</a>&nbsp;&nbsp;&nbsp;<a href="#header.content-location">Content-Location</a></li>
     593               <li><a href="#rfc.section.6.8">6.8</a>&nbsp;&nbsp;&nbsp;<a href="#header.content-type">Content-Type</a></li>
    587594            </ul>
    588595         </li>
    589          <li>7.&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul>
    590                <li>7.1&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li>
    591                <li>7.2&nbsp;&nbsp;&nbsp;<a href="#content.coding.registration">Content Coding Registry</a></li>
     596         <li><a href="#rfc.section.7">7.</a>&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul>
     597               <li><a href="#rfc.section.7.1">7.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li>
     598               <li><a href="#rfc.section.7.2">7.2</a>&nbsp;&nbsp;&nbsp;<a href="#content.coding.registration">Content Coding Registry</a></li>
    592599            </ul>
    593600         </li>
    594          <li>8.&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul>
    595                <li>8.1&nbsp;&nbsp;&nbsp;<a href="#privacy.issues.connected.to.accept.header.fields">Privacy Issues Connected to Accept Header Fields</a></li>
     601         <li><a href="#rfc.section.8">8.</a>&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul>
     602               <li><a href="#rfc.section.8.1">8.1</a>&nbsp;&nbsp;&nbsp;<a href="#privacy.issues.connected.to.accept.header.fields">Privacy Issues Connected to Accept Header Fields</a></li>
    596603            </ul>
    597604         </li>
    598          <li>9.&nbsp;&nbsp;&nbsp;<a href="#ack">Acknowledgments</a></li>
    599          <li>10.&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul>
    600                <li>10.1&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li>
    601                <li>10.2&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li>
     605         <li><a href="#rfc.section.9">9.</a>&nbsp;&nbsp;&nbsp;<a href="#ack">Acknowledgments</a></li>
     606         <li><a href="#rfc.section.10">10.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul>
     607               <li><a href="#rfc.section.10.1">10.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li>
     608               <li><a href="#rfc.section.10.2">10.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li>
    602609            </ul>
    603610         </li>
    604          <li><a href="#rfc.authors">Authors' Addresses</a></li>
    605          <li>A.&nbsp;&nbsp;&nbsp;<a href="#differences.between.http.and.mime">Differences between HTTP and MIME</a><ul>
    606                <li>A.1&nbsp;&nbsp;&nbsp;<a href="#mime-version">MIME-Version</a></li>
    607                <li>A.2&nbsp;&nbsp;&nbsp;<a href="#conversion.to.canonical.form">Conversion to Canonical Form</a></li>
    608                <li>A.3&nbsp;&nbsp;&nbsp;<a href="#conversion.of.date.formats">Conversion of Date Formats</a></li>
    609                <li>A.4&nbsp;&nbsp;&nbsp;<a href="#introduction.of.content-encoding">Introduction of Content-Encoding</a></li>
    610                <li>A.5&nbsp;&nbsp;&nbsp;<a href="#no.content-transfer-encoding">No Content-Transfer-Encoding</a></li>
    611                <li>A.6&nbsp;&nbsp;&nbsp;<a href="#introduction.of.transfer-encoding">Introduction of Transfer-Encoding</a></li>
    612                <li>A.7&nbsp;&nbsp;&nbsp;<a href="#mhtml.line.length">MHTML and Line Length Limitations</a></li>
     611         <li><a href="#rfc.section.A">A.</a>&nbsp;&nbsp;&nbsp;<a href="#differences.between.http.and.mime">Differences between HTTP and MIME</a><ul>
     612               <li><a href="#rfc.section.A.1">A.1</a>&nbsp;&nbsp;&nbsp;<a href="#mime-version">MIME-Version</a></li>
     613               <li><a href="#rfc.section.A.2">A.2</a>&nbsp;&nbsp;&nbsp;<a href="#conversion.to.canonical.form">Conversion to Canonical Form</a></li>
     614               <li><a href="#rfc.section.A.3">A.3</a>&nbsp;&nbsp;&nbsp;<a href="#conversion.of.date.formats">Conversion of Date Formats</a></li>
     615               <li><a href="#rfc.section.A.4">A.4</a>&nbsp;&nbsp;&nbsp;<a href="#introduction.of.content-encoding">Introduction of Content-Encoding</a></li>
     616               <li><a href="#rfc.section.A.5">A.5</a>&nbsp;&nbsp;&nbsp;<a href="#no.content-transfer-encoding">No Content-Transfer-Encoding</a></li>
     617               <li><a href="#rfc.section.A.6">A.6</a>&nbsp;&nbsp;&nbsp;<a href="#introduction.of.transfer-encoding">Introduction of Transfer-Encoding</a></li>
     618               <li><a href="#rfc.section.A.7">A.7</a>&nbsp;&nbsp;&nbsp;<a href="#mhtml.line.length">MHTML and Line Length Limitations</a></li>
    613619            </ul>
    614620         </li>
    615          <li>B.&nbsp;&nbsp;&nbsp;<a href="#additional.features">Additional Features</a></li>
    616          <li>C.&nbsp;&nbsp;&nbsp;<a href="#changes.from.rfc.2616">Changes from RFC 2616</a></li>
    617          <li>D.&nbsp;&nbsp;&nbsp;<a href="#collected.abnf">Collected ABNF</a></li>
    618          <li>E.&nbsp;&nbsp;&nbsp;<a href="#change.log">Change Log (to be removed by RFC Editor before publication)</a><ul>
    619                <li>E.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.E.1">Since RFC 2616</a></li>
    620                <li>E.2&nbsp;&nbsp;&nbsp;<a href="#rfc.section.E.2">Since draft-ietf-httpbis-p3-payload-00</a></li>
    621                <li>E.3&nbsp;&nbsp;&nbsp;<a href="#rfc.section.E.3">Since draft-ietf-httpbis-p3-payload-01</a></li>
    622                <li>E.4&nbsp;&nbsp;&nbsp;<a href="#changes.since.02">Since draft-ietf-httpbis-p3-payload-02</a></li>
    623                <li>E.5&nbsp;&nbsp;&nbsp;<a href="#changes.since.03">Since draft-ietf-httpbis-p3-payload-03</a></li>
    624                <li>E.6&nbsp;&nbsp;&nbsp;<a href="#changes.since.04">Since draft-ietf-httpbis-p3-payload-04</a></li>
    625                <li>E.7&nbsp;&nbsp;&nbsp;<a href="#changes.since.05">Since draft-ietf-httpbis-p3-payload-05</a></li>
    626                <li>E.8&nbsp;&nbsp;&nbsp;<a href="#changes.since.06">Since draft-ietf-httpbis-p3-payload-06</a></li>
    627                <li>E.9&nbsp;&nbsp;&nbsp;<a href="#changes.since.07">Since draft-ietf-httpbis-p3-payload-07</a></li>
    628                <li>E.10&nbsp;&nbsp;&nbsp;<a href="#changes.since.08">Since draft-ietf-httpbis-p3-payload-08</a></li>
    629                <li>E.11&nbsp;&nbsp;&nbsp;<a href="#changes.since.09">Since draft-ietf-httpbis-p3-payload-09</a></li>
    630                <li>E.12&nbsp;&nbsp;&nbsp;<a href="#changes.since.10">Since draft-ietf-httpbis-p3-payload-10</a></li>
    631                <li>E.13&nbsp;&nbsp;&nbsp;<a href="#changes.since.11">Since draft-ietf-httpbis-p3-payload-11</a></li>
    632                <li>E.14&nbsp;&nbsp;&nbsp;<a href="#changes.since.12">Since draft-ietf-httpbis-p3-payload-12</a></li>
    633                <li>E.15&nbsp;&nbsp;&nbsp;<a href="#changes.since.13">Since draft-ietf-httpbis-p3-payload-13</a></li>
     621         <li><a href="#rfc.section.B">B.</a>&nbsp;&nbsp;&nbsp;<a href="#additional.features">Additional Features</a></li>
     622         <li><a href="#rfc.section.C">C.</a>&nbsp;&nbsp;&nbsp;<a href="#changes.from.rfc.2616">Changes from RFC 2616</a></li>
     623         <li><a href="#rfc.section.D">D.</a>&nbsp;&nbsp;&nbsp;<a href="#collected.abnf">Collected ABNF</a></li>
     624         <li><a href="#rfc.section.E">E.</a>&nbsp;&nbsp;&nbsp;<a href="#change.log">Change Log (to be removed by RFC Editor before publication)</a><ul>
     625               <li><a href="#rfc.section.E.1">E.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.E.1">Since RFC 2616</a></li>
     626               <li><a href="#rfc.section.E.2">E.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.E.2">Since draft-ietf-httpbis-p3-payload-00</a></li>
     627               <li><a href="#rfc.section.E.3">E.3</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.E.3">Since draft-ietf-httpbis-p3-payload-01</a></li>
     628               <li><a href="#rfc.section.E.4">E.4</a>&nbsp;&nbsp;&nbsp;<a href="#changes.since.02">Since draft-ietf-httpbis-p3-payload-02</a></li>
     629               <li><a href="#rfc.section.E.5">E.5</a>&nbsp;&nbsp;&nbsp;<a href="#changes.since.03">Since draft-ietf-httpbis-p3-payload-03</a></li>
     630               <li><a href="#rfc.section.E.6">E.6</a>&nbsp;&nbsp;&nbsp;<a href="#changes.since.04">Since draft-ietf-httpbis-p3-payload-04</a></li>
     631               <li><a href="#rfc.section.E.7">E.7</a>&nbsp;&nbsp;&nbsp;<a href="#changes.since.05">Since draft-ietf-httpbis-p3-payload-05</a></li>
     632               <li><a href="#rfc.section.E.8">E.8</a>&nbsp;&nbsp;&nbsp;<a href="#changes.since.06">Since draft-ietf-httpbis-p3-payload-06</a></li>
     633               <li><a href="#rfc.section.E.9">E.9</a>&nbsp;&nbsp;&nbsp;<a href="#changes.since.07">Since draft-ietf-httpbis-p3-payload-07</a></li>
     634               <li><a href="#rfc.section.E.10">E.10</a>&nbsp;&nbsp;&nbsp;<a href="#changes.since.08">Since draft-ietf-httpbis-p3-payload-08</a></li>
     635               <li><a href="#rfc.section.E.11">E.11</a>&nbsp;&nbsp;&nbsp;<a href="#changes.since.09">Since draft-ietf-httpbis-p3-payload-09</a></li>
     636               <li><a href="#rfc.section.E.12">E.12</a>&nbsp;&nbsp;&nbsp;<a href="#changes.since.10">Since draft-ietf-httpbis-p3-payload-10</a></li>
     637               <li><a href="#rfc.section.E.13">E.13</a>&nbsp;&nbsp;&nbsp;<a href="#changes.since.11">Since draft-ietf-httpbis-p3-payload-11</a></li>
     638               <li><a href="#rfc.section.E.14">E.14</a>&nbsp;&nbsp;&nbsp;<a href="#changes.since.12">Since draft-ietf-httpbis-p3-payload-12</a></li>
     639               <li><a href="#rfc.section.E.15">E.15</a>&nbsp;&nbsp;&nbsp;<a href="#changes.since.13">Since draft-ietf-httpbis-p3-payload-13</a></li>
    634640            </ul>
    635641         </li>
    636642         <li><a href="#rfc.index">Index</a></li>
     643         <li><a href="#rfc.authors">Authors' Addresses</a></li>
    637644      </ul>
    638       <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a id="introduction" href="#introduction">Introduction</a></h1>
    639       <p id="rfc.section.1.p.1">This document defines HTTP/1.1 message payloads (a.k.a., content), the associated metadata header fields that define how the
    640          payload is intended to be interpreted by a recipient, the request header fields that might influence content selection, and
    641          the various selection algorithms that are collectively referred to as HTTP content negotiation.
    642       </p>
    643       <p id="rfc.section.1.p.2">This document is currently disorganized in order to minimize the changes between drafts and enable reviewers to see the smaller
    644          errata changes. A future draft will reorganize the sections to better reflect the content. In particular, the sections on
    645          entities will be renamed payload and moved to the first half of the document, while the sections on content negotiation and
    646          associated request header fields will be moved to the second half. The current mess reflects how widely dispersed these topics
    647          and associated requirements had become in <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.
    648       </p>
    649       <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a id="terminology" href="#terminology">Terminology</a></h2>
    650       <p id="rfc.section.1.1.p.1">This specification uses a number of terms to refer to the roles played by participants in, and objects of, the HTTP communication.</p>
    651       <p id="rfc.section.1.1.p.2"> <span id="rfc.iref.c.1"></span>  <dfn>content negotiation</dfn> 
    652       </p>
    653       <ul class="empty">
    654          <li>The mechanism for selecting the appropriate representation when servicing a request. The representation in any response can
    655             be negotiated (including error responses).
    656          </li>
    657       </ul>
    658       <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="intro.requirements" href="#intro.requirements">Requirements</a></h2>
    659       <p id="rfc.section.1.2.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
    660          in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.
    661       </p>
    662       <p id="rfc.section.1.2.p.2">An implementation is not compliant if it fails to satisfy one or more of the "MUST" or "REQUIRED" level requirements for the
    663          protocols it implements. An implementation that satisfies all the "MUST" or "REQUIRED" level and all the "SHOULD" level requirements
    664          for its protocols is said to be "unconditionally compliant"; one that satisfies all the "MUST" level requirements but not
    665          all the "SHOULD" level requirements for its protocols is said to be "conditionally compliant".
    666       </p>
    667       <h2 id="rfc.section.1.3"><a href="#rfc.section.1.3">1.3</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>
    668       <p id="rfc.section.1.3.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</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> (which extends the syntax defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list rule). <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;D</a> shows the collected ABNF, with the list rule expanded.
    669       </p>
    670       <p id="rfc.section.1.3.p.2">The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG
    671          (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), VCHAR (any visible USASCII character),
    672          and WSP (whitespace).
    673       </p>
    674       <h3 id="rfc.section.1.3.1"><a href="#rfc.section.1.3.1">1.3.1</a>&nbsp;<a id="core.rules" href="#core.rules">Core Rules</a></h3>
    675       <p id="rfc.section.1.3.1.p.1">The core rules below are defined in <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.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>:
    676       </p>
    677       <div id="rfc.figure.u.1"></div><pre class="inline">  <a href="#core.rules" class="smpl">token</a>          = &lt;token, 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 1.2.2</a>&gt;
     645      <div id="introduction">
     646         <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a href="#introduction">Introduction</a></h1>
     647         <p id="rfc.section.1.p.1">This document defines HTTP/1.1 message payloads (a.k.a., content), the associated metadata header fields that define how the
     648            payload is intended to be interpreted by a recipient, the request header fields that might influence content selection, and
     649            the various selection algorithms that are collectively referred to as HTTP content negotiation.
     650         </p>
     651         <p id="rfc.section.1.p.2">This document is currently disorganized in order to minimize the changes between drafts and enable reviewers to see the smaller
     652            errata changes. A future draft will reorganize the sections to better reflect the content. In particular, the sections on
     653            entities will be renamed payload and moved to the first half of the document, while the sections on content negotiation and
     654            associated request header fields will be moved to the second half. The current mess reflects how widely dispersed these topics
     655            and associated requirements had become in <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.
     656         </p>
     657         <div id="terminology">
     658            <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a href="#terminology">Terminology</a></h2>
     659            <p id="rfc.section.1.1.p.1">This specification uses a number of terms to refer to the roles played by participants in, and objects of, the HTTP communication.</p>
     660            <p id="rfc.section.1.1.p.2"><span id="rfc.iref.c.1"></span> <dfn>content negotiation</dfn>
     661            </p>
     662            <ul class="empty">
     663               <li>The mechanism for selecting the appropriate representation when servicing a request. The representation in any response can
     664                  be negotiated (including error responses).
     665               </li>
     666            </ul>
     667         </div>
     668         <div id="intro.requirements">
     669            <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a href="#intro.requirements">Requirements</a></h2>
     670            <p id="rfc.section.1.2.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
     671               in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.
     672            </p>
     673            <p id="rfc.section.1.2.p.2">An implementation is not compliant if it fails to satisfy one or more of the "MUST" or "REQUIRED" level requirements for the
     674               protocols it implements. An implementation that satisfies all the "MUST" or "REQUIRED" level and all the "SHOULD" level requirements
     675               for its protocols is said to be "unconditionally compliant"; one that satisfies all the "MUST" level requirements but not
     676               all the "SHOULD" level requirements for its protocols is said to be "conditionally compliant".
     677            </p>
     678         </div>
     679         <div id="notation">
     680            <h2 id="rfc.section.1.3"><a href="#rfc.section.1.3">1.3</a>&nbsp;<a href="#notation">Syntax Notation</a></h2>
     681            <p id="rfc.section.1.3.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</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> (which extends the syntax defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list rule). <a href="#collected.abnf" title="Collected ABNF">Appendix&nbsp;D</a> shows the collected ABNF, with the list rule expanded.
     682            </p>
     683            <p id="rfc.section.1.3.p.2">The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="https://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG
     684               (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), VCHAR (any visible USASCII character),
     685               and WSP (whitespace).
     686            </p>
     687            <div id="core.rules">
     688               <h3 id="rfc.section.1.3.1"><a href="#rfc.section.1.3.1">1.3.1</a>&nbsp;<a href="#core.rules">Core Rules</a></h3>
     689               <p id="rfc.section.1.3.1.p.1">The core rules below are defined in <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.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>:
     690               </p>
     691               <div id="rfc.figure.u.1"></div><pre class="inline">  <a href="#core.rules" class="smpl">token</a>          = &lt;token, 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 1.2.2</a>&gt;
    678692  <a href="#core.rules" class="smpl">word</a>           = &lt;word, 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 1.2.2</a>&gt;
    679693  <a href="#core.rules" class="smpl">OWS</a>            = &lt;OWS, 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 1.2.2</a>&gt;
    680 </pre><h3 id="rfc.section.1.3.2"><a href="#rfc.section.1.3.2">1.3.2</a>&nbsp;<a id="abnf.dependencies" href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></h3>
    681       <p id="rfc.section.1.3.2.p.1">The ABNF rules below are defined in other parts:</p>
    682       <div id="rfc.figure.u.2"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">absolute-URI</a>   = &lt;absolute-URI, 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#uri" title="Uniform Resource Identifiers">Section 2.6</a>&gt;
     694</pre></div>
     695            <div id="abnf.dependencies">
     696               <h3 id="rfc.section.1.3.2"><a href="#rfc.section.1.3.2">1.3.2</a>&nbsp;<a href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></h3>
     697               <p id="rfc.section.1.3.2.p.1">The ABNF rules below are defined in other parts:</p>
     698               <div id="rfc.figure.u.2"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">absolute-URI</a>   = &lt;absolute-URI, 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#uri" title="Uniform Resource Identifiers">Section 2.6</a>&gt;
    683699  <a href="#abnf.dependencies" class="smpl">partial-URI</a>    = &lt;partial-URI, 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#uri" title="Uniform Resource Identifiers">Section 2.6</a>&gt;
    684700  <a href="#abnf.dependencies" class="smpl">qvalue</a>         = &lt;qvalue, defined in <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#quality.values" title="Quality Values">Section 6.4</a>&gt;
    685 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1>
    686       <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="character.sets" href="#character.sets">Character Encodings (charset)</a></h2>
    687       <p id="rfc.section.2.1.p.1">HTTP uses charset names to indicate the character encoding of a textual representation.</p>
    688       <div id="rule.charset">
    689          <p id="rfc.section.2.1.p.2">  A character encoding is identified by a case-insensitive token. The complete set of tokens is defined by the IANA Character
    690             Set registry (&lt;<a href="http://www.iana.org/assignments/character-sets">http://www.iana.org/assignments/character-sets</a>&gt;).
    691          </p>
     701</pre></div>
     702         </div>
    692703      </div>
    693       <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.1"></span>  <a href="#rule.charset" class="smpl">charset</a> = <a href="#core.rules" class="smpl">token</a>
     704      <div id="protocol.parameters">
     705         <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a href="#protocol.parameters">Protocol Parameters</a></h1>
     706         <div id="character.sets">
     707            <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a href="#character.sets">Character Encodings (charset)</a></h2>
     708            <p id="rfc.section.2.1.p.1">HTTP uses charset names to indicate the character encoding of a textual representation.</p>
     709            <div id="rule.charset">
     710               <p id="rfc.section.2.1.p.2"> A character encoding is identified by a case-insensitive token. The complete set of tokens is defined by the IANA Character
     711                  Set registry (&lt;<a href="http://www.iana.org/assignments/character-sets">http://www.iana.org/assignments/character-sets</a>&gt;).
     712               </p>
     713            </div>
     714            <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.1"></span>  <a href="#rule.charset" class="smpl">charset</a> = <a href="#core.rules" class="smpl">token</a>
    694715</pre><p id="rfc.section.2.1.p.4">Although HTTP allows an arbitrary token to be used as a charset value, any token that has a predefined value within the IANA
    695          Character Set registry <em class="bcp14">MUST</em> represent the character encoding defined by that registry. Applications <em class="bcp14">SHOULD</em> limit their use of character encodings to those defined within the IANA registry.
    696       </p>
    697       <p id="rfc.section.2.1.p.5">HTTP uses charset in two contexts: within an Accept-Charset request header field (in which the charset value is an unquoted
    698          token) and as the value of a parameter in a Content-Type header field (within a request or response), in which case the parameter
    699          value of the charset parameter can be quoted.
    700       </p>
    701       <p id="rfc.section.2.1.p.6">Implementors need to be aware of IETF character set requirements <a href="#RFC3629" id="rfc.xref.RFC3629.1"><cite title="UTF-8, a transformation format of ISO 10646">[RFC3629]</cite></a>  <a href="#RFC2277" id="rfc.xref.RFC2277.1"><cite title="IETF Policy on Character Sets and Languages">[RFC2277]</cite></a>.
    702       </p>
    703       <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="content.codings" href="#content.codings">Content Codings</a></h2>
    704       <p id="rfc.section.2.2.p.1">Content coding values indicate an encoding transformation that has been or can be applied to a representation. Content codings
    705          are primarily used to allow a representation to be compressed or otherwise usefully transformed without losing the identity
    706          of its underlying media type and without loss of information. Frequently, the representation is stored in coded form, transmitted
    707          directly, and only decoded by the recipient.
    708       </p>
    709       <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.2"></span>  <a href="#content.codings" class="smpl">content-coding</a>   = <a href="#core.rules" class="smpl">token</a>
     716               Character Set registry <em class="bcp14">MUST</em> represent the character encoding defined by that registry. Applications <em class="bcp14">SHOULD</em> limit their use of character encodings to those defined within the IANA registry.
     717            </p>
     718            <p id="rfc.section.2.1.p.5">HTTP uses charset in two contexts: within an Accept-Charset request header field (in which the charset value is an unquoted
     719               token) and as the value of a parameter in a Content-Type header field (within a request or response), in which case the parameter
     720               value of the charset parameter can be quoted.
     721            </p>
     722            <p id="rfc.section.2.1.p.6">Implementors need to be aware of IETF character set requirements <a href="#RFC3629" id="rfc.xref.RFC3629.1"><cite title="UTF-8, a transformation format of ISO 10646">[RFC3629]</cite></a> <a href="#RFC2277" id="rfc.xref.RFC2277.1"><cite title="IETF Policy on Character Sets and Languages">[RFC2277]</cite></a>.
     723            </p>
     724         </div>
     725         <div id="content.codings">
     726            <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a href="#content.codings">Content Codings</a></h2>
     727            <p id="rfc.section.2.2.p.1">Content coding values indicate an encoding transformation that has been or can be applied to a representation. Content codings
     728               are primarily used to allow a representation to be compressed or otherwise usefully transformed without losing the identity
     729               of its underlying media type and without loss of information. Frequently, the representation is stored in coded form, transmitted
     730               directly, and only decoded by the recipient.
     731            </p>
     732            <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.2"></span>  <a href="#content.codings" class="smpl">content-coding</a>   = <a href="#core.rules" class="smpl">token</a>
    710733</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&nbsp;6.3</a>) and Content-Encoding (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.1" title="Content-Encoding">Section&nbsp;6.5</a>) header fields. Although the value describes the content-coding, what is more important is that it indicates what decoding
    711          mechanism will be required to remove the encoding.
    712       </p>
    713       <p id="rfc.section.2.2.p.4">compress<span id="rfc.iref.c.2"></span><span id="rfc.iref.c.3"></span> 
    714       </p>
    715       <ul class="empty">
    716          <li>See <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 6.2.2.1</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>.
    717          </li>
    718       </ul>
    719       <p id="rfc.section.2.2.p.5">deflate<span id="rfc.iref.d.1"></span><span id="rfc.iref.c.4"></span> 
    720       </p>
    721       <ul class="empty">
    722          <li>See <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 6.2.2.2</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>.
    723          </li>
    724       </ul>
    725       <p id="rfc.section.2.2.p.6">gzip<span id="rfc.iref.g.3"></span><span id="rfc.iref.c.5"></span> 
    726       </p>
    727       <ul class="empty">
    728          <li>See <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 6.2.2.3</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>.
    729          </li>
    730       </ul>
    731       <p id="rfc.section.2.2.p.7">identity<span id="rfc.iref.i.1"></span><span id="rfc.iref.c.6"></span> 
    732       </p>
    733       <ul class="empty">
    734          <li>The default (identity) encoding; the use of no transformation whatsoever. This content-coding is used only in the Accept-Encoding
    735             header field, and <em class="bcp14">SHOULD NOT</em> be used in the Content-Encoding header field.
    736          </li>
    737       </ul>
    738       <h3 id="rfc.section.2.2.1"><a href="#rfc.section.2.2.1">2.2.1</a>&nbsp;<a id="content.coding.registry" href="#content.coding.registry">Content Coding Registry</a></h3>
    739       <p id="rfc.section.2.2.1.p.1">The HTTP Content Coding Registry defines the name space for the content coding names.</p>
    740       <p id="rfc.section.2.2.1.p.2">Registrations <em class="bcp14">MUST</em> include the following fields:
    741       </p>
    742       <ul>
    743          <li>Name</li>
    744          <li>Description</li>
    745          <li>Pointer to specification text</li>
    746       </ul>
    747       <p id="rfc.section.2.2.1.p.3">Names of content codings <em class="bcp14">MUST NOT</em> overlap with names of transfer codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), unless the encoding transformation is identical (as it is the case for the compression codings defined in <a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 6.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    748       </p>
    749       <p id="rfc.section.2.2.1.p.4">Values to be added to this name space require a specification (see "Specification Required" in <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of content coding defined in this section.
    750       </p>
    751       <p id="rfc.section.2.2.1.p.5">The registry itself is maintained at &lt;<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>&gt;.
    752       </p>
    753       <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;<a id="media.types" href="#media.types">Media Types</a></h2>
    754       <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&nbsp;6.8</a>) and Accept (<a href="#header.accept" id="rfc.xref.header.accept.1" title="Accept">Section&nbsp;6.1</a>) header fields in order to provide open and extensible data typing and type negotiation.
    755       </p>
    756       <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>  <a href="#media.types" class="smpl">media-type</a> = <a href="#media.types" class="smpl">type</a> "/" <a href="#media.types" class="smpl">subtype</a> *( <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> <a href="#rule.parameter" class="smpl">parameter</a> )
     734               mechanism will be required to remove the encoding.
     735            </p>
     736            <p id="rfc.section.2.2.p.4">compress<span id="rfc.iref.c.2"></span><span id="rfc.iref.c.3"></span>
     737            </p>
     738            <ul class="empty">
     739               <li>See <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 6.2.2.1</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>.
     740               </li>
     741            </ul>
     742            <p id="rfc.section.2.2.p.5">deflate<span id="rfc.iref.d.1"></span><span id="rfc.iref.c.4"></span>
     743            </p>
     744            <ul class="empty">
     745               <li>See <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 6.2.2.2</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>.
     746               </li>
     747            </ul>
     748            <p id="rfc.section.2.2.p.6">gzip<span id="rfc.iref.g.3"></span><span id="rfc.iref.c.5"></span>
     749            </p>
     750            <ul class="empty">
     751               <li>See <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 6.2.2.3</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>.
     752               </li>
     753            </ul>
     754            <p id="rfc.section.2.2.p.7">identity<span id="rfc.iref.i.1"></span><span id="rfc.iref.c.6"></span>
     755            </p>
     756            <ul class="empty">
     757               <li>The default (identity) encoding; the use of no transformation whatsoever. This content-coding is used only in the Accept-Encoding
     758                  header field, and <em class="bcp14">SHOULD NOT</em> be used in the Content-Encoding header field.
     759               </li>
     760            </ul>
     761            <div id="content.coding.registry">
     762               <h3 id="rfc.section.2.2.1"><a href="#rfc.section.2.2.1">2.2.1</a>&nbsp;<a href="#content.coding.registry">Content Coding Registry</a></h3>
     763               <p id="rfc.section.2.2.1.p.1">The HTTP Content Coding Registry defines the name space for the content coding names.</p>
     764               <p id="rfc.section.2.2.1.p.2">Registrations <em class="bcp14">MUST</em> include the following fields:
     765               </p>
     766               <ul>
     767                  <li>Name</li>
     768                  <li>Description</li>
     769                  <li>Pointer to specification text</li>
     770               </ul>
     771               <p id="rfc.section.2.2.1.p.3">Names of content codings <em class="bcp14">MUST NOT</em> overlap with names of transfer codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), unless the encoding transformation is identical (as it is the case for the compression codings defined in <a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 6.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     772               </p>
     773               <p id="rfc.section.2.2.1.p.4">Values to be added to this name space require a specification (see "Specification Required" in <a href="https://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of content coding defined in this section.
     774               </p>
     775               <p id="rfc.section.2.2.1.p.5">The registry itself is maintained at &lt;<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>&gt;.
     776               </p>
     777            </div>
     778         </div>
     779         <div id="media.types">
     780            <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;<a href="#media.types">Media Types</a></h2>
     781            <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&nbsp;6.8</a>) and Accept (<a href="#header.accept" id="rfc.xref.header.accept.1" title="Accept">Section&nbsp;6.1</a>) header fields in order to provide open and extensible data typing and type negotiation.
     782            </p>
     783            <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>  <a href="#media.types" class="smpl">media-type</a> = <a href="#media.types" class="smpl">type</a> "/" <a href="#media.types" class="smpl">subtype</a> *( <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> <a href="#rule.parameter" class="smpl">parameter</a> )
    757784  <a href="#media.types" class="smpl">type</a>       = <a href="#core.rules" class="smpl">token</a>
    758785  <a href="#media.types" class="smpl">subtype</a>    = <a href="#core.rules" class="smpl">token</a>
    759786</pre><div id="rule.parameter">
    760          <p id="rfc.section.2.3.p.3">      The type/subtype <em class="bcp14">MAY</em> be followed by parameters in the form of attribute/value pairs.
    761          </p>
    762       </div>
    763       <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>  <a href="#rule.parameter" class="smpl">parameter</a>      = <a href="#rule.parameter" class="smpl">attribute</a> "=" <a href="#rule.parameter" class="smpl">value</a>
     787               <p id="rfc.section.2.3.p.3">   The type/subtype <em class="bcp14">MAY</em> be followed by parameters in the form of attribute/value pairs.
     788               </p>
     789            </div>
     790            <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>  <a href="#rule.parameter" class="smpl">parameter</a>      = <a href="#rule.parameter" class="smpl">attribute</a> "=" <a href="#rule.parameter" class="smpl">value</a>
    764791  <a href="#rule.parameter" class="smpl">attribute</a>      = <a href="#core.rules" class="smpl">token</a>
    765792  <a href="#rule.parameter" class="smpl">value</a>          = <a href="#core.rules" class="smpl">word</a>
    766793</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,
    767          depending on the semantics of the parameter name. The presence or absence of a parameter might be significant to the processing
    768          of a media-type, depending on its definition within the media type registry.
    769       </p>
    770       <p id="rfc.section.2.3.p.6">A parameter value that matches the <a href="#core.rules" class="smpl">token</a> production can be transmitted as either a token or within a quoted-string. The quoted and unquoted values are equivalent.
    771       </p>
    772       <p id="rfc.section.2.3.p.7">Note that some older HTTP applications do not recognize media type parameters. When sending data to older HTTP applications,
    773          implementations <em class="bcp14">SHOULD</em> only use media type parameters when they are required by that type/subtype definition.
    774       </p>
    775       <p id="rfc.section.2.3.p.8">Media-type values are registered with the Internet Assigned Number Authority (IANA). The media type registration process is
    776          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.
    777       </p>
    778       <h3 id="rfc.section.2.3.1"><a href="#rfc.section.2.3.1">2.3.1</a>&nbsp;<a id="canonicalization.and.text.defaults" href="#canonicalization.and.text.defaults">Canonicalization and Text Defaults</a></h3>
    779       <p id="rfc.section.2.3.1.p.1">Internet media types are registered with a canonical form. A representation transferred via HTTP messages <em class="bcp14">MUST</em> be in the appropriate canonical form prior to its transmission except for "text" types, as defined in the next paragraph.
    780       </p>
    781       <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 and
    782          allows the transport of text media with plain CR or LF alone representing a line break when it is done consistently for an
    783          entire representation. HTTP applications <em class="bcp14">MUST</em> accept CRLF, bare CR, and bare LF as indicating a line break in text media received via HTTP. In addition, if the text is
    784          in a character encoding that does not use octets 13 and 10 for CR and LF respectively, as is the case for some multi-byte
    785          character encodings, HTTP allows the use of whatever octet sequences are defined by that character encoding to represent the
    786          equivalent of CR and LF for line breaks. This flexibility regarding line breaks applies only to text media in the payload
    787          body; a bare CR or LF <em class="bcp14">MUST NOT</em> be substituted for CRLF within any of the HTTP control structures (such as header fields and multipart boundaries).
    788       </p>
    789       <p id="rfc.section.2.3.1.p.3">If a representation is encoded with a content-coding, the underlying data <em class="bcp14">MUST</em> be in a form defined above prior to being encoded.
    790       </p>
    791       <h3 id="rfc.section.2.3.2"><a href="#rfc.section.2.3.2">2.3.2</a>&nbsp;<a id="multipart.types" href="#multipart.types">Multipart Types</a></h3>
    792       <p id="rfc.section.2.3.2.p.1">MIME provides for a number of "multipart" types — encapsulations of one or more representations within a single message-body.
    793          All multipart types share a common syntax, as defined in <a href="http://tools.ietf.org/html/rfc2046#section-5.1.1">Section 5.1.1</a> of <a href="#RFC2046" id="rfc.xref.RFC2046.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, and <em class="bcp14">MUST</em> include a boundary parameter as part of the media type value. The message body is itself a protocol element and <em class="bcp14">MUST</em> therefore use only CRLF to represent line breaks between body-parts.
    794       </p>
    795       <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. HTTP does
    796          not use the multipart boundary as an indicator of message-body length.  In all other respects, an HTTP user agent <em class="bcp14">SHOULD</em> follow the same or similar behavior as a MIME user agent would upon receipt of a multipart type. The MIME header fields within
    797          each body-part of a multipart message-body do not have any significance to HTTP beyond that defined by their MIME semantics.
    798       </p>
    799       <p id="rfc.section.2.3.2.p.3">If an application receives an unrecognized multipart subtype, the application <em class="bcp14">MUST</em> treat it as being equivalent to "multipart/mixed".
    800       </p>
    801       <div class="note" id="rfc.section.2.3.2.p.4">
    802          <p> <b>Note:</b> The "multipart/form-data" type has been specifically defined for carrying form data suitable for processing via the POST request
    803             method, as described in <a href="#RFC2388" id="rfc.xref.RFC2388.1"><cite title="Returning Values from Forms: multipart/form-data">[RFC2388]</cite></a>.
    804          </p>
     794               depending on the semantics of the parameter name. The presence or absence of a parameter might be significant to the processing
     795               of a media-type, depending on its definition within the media type registry.
     796            </p>
     797            <p id="rfc.section.2.3.p.6">A parameter value that matches the <a href="#core.rules" class="smpl">token</a> production can be transmitted as either a token or within a quoted-string. The quoted and unquoted values are equivalent.
     798            </p>
     799            <p id="rfc.section.2.3.p.7">Note that some older HTTP applications do not recognize media type parameters. When sending data to older HTTP applications,
     800               implementations <em class="bcp14">SHOULD</em> only use media type parameters when they are required by that type/subtype definition.
     801            </p>
     802            <p id="rfc.section.2.3.p.8">Media-type values are registered with the Internet Assigned Number Authority (IANA). The media type registration process is
     803               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.
     804            </p>
     805            <div id="canonicalization.and.text.defaults">
     806               <h3 id="rfc.section.2.3.1"><a href="#rfc.section.2.3.1">2.3.1</a>&nbsp;<a href="#canonicalization.and.text.defaults">Canonicalization and Text Defaults</a></h3>
     807               <p id="rfc.section.2.3.1.p.1">Internet media types are registered with a canonical form. A representation transferred via HTTP messages <em class="bcp14">MUST</em> be in the appropriate canonical form prior to its transmission except for "text" types, as defined in the next paragraph.
     808               </p>
     809               <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 and
     810                  allows the transport of text media with plain CR or LF alone representing a line break when it is done consistently for an
     811                  entire representation. HTTP applications <em class="bcp14">MUST</em> accept CRLF, bare CR, and bare LF as indicating a line break in text media received via HTTP. In addition, if the text is
     812                  in a character encoding that does not use octets 13 and 10 for CR and LF respectively, as is the case for some multi-byte
     813                  character encodings, HTTP allows the use of whatever octet sequences are defined by that character encoding to represent the
     814                  equivalent of CR and LF for line breaks. This flexibility regarding line breaks applies only to text media in the payload
     815                  body; a bare CR or LF <em class="bcp14">MUST NOT</em> be substituted for CRLF within any of the HTTP control structures (such as header fields and multipart boundaries).
     816               </p>
     817               <p id="rfc.section.2.3.1.p.3">If a representation is encoded with a content-coding, the underlying data <em class="bcp14">MUST</em> be in a form defined above prior to being encoded.
     818               </p>
     819            </div>
     820            <div id="multipart.types">
     821               <h3 id="rfc.section.2.3.2"><a href="#rfc.section.2.3.2">2.3.2</a>&nbsp;<a href="#multipart.types">Multipart Types</a></h3>
     822               <p id="rfc.section.2.3.2.p.1">MIME provides for a number of "multipart" types — encapsulations of one or more representations within a single message-body.
     823                  All multipart types share a common syntax, as defined in <a href="https://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.
     824               </p>
     825               <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. HTTP does
     826                  not use the multipart boundary as an indicator of message-body length.  In all other respects, an HTTP user agent <em class="bcp14">SHOULD</em> follow the same or similar behavior as a MIME user agent would upon receipt of a multipart type. The MIME header fields within
     827                  each body-part of a multipart message-body do not have any significance to HTTP beyond that defined by their MIME semantics.
     828               </p>
     829               <p id="rfc.section.2.3.2.p.3">If an application receives an unrecognized multipart subtype, the application <em class="bcp14">MUST</em> treat it as being equivalent to "multipart/mixed".
     830               </p>
     831               <div class="note" id="rfc.section.2.3.2.p.4">
     832                  <p><b>Note:</b> The "multipart/form-data" type has been specifically defined for carrying form data suitable for processing via the POST request
     833                     method, as described in <a href="#RFC2388" id="rfc.xref.RFC2388.1"><cite title="Returning Values from Forms: multipart/form-data">[RFC2388]</cite></a>.
     834                  </p>
     835               </div>
     836            </div>
     837         </div>
     838         <div id="language.tags">
     839            <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;<a href="#language.tags">Language Tags</a></h2>
     840            <p id="rfc.section.2.4.p.1">A language tag, as defined in <a href="#RFC5646" id="rfc.xref.RFC5646.1"><cite title="Tags for Identifying Languages">[RFC5646]</cite></a>, identifies a natural language spoken, written, or otherwise conveyed by human beings for communication of information to
     841               other human beings. Computer languages are explicitly excluded. HTTP uses language tags within the Accept-Language and Content-Language
     842               fields.
     843            </p>
     844            <p id="rfc.section.2.4.p.2">In summary, a language tag is composed of one or more parts: A primary language subtag followed by a possibly empty series
     845               of subtags:
     846            </p>
     847            <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.10"></span>  <a href="#language.tags" class="smpl">language-tag</a> = &lt;Language-Tag, defined in <a href="#RFC5646" id="rfc.xref.RFC5646.2"><cite title="Tags for Identifying Languages">[RFC5646]</cite></a>, <a href="https://tools.ietf.org/html/rfc5646#section-2.1">Section 2.1</a>&gt;
     848</pre><p id="rfc.section.2.4.p.4">White space is not allowed within the tag and all tags are case-insensitive. The name space of language subtags is administered
     849               by the IANA (see &lt;<a href="http://www.iana.org/assignments/language-subtag-registry">http://www.iana.org/assignments/language-subtag-registry</a>&gt;).
     850            </p>
     851            <div id="rfc.figure.u.8"></div>
     852            <p>Example tags include:</p><pre class="text">  en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN
     853</pre><p id="rfc.section.2.4.p.6">See <a href="#RFC5646" id="rfc.xref.RFC5646.3"><cite title="Tags for Identifying Languages">[RFC5646]</cite></a> for further information.
     854            </p>
     855         </div>
    805856      </div>
    806       <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;<a id="language.tags" href="#language.tags">Language Tags</a></h2>
    807       <p id="rfc.section.2.4.p.1">A language tag, as defined in <a href="#RFC5646" id="rfc.xref.RFC5646.1"><cite title="Tags for Identifying Languages">[RFC5646]</cite></a>, identifies a natural language spoken, written, or otherwise conveyed by human beings for communication of information to
    808          other human beings. Computer languages are explicitly excluded. HTTP uses language tags within the Accept-Language and Content-Language
    809          fields.
    810       </p>
    811       <p id="rfc.section.2.4.p.2">In summary, a language tag is composed of one or more parts: A primary language subtag followed by a possibly empty series
    812          of subtags:
    813       </p>
    814       <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.10"></span>  <a href="#language.tags" class="smpl">language-tag</a> = &lt;Language-Tag, defined in <a href="#RFC5646" id="rfc.xref.RFC5646.2"><cite title="Tags for Identifying Languages">[RFC5646]</cite></a>, <a href="http://tools.ietf.org/html/rfc5646#section-2.1">Section 2.1</a>&gt;
    815 </pre><p id="rfc.section.2.4.p.4">White space is not allowed within the tag and all tags are case-insensitive. The name space of language subtags is administered
    816          by the IANA (see &lt;<a href="http://www.iana.org/assignments/language-subtag-registry">http://www.iana.org/assignments/language-subtag-registry</a>&gt;).
    817       </p>
    818       <div id="rfc.figure.u.8"></div>
    819       <p>Example tags include:</p>  <pre class="text">  en, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN
    820 </pre> <p id="rfc.section.2.4.p.6">See <a href="#RFC5646" id="rfc.xref.RFC5646.3"><cite title="Tags for Identifying Languages">[RFC5646]</cite></a> for further information.
    821       </p>
    822       <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="payload" href="#payload">Payload</a></h1>
    823       <p id="rfc.section.3.p.1">HTTP messages <em class="bcp14">MAY</em> transfer a payload if not otherwise restricted by the request method or response status code. The payload consists of metadata,
    824          in the form of header fields, and data, in the form of the sequence of octets in the message-body after any transfer-coding
    825          has been decoded.
    826       </p>
    827       <div id="rfc.iref.p.1"></div>
    828       <p id="rfc.section.3.p.2">A "<dfn>payload</dfn>" in HTTP is always a partial or complete representation of some resource. We use separate terms for payload and representation
    829          because some messages contain only the associated representation's header fields (e.g., responses to HEAD) or only some part(s)
    830          of the representation (e.g., the 206 status code).
    831       </p>
    832       <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="payload.header.fields" href="#payload.header.fields">Payload Header Fields</a></h2>
    833       <p id="rfc.section.3.1.p.1">HTTP header fields that specifically define the payload, rather than the associated representation, are referred to as "payload
    834          header fields". The following payload header fields are defined by HTTP/1.1:
    835       </p>
    836       <div id="rfc.table.u.1">
    837          <table class="tt full left" cellpadding="3" cellspacing="0">
    838             <thead>
    839                <tr>
    840                   <th>Header Field Name</th>
    841                   <th>Defined in...</th>
    842                </tr>
    843             </thead>
    844             <tbody>
    845                <tr>
    846                   <td class="left">Content-Length</td>
    847                   <td class="left"><a href="p1-messaging.html#header.content-length" title="Content-Length">Section 9.2</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>
    848                </tr>
    849                <tr>
    850                   <td class="left">Content-Range</td>
    851                   <td class="left"><a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</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></td>
    852                </tr>
    853             </tbody>
    854          </table>
     857      <div id="payload">
     858         <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a href="#payload">Payload</a></h1>
     859         <p id="rfc.section.3.p.1">HTTP messages <em class="bcp14">MAY</em> transfer a payload if not otherwise restricted by the request method or response status code. The payload consists of metadata,
     860            in the form of header fields, and data, in the form of the sequence of octets in the message-body after any transfer-coding
     861            has been decoded.
     862         </p>
     863         <div id="rfc.iref.p.1"></div>
     864         <p id="rfc.section.3.p.2">A "<dfn>payload</dfn>" in HTTP is always a partial or complete representation of some resource. We use separate terms for payload and representation
     865            because some messages contain only the associated representation's header fields (e.g., responses to HEAD) or only some part(s)
     866            of the representation (e.g., the 206 status code).
     867         </p>
     868         <div id="payload.header.fields">
     869            <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a href="#payload.header.fields">Payload Header Fields</a></h2>
     870            <p id="rfc.section.3.1.p.1">HTTP header fields that specifically define the payload, rather than the associated representation, are referred to as "payload
     871               header fields". The following payload header fields are defined by HTTP/1.1:
     872            </p>
     873            <div id="rfc.table.u.1">
     874               <table class="tt full left" cellpadding="3" cellspacing="0">
     875                  <thead>
     876                     <tr>
     877                        <th>Header Field Name</th>
     878                        <th>Defined in...</th>
     879                     </tr>
     880                  </thead>
     881                  <tbody>
     882                     <tr>
     883                        <td class="left">Content-Length</td>
     884                        <td class="left"><a href="p1-messaging.html#header.content-length" title="Content-Length">Section 9.2</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>
     885                     </tr>
     886                     <tr>
     887                        <td class="left">Content-Range</td>
     888                        <td class="left"><a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</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></td>
     889                     </tr>
     890                  </tbody>
     891               </table>
     892            </div>
     893         </div>
     894         <div id="payload.body">
     895            <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a href="#payload.body">Payload Body</a></h2>
     896            <p id="rfc.section.3.2.p.1">A payload body is only present in a message when a message-body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The payload body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied to ensure
     897               safe and proper transfer of the message.
     898            </p>
     899         </div>
    855900      </div>
    856       <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="payload.body" href="#payload.body">Payload Body</a></h2>
    857       <p id="rfc.section.3.2.p.1">A payload body is only present in a message when a message-body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The payload body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied to ensure
    858          safe and proper transfer of the message.
    859       </p>
    860       <div id="rfc.iref.r.1"></div>
    861       <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="representation" href="#representation">Representation</a></h1>
    862       <p id="rfc.section.4.p.1">A "<dfn>representation</dfn>" is information in a format that can be readily communicated from one party to another. A resource representation is information
    863          that reflects the state of that resource, as observed at some point in the past (e.g., in a response to GET) or to be desired
    864          at some point in the future (e.g., in a PUT request).
    865       </p>
    866       <p id="rfc.section.4.p.2">Most, but not all, representations transferred via HTTP are intended to be a representation of the target resource (the resource
    867          identified by the effective request URI). The precise semantics of a representation are determined by the type of message
    868          (request or response), the request method, the response status code, and the representation metadata. For example, the above
    869          semantic is true for the representation in any 200 (OK) response to GET and for the representation in any PUT request. A 200
    870          response to PUT, in contrast, contains either a representation that describes the successful action or a representation of
    871          the target resource, with the latter indicated by a Content-Location header field with the same value as the effective request
    872          URI. Likewise, response messages with an error status code usually contain a representation that describes the error and what
    873          next steps are suggested for resolving it.
    874       </p>
    875       <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="representation.header.fields" href="#representation.header.fields">Representation Header Fields</a></h2>
    876       <p id="rfc.section.4.1.p.1">Representation header fields define metadata about the representation data enclosed in the message-body or, if no message-body
    877          is present, about the representation that would have been transferred in a 200 response to a simultaneous GET request with
    878          the same effective request URI.
    879       </p>
    880       <p id="rfc.section.4.1.p.2">The following header fields are defined as representation metadata:</p>
    881       <div id="rfc.table.u.2">
    882          <table class="tt full left" cellpadding="3" cellspacing="0">
    883             <thead>
    884                <tr>
    885                   <th>Header Field Name</th>
    886                   <th>Defined in...</th>
    887                </tr>
    888             </thead>
    889             <tbody>
    890                <tr>
    891                   <td class="left">Content-Encoding</td>
    892                   <td class="left"><a href="#header.content-encoding" id="rfc.xref.header.content-encoding.2" title="Content-Encoding">Section&nbsp;6.5</a></td>
    893                </tr>
    894                <tr>
    895                   <td class="left">Content-Language</td>
    896                   <td class="left"><a href="#header.content-language" id="rfc.xref.header.content-language.1" title="Content-Language">Section&nbsp;6.6</a></td>
    897                </tr>
    898                <tr>
    899                   <td class="left">Content-Location</td>
    900                   <td class="left"><a href="#header.content-location" id="rfc.xref.header.content-location.1" title="Content-Location">Section&nbsp;6.7</a></td>
    901                </tr>
    902                <tr>
    903                   <td class="left">Content-Type</td>
    904                   <td class="left"><a href="#header.content-type" id="rfc.xref.header.content-type.2" title="Content-Type">Section&nbsp;6.8</a></td>
    905                </tr>
    906                <tr>
    907                   <td class="left">Expires</td>
    908                   <td class="left"><a href="p6-cache.html#header.expires" title="Expires">Section 3.3</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a></td>
    909                </tr>
    910                <tr>
    911                   <td class="left">Last-Modified</td>
    912                   <td class="left"><a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.1</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td>
    913                </tr>
    914             </tbody>
    915          </table>
     901      <div id="representation">
     902         <div id="rfc.iref.r.1"></div>
     903         <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a href="#representation">Representation</a></h1>
     904         <p id="rfc.section.4.p.1">A "<dfn>representation</dfn>" is information in a format that can be readily communicated from one party to another. A resource representation is information
     905            that reflects the state of that resource, as observed at some point in the past (e.g., in a response to GET) or to be desired
     906            at some point in the future (e.g., in a PUT request).
     907         </p>
     908         <p id="rfc.section.4.p.2">Most, but not all, representations transferred via HTTP are intended to be a representation of the target resource (the resource
     909            identified by the effective request URI). The precise semantics of a representation are determined by the type of message
     910            (request or response), the request method, the response status code, and the representation metadata. For example, the above
     911            semantic is true for the representation in any 200 (OK) response to GET and for the representation in any PUT request. A 200
     912            response to PUT, in contrast, contains either a representation that describes the successful action or a representation of
     913            the target resource, with the latter indicated by a Content-Location header field with the same value as the effective request
     914            URI. Likewise, response messages with an error status code usually contain a representation that describes the error and what
     915            next steps are suggested for resolving it.
     916         </p>
     917         <div id="representation.header.fields">
     918            <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a href="#representation.header.fields">Representation Header Fields</a></h2>
     919            <p id="rfc.section.4.1.p.1">Representation header fields define metadata about the representation data enclosed in the message-body or, if no message-body
     920               is present, about the representation that would have been transferred in a 200 response to a simultaneous GET request with
     921               the same effective request URI.
     922            </p>
     923            <p id="rfc.section.4.1.p.2">The following header fields are defined as representation metadata:</p>
     924            <div id="rfc.table.u.2">
     925               <table class="tt full left" cellpadding="3" cellspacing="0">
     926                  <thead>
     927                     <tr>
     928                        <th>Header Field Name</th>
     929                        <th>Defined in...</th>
     930                     </tr>
     931                  </thead>
     932                  <tbody>
     933                     <tr>
     934                        <td class="left">Content-Encoding</td>
     935                        <td class="left"><a href="#header.content-encoding" id="rfc.xref.header.content-encoding.2" title="Content-Encoding">Section&nbsp;6.5</a></td>
     936                     </tr>
     937                     <tr>
     938                        <td class="left">Content-Language</td>
     939                        <td class="left"><a href="#header.content-language" id="rfc.xref.header.content-language.1" title="Content-Language">Section&nbsp;6.6</a></td>
     940                     </tr>
     941                     <tr>
     942                        <td class="left">Content-Location</td>
     943                        <td class="left"><a href="#header.content-location" id="rfc.xref.header.content-location.1" title="Content-Location">Section&nbsp;6.7</a></td>
     944                     </tr>
     945                     <tr>
     946                        <td class="left">Content-Type</td>
     947                        <td class="left"><a href="#header.content-type" id="rfc.xref.header.content-type.2" title="Content-Type">Section&nbsp;6.8</a></td>
     948                     </tr>
     949                     <tr>
     950                        <td class="left">Expires</td>
     951                        <td class="left"><a href="p6-cache.html#header.expires" title="Expires">Section 3.3</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a></td>
     952                     </tr>
     953                     <tr>
     954                        <td class="left">Last-Modified</td>
     955                        <td class="left"><a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.1</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a></td>
     956                     </tr>
     957                  </tbody>
     958               </table>
     959            </div>
     960         </div>
     961         <div id="representation.data">
     962            <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a href="#representation.data">Representation Data</a></h2>
     963            <p id="rfc.section.4.2.p.1">The representation body associated with an HTTP message is either provided as the payload body of the message or referred
     964               to by the message semantics and the effective request URI. The representation data is in a format and encoding defined by
     965               the representation metadata header fields.
     966            </p>
     967            <p id="rfc.section.4.2.p.2">The data type of the representation data is determined via the header fields Content-Type and Content-Encoding. These define
     968               a two-layer, ordered encoding model:
     969            </p>
     970            <div id="rfc.figure.u.9"></div><pre class="text">  representation-data := Content-Encoding( Content-Type( bits ) )
     971</pre><p id="rfc.section.4.2.p.4">Content-Type specifies the media type of the underlying data, which defines both the data format and how that data <em class="bcp14">SHOULD</em> be processed by the recipient (within the scope of the request method semantics). Any HTTP/1.1 message containing a payload
     972               body <em class="bcp14">SHOULD</em> include a Content-Type header field defining the media type of the associated representation unless that metadata is unknown
     973               to the sender. If the Content-Type header field is not present, it indicates that the sender does not know the media type
     974               of the representation; recipients <em class="bcp14">MAY</em> either assume that the media type is "application/octet-stream" (<a href="#RFC2046" id="rfc.xref.RFC2046.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, <a href="https://tools.ietf.org/html/rfc2046#section-4.5.1">Section 4.5.1</a>) or examine the content to determine its type.
     975            </p>
     976            <p id="rfc.section.4.2.p.5">In practice, resource owners do not always properly configure their origin server to provide the correct Content-Type for
     977               a given representation, with the result that some clients will examine a response body's content and override the specified
     978               type. Clients that do so risk drawing incorrect conclusions, which might expose additional security risks (e.g., "privilege
     979               escalation"). Furthermore, it is impossible to determine the sender's intent by examining the data format: many data formats
     980               match multiple media types that differ only in processing semantics. Implementers are encouraged to provide a means of disabling
     981               such "content sniffing" when it is used.
     982            </p>
     983            <p id="rfc.section.4.2.p.6">Content-Encoding is used to indicate any additional content codings applied to the data, usually for the purpose of data compression,
     984               that are a property of the representation. If Content-Encoding is not present, then there is no additional encoding beyond
     985               that defined by the Content-Type.
     986            </p>
     987         </div>
    916988      </div>
    917       <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="representation.data" href="#representation.data">Representation Data</a></h2>
    918       <p id="rfc.section.4.2.p.1">The representation body associated with an HTTP message is either provided as the payload body of the message or referred
    919          to by the message semantics and the effective request URI. The representation data is in a format and encoding defined by
    920          the representation metadata header fields.
    921       </p>
    922       <p id="rfc.section.4.2.p.2">The data type of the representation data is determined via the header fields Content-Type and Content-Encoding. These define
    923          a two-layer, ordered encoding model:
    924       </p>
    925       <div id="rfc.figure.u.9"></div><pre class="text">  representation-data := Content-Encoding( Content-Type( bits ) )
    926 </pre><p id="rfc.section.4.2.p.4">Content-Type specifies the media type of the underlying data, which defines both the data format and how that data <em class="bcp14">SHOULD</em> be processed by the recipient (within the scope of the request method semantics). Any HTTP/1.1 message containing a payload
    927          body <em class="bcp14">SHOULD</em> include a Content-Type header field defining the media type of the associated representation unless that metadata is unknown
    928          to the sender. If the Content-Type header field is not present, it indicates that the sender does not know the media type
    929          of the representation; recipients <em class="bcp14">MAY</em> either assume that the media type is "application/octet-stream" (<a href="#RFC2046" id="rfc.xref.RFC2046.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, <a href="http://tools.ietf.org/html/rfc2046#section-4.5.1">Section 4.5.1</a>) or examine the content to determine its type.
    930       </p>
    931       <p id="rfc.section.4.2.p.5">In practice, resource owners do not always properly configure their origin server to provide the correct Content-Type for
    932          a given representation, with the result that some clients will examine a response body's content and override the specified
    933          type. Clients that do so risk drawing incorrect conclusions, which might expose additional security risks (e.g., "privilege
    934          escalation"). Furthermore, it is impossible to determine the sender's intent by examining the data format: many data formats
    935          match multiple media types that differ only in processing semantics. Implementers are encouraged to provide a means of disabling
    936          such "content sniffing" when it is used.
    937       </p>
    938       <p id="rfc.section.4.2.p.6">Content-Encoding is used to indicate any additional content codings applied to the data, usually for the purpose of data compression,
    939          that are a property of the representation. If Content-Encoding is not present, then there is no additional encoding beyond
    940          that defined by the Content-Type.
    941       </p>
    942       <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="content.negotiation" href="#content.negotiation">Content Negotiation</a></h1>
    943       <p id="rfc.section.5.p.1">HTTP responses include a representation which contains information for interpretation, whether by a human user or for further
    944          processing. Often, the server has different ways of representing the same information; for example, in different formats,
    945          languages, or using different character encodings.
    946       </p>
    947       <p id="rfc.section.5.p.2">HTTP clients and their users might have different or variable capabilities, characteristics or preferences which would influence
    948          which representation, among those available from the server, would be best for the server to deliver. For this reason, HTTP
    949          provides mechanisms for "content negotiation" — a process of allowing selection of a representation of a given resource, when
    950          more than one is available.
    951       </p>
    952       <p id="rfc.section.5.p.3">This specification defines two patterns of content negotiation; "server-driven", where the server selects the representation
    953          based upon the client's stated preferences, and "agent-driven" negotiation, where the server provides a list of representations
    954          for the client to choose from, based upon their metadata. In addition, there are other patterns: some applications use an
    955          "active content" pattern, where the server returns active content which runs on the client and, based on client available
    956          parameters, selects additional resources to invoke. "Transparent Content Negotiation" (<a href="#RFC2295" id="rfc.xref.RFC2295.1"><cite title="Transparent Content Negotiation in HTTP">[RFC2295]</cite></a>) has also been proposed.
    957       </p>
    958       <p id="rfc.section.5.p.4">These patterns are all widely used, and have trade-offs in applicability and practicality. In particular, when the number
    959          of preferences or capabilities to be expressed by a client are large (such as when many different formats are supported by
    960          a user-agent), server-driven negotiation becomes unwieldy, and might not be appropriate. Conversely, when the number of representations
    961          to choose from is very large, agent-driven negotiation might not be appropriate.
    962       </p>
    963       <p id="rfc.section.5.p.5">Note that in all cases, the supplier of representations has the responsibility for determining which representations might
    964          be considered to be the "same information".
    965       </p>
    966       <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;<a id="server-driven.negotiation" href="#server-driven.negotiation">Server-driven Negotiation</a></h2>
    967       <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
    968          negotiation. Selection is based on the available representations of the response (the dimensions over which it can vary; e.g.,
    969          language, content-coding, etc.) and the contents of particular header fields in the request message or on other information
    970          pertaining to the request (such as the network address of the client).
    971       </p>
    972       <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
    973          to describe to the user agent, or when the server desires to send its "best guess" to the client along with the first response
    974          (hoping to avoid the round-trip delay of a subsequent request if the "best guess" is good enough for the user). In order to
    975          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.
    976       </p>
    977       <p id="rfc.section.5.1.p.3">Server-driven negotiation has disadvantages: </p>
    978       <ol>
    979          <li>It is impossible for the server to accurately determine what might be "best" for any given user, since that would require
    980             complete knowledge of both the capabilities of the user agent and the intended use for the response (e.g., does the user want
    981             to view it on screen or print it on paper?).
    982          </li>
    983          <li>Having the user agent describe its capabilities in every request can be both very inefficient (given that only a small percentage
    984             of responses have multiple representations) and a potential violation of the user's privacy.
    985          </li>
    986          <li>It complicates the implementation of an origin server and the algorithms for generating responses to a request.</li>
    987          <li>It might limit a public cache's ability to use the same response for multiple user's requests.</li>
    988       </ol>
    989       <p id="rfc.section.5.1.p.4">HTTP/1.1 includes the following header fields for enabling server-driven negotiation through description of user agent capabilities
    990          and user preferences: Accept (<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section&nbsp;6.1</a>), Accept-Charset (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section&nbsp;6.2</a>), Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section&nbsp;6.3</a>), Accept-Language (<a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section&nbsp;6.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.1"><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 aspects of the connection (e.g., IP address) or information
    991          within extension header fields not defined by this specification.
    992       </p>
    993       <div class="note" id="rfc.section.5.1.p.5">
    994          <p> <b>Note:</b> In practice, User-Agent based negotiation is fragile, because new clients might not be recognized.
    995          </p>
     989      <div id="content.negotiation">
     990         <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a href="#content.negotiation">Content Negotiation</a></h1>
     991         <p id="rfc.section.5.p.1">HTTP responses include a representation which contains information for interpretation, whether by a human user or for further
     992            processing. Often, the server has different ways of representing the same information; for example, in different formats,
     993            languages, or using different character encodings.
     994         </p>
     995         <p id="rfc.section.5.p.2">HTTP clients and their users might have different or variable capabilities, characteristics or preferences which would influence
     996            which representation, among those available from the server, would be best for the server to deliver. For this reason, HTTP
     997            provides mechanisms for "content negotiation" — a process of allowing selection of a representation of a given resource, when
     998            more than one is available.
     999         </p>
     1000         <p id="rfc.section.5.p.3">This specification defines two patterns of content negotiation; "server-driven", where the server selects the representation
     1001            based upon the client's stated preferences, and "agent-driven" negotiation, where the server provides a list of representations
     1002            for the client to choose from, based upon their metadata. In addition, there are other patterns: some applications use an
     1003            "active content" pattern, where the server returns active content which runs on the client and, based on client available
     1004            parameters, selects additional resources to invoke. "Transparent Content Negotiation" (<a href="#RFC2295" id="rfc.xref.RFC2295.1"><cite title="Transparent Content Negotiation in HTTP">[RFC2295]</cite></a>) has also been proposed.
     1005         </p>
     1006         <p id="rfc.section.5.p.4">These patterns are all widely used, and have trade-offs in applicability and practicality. In particular, when the number
     1007            of preferences or capabilities to be expressed by a client are large (such as when many different formats are supported by
     1008            a user-agent), server-driven negotiation becomes unwieldy, and might not be appropriate. Conversely, when the number of representations
     1009            to choose from is very large, agent-driven negotiation might not be appropriate.
     1010         </p>
     1011         <p id="rfc.section.5.p.5">Note that in all cases, the supplier of representations has the responsibility for determining which representations might
     1012            be considered to be the "same information".
     1013         </p>
     1014         <div id="server-driven.negotiation">
     1015            <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;<a href="#server-driven.negotiation">Server-driven Negotiation</a></h2>
     1016            <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
     1017               negotiation. Selection is based on the available representations of the response (the dimensions over which it can vary; e.g.,
     1018               language, content-coding, etc.) and the contents of particular header fields in the request message or on other information
     1019               pertaining to the request (such as the network address of the client).
     1020            </p>
     1021            <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
     1022               to describe to the user agent, or when the server desires to send its "best guess" to the client along with the first response
     1023               (hoping to avoid the round-trip delay of a subsequent request if the "best guess" is good enough for the user). In order to
     1024               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.
     1025            </p>
     1026            <p id="rfc.section.5.1.p.3">Server-driven negotiation has disadvantages: </p>
     1027            <ol>
     1028               <li>It is impossible for the server to accurately determine what might be "best" for any given user, since that would require
     1029                  complete knowledge of both the capabilities of the user agent and the intended use for the response (e.g., does the user want
     1030                  to view it on screen or print it on paper?).
     1031               </li>
     1032               <li>Having the user agent describe its capabilities in every request can be both very inefficient (given that only a small percentage
     1033                  of responses have multiple representations) and a potential violation of the user's privacy.
     1034               </li>
     1035               <li>It complicates the implementation of an origin server and the algorithms for generating responses to a request.</li>
     1036               <li>It might limit a public cache's ability to use the same response for multiple user's requests.</li>
     1037            </ol>
     1038            <p id="rfc.section.5.1.p.4">HTTP/1.1 includes the following header fields for enabling server-driven negotiation through description of user agent capabilities
     1039               and user preferences: Accept (<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section&nbsp;6.1</a>), Accept-Charset (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section&nbsp;6.2</a>), Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section&nbsp;6.3</a>), Accept-Language (<a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section&nbsp;6.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.1"><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 aspects of the connection (e.g., IP address) or information
     1040               within extension header fields not defined by this specification.
     1041            </p>
     1042            <div class="note" id="rfc.section.5.1.p.5">
     1043               <p><b>Note:</b> In practice, User-Agent based negotiation is fragile, because new clients might not be recognized.
     1044               </p>
     1045            </div>
     1046            <p id="rfc.section.5.1.p.6">The Vary header field (<a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.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.
     1047            </p>
     1048         </div>
     1049         <div id="agent-driven.negotiation">
     1050            <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a>&nbsp;<a href="#agent-driven.negotiation">Agent-driven Negotiation</a></h2>
     1051            <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
     1052               an initial response from the origin server. Selection is based on a list of the available representations of the response
     1053               included within the header fields or body of the initial response, with each representation identified by its own URI. Selection
     1054               from among the representations can be performed automatically (if the user agent is capable of doing so) or manually by the
     1055               user selecting from a generated (possibly hypertext) menu.
     1056            </p>
     1057            <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,
     1058               or encoding), when the origin server is unable to determine a user agent's capabilities from examining the request, and generally
     1059               when public caches are used to distribute server load and reduce network usage.
     1060            </p>
     1061            <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.
     1062               This second request is only efficient when caching is used. In addition, this specification does not define any mechanism
     1063               for supporting automatic selection, though it also does not prevent any such mechanism from being developed as an extension
     1064               and used within HTTP/1.1.
     1065            </p>
     1066            <p id="rfc.section.5.2.p.4">This specification defines the 300 (Multiple Choices) and 406 (Not Acceptable) status codes for enabling agent-driven negotiation
     1067               when the server is unwilling or unable to provide a varying response using server-driven negotiation.
     1068            </p>
     1069         </div>
    9961070      </div>
    997       <p id="rfc.section.5.1.p.6">The Vary header field (<a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.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.
    998       </p>
    999       <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a>&nbsp;<a id="agent-driven.negotiation" href="#agent-driven.negotiation">Agent-driven Negotiation</a></h2>
    1000       <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
    1001          an initial response from the origin server. Selection is based on a list of the available representations of the response
    1002          included within the header fields or body of the initial response, with each representation identified by its own URI. Selection
    1003          from among the representations can be performed automatically (if the user agent is capable of doing so) or manually by the
    1004          user selecting from a generated (possibly hypertext) menu.
    1005       </p>
    1006       <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,
    1007          or encoding), when the origin server is unable to determine a user agent's capabilities from examining the request, and generally
    1008          when public caches are used to distribute server load and reduce network usage.
    1009       </p>
    1010       <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.
    1011          This second request is only efficient when caching is used. In addition, this specification does not define any mechanism
    1012          for supporting automatic selection, though it also does not prevent any such mechanism from being developed as an extension
    1013          and used within HTTP/1.1.
    1014       </p>
    1015       <p id="rfc.section.5.2.p.4">This specification defines the 300 (Multiple Choices) and 406 (Not Acceptable) status codes for enabling agent-driven negotiation
    1016          when the server is unwilling or unable to provide a varying response using server-driven negotiation.
    1017       </p>
    1018       <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
    1019       <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>
    1020       <div id="rfc.iref.a.1"></div>
    1021       <div id="rfc.iref.h.1"></div>
    1022       <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="header.accept" href="#header.accept">Accept</a></h2>
    1023       <p id="rfc.section.6.1.p.1">The "Accept" header field can be used by user agents to specify response media types that are acceptable. Accept header fields
    1024          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
    1025          for an in-line image.
    1026       </p>
    1027       <div id="rfc.figure.u.10"></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><span id="rfc.iref.g.14"></span>  <a href="#header.accept" class="smpl">Accept</a> = #( <a href="#header.accept" class="smpl">media-range</a> [ <a href="#header.accept" class="smpl">accept-params</a> ] )
     1071      <div id="header.fields">
     1072         <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a href="#header.fields">Header Field Definitions</a></h1>
     1073         <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>
     1074         <div id="header.accept">
     1075            <div id="rfc.iref.a.1"></div>
     1076            <div id="rfc.iref.h.1"></div>
     1077            <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a href="#header.accept">Accept</a></h2>
     1078            <p id="rfc.section.6.1.p.1">The "Accept" header field can be used by user agents to specify response media types that are acceptable. Accept header fields
     1079               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
     1080               for an in-line image.
     1081            </p>
     1082            <div id="rfc.figure.u.10"></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><span id="rfc.iref.g.14"></span>  <a href="#header.accept" class="smpl">Accept</a> = #( <a href="#header.accept" class="smpl">media-range</a> [ <a href="#header.accept" class="smpl">accept-params</a> ] )
    10281083 
    10291084  <a href="#header.accept" class="smpl">media-range</a>    = ( "*/*"
     
    10341089  <a href="#header.accept" class="smpl">accept-ext</a>     = <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> <a href="#core.rules" class="smpl">token</a> [ "=" <a href="#core.rules" class="smpl">word</a> ]
    10351090</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
    1036          all subtypes of that type. The media-range <em class="bcp14">MAY</em> include media type parameters that are applicable to that range.
    1037       </p>
    1038       <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
    1039          "q" parameter (if any) separates the media-range parameter(s) from the accept-params. Quality factors allow the user or user
    1040          agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (<a href="p1-messaging.html#quality.values" title="Quality Values">Section 6.4</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The default value is q=1.
    1041       </p>
    1042       <div class="note" id="rfc.section.6.1.p.5">
    1043          <p> <b>Note:</b> Use of the "q" parameter name to separate media type parameters from Accept extension parameters is due to historical practice.
    1044             Although this prevents any media type parameter named "q" from being used with a media range, such an event is believed to
    1045             be unlikely given the lack of any "q" parameters in the IANA media type registry and the rare usage of any media type parameters
    1046             in Accept. Future media types are discouraged from registering any parameter named "q".
    1047          </p>
    1048       </div>
    1049       <p id="rfc.section.6.1.p.6">The example</p>
    1050       <div id="rfc.figure.u.11"></div><pre class="text">  Accept: audio/*; q=0.2, audio/basic
    1051 </pre><p id="rfc.section.6.1.p.8"> <em class="bcp14">SHOULD</em> be interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% mark-down in
    1052          quality".
    1053       </p>
    1054       <p id="rfc.section.6.1.p.9">If no Accept header field is present, then it is assumed that the client accepts all media types. If an Accept header field
    1055          is present, and if the server cannot send a response which is acceptable according to the combined Accept field value, then
    1056          the server <em class="bcp14">SHOULD</em> send a 406 (Not Acceptable) response.
    1057       </p>
    1058       <p id="rfc.section.6.1.p.10">A more elaborate example is</p>
    1059       <div id="rfc.figure.u.12"></div><pre class="text">  Accept: text/plain; q=0.5, text/html,
     1091               all subtypes of that type. The media-range <em class="bcp14">MAY</em> include media type parameters that are applicable to that range.
     1092            </p>
     1093            <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
     1094               "q" parameter (if any) separates the media-range parameter(s) from the accept-params. Quality factors allow the user or user
     1095               agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (<a href="p1-messaging.html#quality.values" title="Quality Values">Section 6.4</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The default value is q=1.
     1096            </p>
     1097            <div class="note" id="rfc.section.6.1.p.5">
     1098               <p><b>Note:</b> Use of the "q" parameter name to separate media type parameters from Accept extension parameters is due to historical practice.
     1099                  Although this prevents any media type parameter named "q" from being used with a media range, such an event is believed to
     1100                  be unlikely given the lack of any "q" parameters in the IANA media type registry and the rare usage of any media type parameters
     1101                  in Accept. Future media types are discouraged from registering any parameter named "q".
     1102               </p>
     1103            </div>
     1104            <p id="rfc.section.6.1.p.6">The example</p>
     1105            <div id="rfc.figure.u.11"></div><pre class="text">  Accept: audio/*; q=0.2, audio/basic
     1106</pre><p id="rfc.section.6.1.p.8"><em class="bcp14">SHOULD</em> be interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% mark-down in
     1107               quality".
     1108            </p>
     1109            <p id="rfc.section.6.1.p.9">If no Accept header field is present, then it is assumed that the client accepts all media types. If an Accept header field
     1110               is present, and if the server cannot send a response which is acceptable according to the combined Accept field value, then
     1111               the server <em class="bcp14">SHOULD</em> send a 406 (Not Acceptable) response.
     1112            </p>
     1113            <p id="rfc.section.6.1.p.10">A more elaborate example is</p>
     1114            <div id="rfc.figure.u.12"></div><pre class="text">  Accept: text/plain; q=0.5, text/html,
    10601115          text/x-dvi; q=0.8, text/x-c
    10611116</pre><p id="rfc.section.6.1.p.12">Verbally, this would be interpreted as "text/html and text/x-c are the preferred media types, but if they do not exist, then
    1062          send the text/x-dvi representation, and if that does not exist, send the text/plain representation".
    1063       </p>
    1064       <p id="rfc.section.6.1.p.13">Media ranges can be overridden by more specific media ranges or specific media types. If more than one media range applies
    1065          to a given type, the most specific reference has precedence. For example,
    1066       </p>
    1067       <div id="rfc.figure.u.13"></div><pre class="text">  Accept: text/*, text/plain, text/plain;format=flowed, */*
     1117               send the text/x-dvi representation, and if that does not exist, send the text/plain representation".
     1118            </p>
     1119            <p id="rfc.section.6.1.p.13">Media ranges can be overridden by more specific media ranges or specific media types. If more than one media range applies
     1120               to a given type, the most specific reference has precedence. For example,
     1121            </p>
     1122            <div id="rfc.figure.u.13"></div><pre class="text">  Accept: text/*, text/plain, text/plain;format=flowed, */*
    10681123</pre><p id="rfc.section.6.1.p.15">have the following precedence: </p>
    1069       <ol>
    1070          <li>text/plain;format=flowed</li>
    1071          <li>text/plain</li>
    1072          <li>text/*</li>
    1073          <li>*/*</li>
    1074       </ol>
    1075       <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
    1076          which matches that type. For example,
    1077       </p>
    1078       <div id="rfc.figure.u.14"></div><pre class="text">  Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
     1124            <ol>
     1125               <li>text/plain;format=flowed</li>
     1126               <li>text/plain</li>
     1127               <li>text/*</li>
     1128               <li>*/*</li>
     1129            </ol>
     1130            <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
     1131               which matches that type. For example,
     1132            </p>
     1133            <div id="rfc.figure.u.14"></div><pre class="text">  Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
    10791134          text/html;level=2;q=0.4, */*;q=0.5
    10801135</pre><p id="rfc.section.6.1.p.18">would cause the following values to be associated:</p>
    1081       <div id="rfc.table.u.3">
    1082          <table class="tt full left" cellpadding="3" cellspacing="0">
    1083             <thead>
    1084                <tr>
    1085                   <th>Media Type</th>
    1086                   <th>Quality Value</th>
    1087                </tr>
    1088             </thead>
    1089             <tbody>
    1090                <tr>
    1091                   <td class="left">text/html;level=1</td>
    1092                   <td class="left">1</td>
    1093                </tr>
    1094                <tr>
    1095                   <td class="left">text/html</td>
    1096                   <td class="left">0.7</td>
    1097                </tr>
    1098                <tr>
    1099                   <td class="left">text/plain</td>
    1100                   <td class="left">0.3</td>
    1101                </tr>
    1102                <tr>
    1103                   <td class="left">image/jpeg</td>
    1104                   <td class="left">0.5</td>
    1105                </tr>
    1106                <tr>
    1107                   <td class="left">text/html;level=2</td>
    1108                   <td class="left">0.4</td>
    1109                </tr>
    1110                <tr>
    1111                   <td class="left">text/html;level=3</td>
    1112                   <td class="left">0.7</td>
    1113                </tr>
    1114             </tbody>
    1115          </table>
    1116       </div>
    1117       <p id="rfc.section.6.1.p.19"> <b>Note:</b> A user agent might be provided with a default set of quality values for certain media ranges. However, unless the user agent
    1118          is a closed system which cannot interact with other rendering agents, this default set ought to be configurable by the user.
    1119       </p>
    1120       <div id="rfc.iref.a.2"></div>
    1121       <div id="rfc.iref.h.2"></div>
    1122       <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<a id="header.accept-charset" href="#header.accept-charset">Accept-Charset</a></h2>
    1123       <p id="rfc.section.6.2.p.1">The "Accept-Charset" header field can be used by user agents to indicate what character encodings are acceptable in a response
    1124          payload. This field allows clients capable of understanding more comprehensive or special-purpose character encodings to signal
    1125          that capability to a server which is capable of representing documents in those character encodings.
    1126       </p>
    1127       <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.15"></span>  <a href="#header.accept-charset" class="smpl">Accept-Charset</a> = 1#( ( <a href="#rule.charset" class="smpl">charset</a> / "*" )
     1136            <div id="rfc.table.u.3">
     1137               <table class="tt full left" cellpadding="3" cellspacing="0">
     1138                  <thead>
     1139                     <tr>
     1140                        <th>Media Type</th>
     1141                        <th>Quality Value</th>
     1142                     </tr>
     1143                  </thead>
     1144                  <tbody>
     1145                     <tr>
     1146                        <td class="left">text/html;level=1</td>
     1147                        <td class="left">1</td>
     1148                     </tr>
     1149                     <tr>
     1150                        <td class="left">text/html</td>
     1151                        <td class="left">0.7</td>
     1152                     </tr>
     1153                     <tr>
     1154                        <td class="left">text/plain</td>
     1155                        <td class="left">0.3</td>
     1156                     </tr>
     1157                     <tr>
     1158                        <td class="left">image/jpeg</td>
     1159                        <td class="left">0.5</td>
     1160                     </tr>
     1161                     <tr>
     1162                        <td class="left">text/html;level=2</td>
     1163                        <td class="left">0.4</td>
     1164                     </tr>
     1165                     <tr>
     1166                        <td class="left">text/html;level=3</td>
     1167                        <td class="left">0.7</td>
     1168                     </tr>
     1169                  </tbody>
     1170               </table>
     1171            </div>
     1172            <p id="rfc.section.6.1.p.19"><b>Note:</b> A user agent might be provided with a default set of quality values for certain media ranges. However, unless the user agent
     1173               is a closed system which cannot interact with other rendering agents, this default set ought to be configurable by the user.
     1174            </p>
     1175         </div>
     1176         <div id="header.accept-charset">
     1177            <div id="rfc.iref.a.2"></div>
     1178            <div id="rfc.iref.h.2"></div>
     1179            <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<a href="#header.accept-charset">Accept-Charset</a></h2>
     1180            <p id="rfc.section.6.2.p.1">The "Accept-Charset" header field can be used by user agents to indicate what character encodings are acceptable in a response
     1181               payload. This field allows clients capable of understanding more comprehensive or special-purpose character encodings to signal
     1182               that capability to a server which is capable of representing documents in those character encodings.
     1183            </p>
     1184            <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.15"></span>  <a href="#header.accept-charset" class="smpl">Accept-Charset</a> = 1#( ( <a href="#rule.charset" class="smpl">charset</a> / "*" )
    11281185                         [ <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> "q=" <a href="#abnf.dependencies" class="smpl">qvalue</a> ] )
    11291186</pre><p id="rfc.section.6.2.p.3">Character encoding values (a.k.a., charsets) are described in <a href="#character.sets" title="Character Encodings (charset)">Section&nbsp;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. An
    1130          example is
    1131       </p>
    1132       <div id="rfc.figure.u.16"></div><pre class="text">  Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
     1187               example is
     1188            </p>
     1189            <div id="rfc.figure.u.16"></div><pre class="text">  Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
    11331190</pre><p id="rfc.section.6.2.p.5">The special value "*", if present in the Accept-Charset field, matches every character encoding which is not mentioned elsewhere
    1134          in the Accept-Charset field. If no "*" is present in an Accept-Charset field, then all character encodings not explicitly
    1135          mentioned get a quality value of 0.
    1136       </p>
    1137       <p id="rfc.section.6.2.p.6">If no Accept-Charset header field is present, the default is that any character encoding is acceptable. If an Accept-Charset
    1138          header field is present, and if the server cannot send a response which is acceptable according to the Accept-Charset header
    1139          field, 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.
    1140       </p>
    1141       <div id="rfc.iref.a.3"></div>
    1142       <div id="rfc.iref.h.3"></div>
    1143       <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a>&nbsp;<a id="header.accept-encoding" href="#header.accept-encoding">Accept-Encoding</a></h2>
    1144       <p id="rfc.section.6.3.p.1">The "Accept-Encoding" header field can be used by user agents to indicate what response content-codings (<a href="#content.codings" title="Content Codings">Section&nbsp;2.2</a>) are acceptable in the response.
    1145       </p>
    1146       <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span>  <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a>  = #( <a href="#header.accept-encoding" class="smpl">codings</a> [ <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> "q=" <a href="#abnf.dependencies" class="smpl">qvalue</a> ] )
     1191               in the Accept-Charset field. If no "*" is present in an Accept-Charset field, then all character encodings not explicitly
     1192               mentioned get a quality value of 0.
     1193            </p>
     1194            <p id="rfc.section.6.2.p.6">If no Accept-Charset header field is present, the default is that any character encoding is acceptable. If an Accept-Charset
     1195               header field is present, and if the server cannot send a response which is acceptable according to the Accept-Charset header
     1196               field, 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.
     1197            </p>
     1198         </div>
     1199         <div id="header.accept-encoding">
     1200            <div id="rfc.iref.a.3"></div>
     1201            <div id="rfc.iref.h.3"></div>
     1202            <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a>&nbsp;<a href="#header.accept-encoding">Accept-Encoding</a></h2>
     1203            <p id="rfc.section.6.3.p.1">The "Accept-Encoding" header field can be used by user agents to indicate what response content-codings (<a href="#content.codings" title="Content Codings">Section&nbsp;2.2</a>) are acceptable in the response.
     1204            </p>
     1205            <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span>  <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a>  = #( <a href="#header.accept-encoding" class="smpl">codings</a> [ <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> "q=" <a href="#abnf.dependencies" class="smpl">qvalue</a> ] )
    11471206  <a href="#header.accept-encoding" class="smpl">codings</a>          = ( <a href="#content.codings" class="smpl">content-coding</a> / "*" )
    11481207</pre><p id="rfc.section.6.3.p.3">Each codings value <em class="bcp14">MAY</em> be given an associated quality value which represents the preference for that encoding. The default value is q=1.
    1149       </p>
    1150       <p id="rfc.section.6.3.p.4">Examples of its use are:</p>
    1151       <div id="rfc.figure.u.18"></div><pre class="text">  Accept-Encoding: compress, gzip
     1208            </p>
     1209            <p id="rfc.section.6.3.p.4">Examples of its use are:</p>
     1210            <div id="rfc.figure.u.18"></div><pre class="text">  Accept-Encoding: compress, gzip
    11521211  Accept-Encoding:
    11531212  Accept-Encoding: *
     
    11551214  Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
    11561215</pre><p id="rfc.section.6.3.p.6">A server tests whether a content-coding is acceptable, according to an Accept-Encoding field, using these rules: </p>
    1157       <ol>
    1158          <li>If the content-coding is one of the content-codings listed in the Accept-Encoding field, then it is acceptable, unless it
    1159             is accompanied by a qvalue of 0. (As defined in <a href="p1-messaging.html#quality.values" title="Quality Values">Section 6.4</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, a qvalue of 0 means "not acceptable".)
    1160          </li>
    1161          <li>The special "*" symbol in an Accept-Encoding field matches any available content-coding not explicitly listed in the header
    1162             field.
    1163          </li>
    1164          <li>If multiple content-codings are acceptable, then the acceptable content-coding with the highest non-zero qvalue is preferred.</li>
    1165          <li>The "identity" content-coding is always acceptable, unless specifically refused because the Accept-Encoding field includes
    1166             "identity;q=0", or because the field includes "*;q=0" and does not explicitly include the "identity" content-coding. If the
    1167             Accept-Encoding field-value is empty, then only the "identity" encoding is acceptable.
    1168          </li>
    1169       </ol>
    1170       <p id="rfc.section.6.3.p.7">If an Accept-Encoding field is present in a request, and if the server cannot send a response which is acceptable according
    1171          to the Accept-Encoding header field, then the server <em class="bcp14">SHOULD</em> send an error response with the 406 (Not Acceptable) status code.
    1172       </p>
    1173       <p id="rfc.section.6.3.p.8">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,
    1174          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
    1175          client.
    1176       </p>
    1177       <div class="note" id="rfc.section.6.3.p.9">
    1178          <p> <b>Note:</b> If the request does not include an Accept-Encoding field, and if the "identity" content-coding is unavailable, then content-codings
    1179             commonly understood by HTTP/1.0 clients (i.e., "gzip" and "compress") are preferred; some older clients improperly display
    1180             messages sent with other content-codings. The server might also make this decision based on information about the particular
    1181             user-agent or client.
    1182          </p>
    1183       </div>
    1184       <div class="note" id="rfc.section.6.3.p.10">
    1185          <p> <b>Note:</b> Most HTTP/1.0 applications do not recognize or obey qvalues associated with content-codings. This means that qvalues will
    1186             not work and are not permitted with x-gzip or x-compress.
    1187          </p>
    1188       </div>
    1189       <div id="rfc.iref.a.4"></div>
    1190       <div id="rfc.iref.h.4"></div>
    1191       <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a>&nbsp;<a id="header.accept-language" href="#header.accept-language">Accept-Language</a></h2>
    1192       <p id="rfc.section.6.4.p.1">The "Accept-Language" header field can be used by user agents to indicate the set of natural languages that are preferred
    1193          in the response. Language tags are defined in <a href="#language.tags" title="Language Tags">Section&nbsp;2.4</a>.
    1194       </p>
    1195       <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span>  <a href="#header.accept-language" class="smpl">Accept-Language</a> =
     1216            <ol>
     1217               <li>If the content-coding is one of the content-codings listed in the Accept-Encoding field, then it is acceptable, unless it
     1218                  is accompanied by a qvalue of 0. (As defined in <a href="p1-messaging.html#quality.values" title="Quality Values">Section 6.4</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, a qvalue of 0 means "not acceptable".)
     1219               </li>
     1220               <li>The special "*" symbol in an Accept-Encoding field matches any available content-coding not explicitly listed in the header
     1221                  field.
     1222               </li>
     1223               <li>If multiple content-codings are acceptable, then the acceptable content-coding with the highest non-zero qvalue is preferred.</li>
     1224               <li>The "identity" content-coding is always acceptable, unless specifically refused because the Accept-Encoding field includes
     1225                  "identity;q=0", or because the field includes "*;q=0" and does not explicitly include the "identity" content-coding. If the
     1226                  Accept-Encoding field-value is empty, then only the "identity" encoding is acceptable.
     1227               </li>
     1228            </ol>
     1229            <p id="rfc.section.6.3.p.7">If an Accept-Encoding field is present in a request, and if the server cannot send a response which is acceptable according
     1230               to the Accept-Encoding header field, then the server <em class="bcp14">SHOULD</em> send an error response with the 406 (Not Acceptable) status code.
     1231            </p>
     1232            <p id="rfc.section.6.3.p.8">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,
     1233               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
     1234               client.
     1235            </p>
     1236            <div class="note" id="rfc.section.6.3.p.9">
     1237               <p><b>Note:</b> If the request does not include an Accept-Encoding field, and if the "identity" content-coding is unavailable, then content-codings
     1238                  commonly understood by HTTP/1.0 clients (i.e., "gzip" and "compress") are preferred; some older clients improperly display
     1239                  messages sent with other content-codings. The server might also make this decision based on information about the particular
     1240                  user-agent or client.
     1241               </p>
     1242            </div>
     1243            <div class="note" id="rfc.section.6.3.p.10">
     1244               <p><b>Note:</b> Most HTTP/1.0 applications do not recognize or obey qvalues associated with content-codings. This means that qvalues will
     1245                  not work and are not permitted with x-gzip or x-compress.
     1246               </p>
     1247            </div>
     1248         </div>
     1249         <div id="header.accept-language">
     1250            <div id="rfc.iref.a.4"></div>
     1251            <div id="rfc.iref.h.4"></div>
     1252            <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a>&nbsp;<a href="#header.accept-language">Accept-Language</a></h2>
     1253            <p id="rfc.section.6.4.p.1">The "Accept-Language" header field can be used by user agents to indicate the set of natural languages that are preferred
     1254               in the response. Language tags are defined in <a href="#language.tags" title="Language Tags">Section&nbsp;2.4</a>.
     1255            </p>
     1256            <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span>  <a href="#header.accept-language" class="smpl">Accept-Language</a> =
    11961257                    1#( <a href="#header.accept-language" class="smpl">language-range</a> [ <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> "q=" <a href="#abnf.dependencies" class="smpl">qvalue</a> ] )
    11971258  <a href="#header.accept-language" class="smpl">language-range</a>  =
    1198             &lt;language-range, defined in <a href="#RFC4647" id="rfc.xref.RFC4647.1"><cite title="Matching of Language Tags">[RFC4647]</cite></a>, <a href="http://tools.ietf.org/html/rfc4647#section-2.1">Section 2.1</a>&gt;
     1259            &lt;language-range, defined in <a href="#RFC4647" id="rfc.xref.RFC4647.1"><cite title="Matching of Language Tags">[RFC4647]</cite></a>, <a href="https://tools.ietf.org/html/rfc4647#section-2.1">Section 2.1</a>&gt;
    11991260</pre><p id="rfc.section.6.4.p.3">Each language-range can be given an associated quality value which represents an estimate of the user's preference for the
    1200          languages specified by that range. The quality value defaults to "q=1". For example,
    1201       </p>
    1202       <div id="rfc.figure.u.20"></div><pre class="text">  Accept-Language: da, en-gb;q=0.8, en;q=0.7
    1203 </pre><p id="rfc.section.6.4.p.5">would mean: "I prefer Danish, but will accept British English and other types of English". (see also <a href="http://tools.ietf.org/html/rfc4647#section-2.3">Section 2.3</a> of <a href="#RFC4647" id="rfc.xref.RFC4647.2"><cite title="Matching of Language Tags">[RFC4647]</cite></a>)
    1204       </p>
    1205       <p id="rfc.section.6.4.p.6">For matching, <a href="http://tools.ietf.org/html/rfc4647#section-3">Section 3</a> of <a href="#RFC4647" id="rfc.xref.RFC4647.3"><cite title="Matching of Language Tags">[RFC4647]</cite></a> defines several matching schemes. Implementations can offer the most appropriate matching scheme for their requirements.
    1206       </p>
    1207       <div class="note" id="rfc.section.6.4.p.7">
    1208          <p> <b>Note:</b> The "Basic Filtering" scheme (<a href="#RFC4647" id="rfc.xref.RFC4647.4"><cite title="Matching of Language Tags">[RFC4647]</cite></a>, <a href="http://tools.ietf.org/html/rfc4647#section-3.3.1">Section 3.3.1</a>) is identical to the matching scheme that was previously defined in <a href="http://tools.ietf.org/html/rfc2616#section-14.4">Section 14.4</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.
    1209          </p>
     1261               languages specified by that range. The quality value defaults to "q=1". For example,
     1262            </p>
     1263            <div id="rfc.figure.u.20"></div><pre class="text">  Accept-Language: da, en-gb;q=0.8, en;q=0.7
     1264</pre><p id="rfc.section.6.4.p.5">would mean: "I prefer Danish, but will accept British English and other types of English". (see also <a href="https://tools.ietf.org/html/rfc4647#section-2.3">Section 2.3</a> of <a href="#RFC4647" id="rfc.xref.RFC4647.2"><cite title="Matching of Language Tags">[RFC4647]</cite></a>)
     1265            </p>
     1266            <p id="rfc.section.6.4.p.6">For matching, <a href="https://tools.ietf.org/html/rfc4647#section-3">Section 3</a> of <a href="#RFC4647" id="rfc.xref.RFC4647.3"><cite title="Matching of Language Tags">[RFC4647]</cite></a> defines several matching schemes. Implementations can offer the most appropriate matching scheme for their requirements.
     1267            </p>
     1268            <div class="note" id="rfc.section.6.4.p.7">
     1269               <p><b>Note:</b> The "Basic Filtering" scheme (<a href="#RFC4647" id="rfc.xref.RFC4647.4"><cite title="Matching of Language Tags">[RFC4647]</cite></a>, <a href="https://tools.ietf.org/html/rfc4647#section-3.3.1">Section 3.3.1</a>) is identical to the matching scheme that was previously defined in <a href="https://tools.ietf.org/html/rfc2616#section-14.4">Section 14.4</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.
     1270               </p>
     1271            </div>
     1272            <p id="rfc.section.6.4.p.8">It might be contrary to the privacy expectations of the user to send an Accept-Language header field with the complete linguistic
     1273               preferences of the user in every request. For a discussion of this issue, see <a href="#privacy.issues.connected.to.accept.header.fields" title="Privacy Issues Connected to Accept Header Fields">Section&nbsp;8.1</a>.
     1274            </p>
     1275            <p id="rfc.section.6.4.p.9">As intelligibility is highly dependent on the individual user, it is recommended that client applications make the choice
     1276               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.
     1277            </p>
     1278            <div class="note" id="rfc.section.6.4.p.10">
     1279               <p><b>Note:</b> When making the choice of linguistic preference available to the user, we remind implementors of the fact that users are not
     1280                  familiar with the details of language matching as described above, and ought to be provided appropriate guidance. As an example,
     1281                  users might assume that on selecting "en-gb", they will be served any kind of English document if British English is not available.
     1282                  A user agent might suggest in such a case to add "en" to get the best matching behavior.
     1283               </p>
     1284            </div>
     1285         </div>
     1286         <div id="header.content-encoding">
     1287            <div id="rfc.iref.c.7"></div>
     1288            <div id="rfc.iref.h.5"></div>
     1289            <h2 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a>&nbsp;<a href="#header.content-encoding">Content-Encoding</a></h2>
     1290            <p id="rfc.section.6.5.p.1">The "Content-Encoding" header field indicates what content-codings have been applied to the representation, and thus what
     1291               decoding mechanisms must be applied in order to obtain the media-type referenced by the Content-Type header field. Content-Encoding
     1292               is primarily used to allow a representation to be compressed without losing the identity of its underlying media type.
     1293            </p>
     1294            <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.20"></span>  <a href="#header.content-encoding" class="smpl">Content-Encoding</a> = 1#<a href="#content.codings" class="smpl">content-coding</a>
     1295</pre><p id="rfc.section.6.5.p.3">Content codings are defined in <a href="#content.codings" title="Content Codings">Section&nbsp;2.2</a>. An example of its use is
     1296            </p>
     1297            <div id="rfc.figure.u.22"></div><pre class="text">  Content-Encoding: gzip
     1298</pre><p id="rfc.section.6.5.p.5">The content-coding is a characteristic of the representation. Typically, the representation body is stored with this encoding
     1299               and is only decoded before rendering or analogous usage. However, a transforming proxy <em class="bcp14">MAY</em> modify the content-coding if the new coding is known to be acceptable to the recipient, unless the "no-transform" cache-control
     1300               directive is present in the message.
     1301            </p>
     1302            <p id="rfc.section.6.5.p.6">If the content-coding of a representation is not "identity", then the representation metadata <em class="bcp14">MUST</em> include a Content-Encoding header field (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.3" title="Content-Encoding">Section&nbsp;6.5</a>) that lists the non-identity content-coding(s) used.
     1303            </p>
     1304            <p id="rfc.section.6.5.p.7">If the content-coding of a representation in a request message is not acceptable to the origin server, the server <em class="bcp14">SHOULD</em> respond with a status code of 415 (Unsupported Media Type).
     1305            </p>
     1306            <p id="rfc.section.6.5.p.8">If multiple encodings have been applied to a representation, the content codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
     1307            </p>
     1308         </div>
     1309         <div id="header.content-language">
     1310            <div id="rfc.iref.c.8"></div>
     1311            <div id="rfc.iref.h.6"></div>
     1312            <h2 id="rfc.section.6.6"><a href="#rfc.section.6.6">6.6</a>&nbsp;<a href="#header.content-language">Content-Language</a></h2>
     1313            <p id="rfc.section.6.6.p.1">The "Content-Language" header field describes the natural language(s) of the intended audience for the representation. Note
     1314               that this might not be equivalent to all the languages used within the representation.
     1315            </p>
     1316            <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.21"></span>  <a href="#header.content-language" class="smpl">Content-Language</a> = 1#<a href="#language.tags" class="smpl">language-tag</a>
     1317</pre><p id="rfc.section.6.6.p.3">Language tags are defined in <a href="#language.tags" title="Language Tags">Section&nbsp;2.4</a>. The primary purpose of Content-Language is to allow a user to identify and differentiate representations according to the
     1318               user's own preferred language. Thus, if the body content is intended only for a Danish-literate audience, the appropriate
     1319               field is
     1320            </p>
     1321            <div id="rfc.figure.u.24"></div><pre class="text">  Content-Language: da
     1322</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
     1323               that the sender does not consider it to be specific to any natural language, or that the sender does not know for which language
     1324               it is intended.
     1325            </p>
     1326            <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
     1327               simultaneously in the original Maori and English versions, would call for
     1328            </p>
     1329            <div id="rfc.figure.u.25"></div><pre class="text">  Content-Language: mi, en
     1330</pre><p id="rfc.section.6.6.p.8">However, just because multiple languages are present within a representation does not mean that it is intended for multiple
     1331               linguistic audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin", which is clearly
     1332               intended to be used by an English-literate audience. In this case, the Content-Language would properly only include "en".
     1333            </p>
     1334            <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.
     1335            </p>
     1336         </div>
     1337         <div id="header.content-location">
     1338            <div id="rfc.iref.c.9"></div>
     1339            <div id="rfc.iref.h.7"></div>
     1340            <h2 id="rfc.section.6.7"><a href="#rfc.section.6.7">6.7</a>&nbsp;<a href="#header.content-location">Content-Location</a></h2>
     1341            <p id="rfc.section.6.7.p.1">The "Content-Location" header field supplies a URI that can be used as a specific identifier for the representation in this
     1342               message. In other words, if one were to perform a GET on this URI at the time of this message's generation, then a 200 response
     1343               would contain the same representation that is enclosed as payload in this message.
     1344            </p>
     1345            <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.22"></span>  <a href="#header.content-location" class="smpl">Content-Location</a> = <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a>
     1346</pre><p id="rfc.section.6.7.p.3">The Content-Location value is not a replacement for the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME
     1347               body parts in <a href="https://tools.ietf.org/html/rfc2557#section-4">Section 4</a> of <a href="#RFC2557" id="rfc.xref.RFC2557.1"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a>. However, its appearance in an HTTP message has some special implications for HTTP recipients.
     1348            </p>
     1349            <p id="rfc.section.6.7.p.4">If Content-Location is included in a response message and its value is the same as the effective request URI, then the response
     1350               payload <em class="bcp14">SHOULD</em> be considered the current representation of that resource. For a GET or HEAD request, this is the same as the default semantics
     1351               when no Content-Location is provided by the server. For a state-changing request like PUT or POST, it implies that the server's
     1352               response contains the new representation of that resource, thereby distinguishing it from representations that might only
     1353               report about the action (e.g., "It worked!"). This allows authoring applications to update their local copies without the
     1354               need for a subsequent GET request.
     1355            </p>
     1356            <p id="rfc.section.6.7.p.5">If Content-Location is included in a response message and its value differs from the effective request URI, then the origin
     1357               server is informing recipients that this representation has its own, presumably more specific, identifier. For a GET or HEAD
     1358               request, this is an indication that the effective request URI identifies a resource that is subject to content negotiation
     1359               and the representation selected for this response can also be found at the identified URI. For other methods, such a Content-Location
     1360               indicates that this representation contains a report on the action's status and the same report is available (for future access
     1361               with GET) at the given URI. For example, a purchase transaction made via a POST request might include a receipt document as
     1362               the payload of the 200 response; the Content-Location value provides an identifier for retrieving a copy of that same receipt
     1363               in the future.
     1364            </p>
     1365            <p id="rfc.section.6.7.p.6">If Content-Location is included in a request message, then it <em class="bcp14">MAY</em> be interpreted by the origin server as an indication of where the user agent originally obtained the content of the enclosed
     1366               representation (prior to any subsequent modification of the content by that user agent). In other words, the user agent is
     1367               providing the same representation metadata that it received with the original representation. However, such interpretation <em class="bcp14">MUST NOT</em> be used to alter the semantics of the method requested by the client. For example, if a client makes a PUT request on a negotiated
     1368               resource and the origin server accepts that PUT (without redirection), then the new set of values for that resource is expected
     1369               to be consistent with the one representation supplied in that PUT; the Content-Location cannot be used as a form of reverse
     1370               content selection that identifies only one of the negotiated representations to be updated. If the user agent had wanted the
     1371               latter semantics, it would have applied the PUT directly to the Content-Location URI.
     1372            </p>
     1373            <p id="rfc.section.6.7.p.7">A Content-Location field received in a request message is transitory information that <em class="bcp14">SHOULD NOT</em> be saved with other representation metadata for use in later responses. The Content-Location's value might be saved for use
     1374               in other contexts, such as within source links or other metadata.
     1375            </p>
     1376            <p id="rfc.section.6.7.p.8">A cache cannot assume that a representation with a Content-Location different from the URI used to retrieve it can be used
     1377               to respond to later requests on that Content-Location URI.
     1378            </p>
     1379            <p id="rfc.section.6.7.p.9">If the Content-Location value is a partial URI, the partial URI is interpreted relative to the effective request URI.</p>
     1380         </div>
     1381         <div id="header.content-type">
     1382            <div id="rfc.iref.c.10"></div>
     1383            <div id="rfc.iref.h.8"></div>
     1384            <h2 id="rfc.section.6.8"><a href="#rfc.section.6.8">6.8</a>&nbsp;<a href="#header.content-type">Content-Type</a></h2>
     1385            <p id="rfc.section.6.8.p.1">The "Content-Type" header field indicates the media type of the representation. In the case of responses to the HEAD method,
     1386               the media type is that which would have been sent had the request been a GET.
     1387            </p>
     1388            <div id="rfc.figure.u.27"></div><pre class="inline"><span id="rfc.iref.g.23"></span>  <a href="#header.content-type" class="smpl">Content-Type</a> = <a href="#media.types" class="smpl">media-type</a>
     1389</pre><p id="rfc.section.6.8.p.3">Media types are defined in <a href="#media.types" title="Media Types">Section&nbsp;2.3</a>. An example of the field is
     1390            </p>
     1391            <div id="rfc.figure.u.28"></div><pre class="text">  Content-Type: text/html; charset=ISO-8859-4
     1392</pre><p id="rfc.section.6.8.p.5">Further discussion of Content-Type is provided in <a href="#representation.data" title="Representation Data">Section&nbsp;4.2</a>.
     1393            </p>
     1394         </div>
    12101395      </div>
    1211       <p id="rfc.section.6.4.p.8">It might be contrary to the privacy expectations of the user to send an Accept-Language header field with the complete linguistic
    1212          preferences of the user in every request. For a discussion of this issue, see <a href="#privacy.issues.connected.to.accept.header.fields" title="Privacy Issues Connected to Accept Header Fields">Section&nbsp;8.1</a>.
    1213       </p>
    1214       <p id="rfc.section.6.4.p.9">As intelligibility is highly dependent on the individual user, it is recommended that client applications make the choice
    1215          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.
    1216       </p>
    1217       <div class="note" id="rfc.section.6.4.p.10">
    1218          <p> <b>Note:</b> When making the choice of linguistic preference available to the user, we remind implementors of the fact that users are not
    1219             familiar with the details of language matching as described above, and ought to be provided appropriate guidance. As an example,
    1220             users might assume that on selecting "en-gb", they will be served any kind of English document if British English is not available.
    1221             A user agent might suggest in such a case to add "en" to get the best matching behavior.
    1222          </p>
     1396      <div id="IANA.considerations">
     1397         <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a href="#IANA.considerations">IANA Considerations</a></h1>
     1398         <div id="header.field.registration">
     1399            <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;<a href="#header.field.registration">Header Field Registration</a></h2>
     1400            <p id="rfc.section.7.1.p.1">The Message Header Field Registry located at &lt;<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>&gt; shall be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):
     1401            </p>
     1402            <div id="rfc.table.1">
     1403               <div id="iana.header.registration.table"></div>
     1404               <table class="tt full left" cellpadding="3" cellspacing="0">
     1405                  <thead>
     1406                     <tr>
     1407                        <th>Header Field Name</th>
     1408                        <th>Protocol</th>
     1409                        <th>Status</th>
     1410                        <th>Reference</th>
     1411                     </tr>
     1412                  </thead>
     1413                  <tbody>
     1414                     <tr>
     1415                        <td class="left">Accept</td>
     1416                        <td class="left">http</td>
     1417                        <td class="left">standard</td>
     1418                        <td class="left"><a href="#header.accept" id="rfc.xref.header.accept.3" title="Accept">Section&nbsp;6.1</a>
     1419                        </td>
     1420                     </tr>
     1421                     <tr>
     1422                        <td class="left">Accept-Charset</td>
     1423                        <td class="left">http</td>
     1424                        <td class="left">standard</td>
     1425                        <td class="left"><a href="#header.accept-charset" id="rfc.xref.header.accept-charset.2" title="Accept-Charset">Section&nbsp;6.2</a>
     1426                        </td>
     1427                     </tr>
     1428                     <tr>
     1429                        <td class="left">Accept-Encoding</td>
     1430                        <td class="left">http</td>
     1431                        <td class="left">standard</td>
     1432                        <td class="left"><a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.3" title="Accept-Encoding">Section&nbsp;6.3</a>
     1433                        </td>
     1434                     </tr>
     1435                     <tr>
     1436                        <td class="left">Accept-Language</td>
     1437                        <td class="left">http</td>
     1438                        <td class="left">standard</td>
     1439                        <td class="left"><a href="#header.accept-language" id="rfc.xref.header.accept-language.2" title="Accept-Language">Section&nbsp;6.4</a>
     1440                        </td>
     1441                     </tr>
     1442                     <tr>
     1443                        <td class="left">Content-Encoding</td>
     1444                        <td class="left">http</td>
     1445                        <td class="left">standard</td>
     1446                        <td class="left"><a href="#header.content-encoding" id="rfc.xref.header.content-encoding.4" title="Content-Encoding">Section&nbsp;6.5</a>
     1447                        </td>
     1448                     </tr>
     1449                     <tr>
     1450                        <td class="left">Content-Language</td>
     1451                        <td class="left">http</td>
     1452                        <td class="left">standard</td>
     1453                        <td class="left"><a href="#header.content-language" id="rfc.xref.header.content-language.2" title="Content-Language">Section&nbsp;6.6</a>
     1454                        </td>
     1455                     </tr>
     1456                     <tr>
     1457                        <td class="left">Content-Location</td>
     1458                        <td class="left">http</td>
     1459                        <td class="left">standard</td>
     1460                        <td class="left"><a href="#header.content-location" id="rfc.xref.header.content-location.2" title="Content-Location">Section&nbsp;6.7</a>
     1461                        </td>
     1462                     </tr>
     1463                     <tr>
     1464                        <td class="left">Content-Type</td>
     1465                        <td class="left">http</td>
     1466                        <td class="left">standard</td>
     1467                        <td class="left"><a href="#header.content-type" id="rfc.xref.header.content-type.3" title="Content-Type">Section&nbsp;6.8</a>
     1468                        </td>
     1469                     </tr>
     1470                     <tr>
     1471                        <td class="left">MIME-Version</td>
     1472                        <td class="left">http</td>
     1473                        <td class="left">standard</td>
     1474                        <td class="left"><a href="#mime-version" id="rfc.xref.mime-version.1" title="MIME-Version">Appendix&nbsp;A.1</a>
     1475                        </td>
     1476                     </tr>
     1477                  </tbody>
     1478               </table>
     1479            </div>
     1480            <p id="rfc.section.7.1.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>
     1481         </div>
     1482         <div id="content.coding.registration">
     1483            <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;<a href="#content.coding.registration">Content Coding Registry</a></h2>
     1484            <p id="rfc.section.7.2.p.1">The registration procedure for HTTP Content Codings is now defined by <a href="#content.coding.registry" title="Content Coding Registry">Section&nbsp;2.2.1</a> of this document.
     1485            </p>
     1486            <p id="rfc.section.7.2.p.2">The HTTP Content Codings Registry located at &lt;<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>&gt; shall be updated with the registration below:
     1487            </p>
     1488            <div id="rfc.table.2">
     1489               <div id="iana.content.coding.registration.table"></div>
     1490               <table class="tt full left" cellpadding="3" cellspacing="0">
     1491                  <thead>
     1492                     <tr>
     1493                        <th>Name</th>
     1494                        <th>Description</th>
     1495                        <th>Reference</th>
     1496                     </tr>
     1497                  </thead>
     1498                  <tbody>
     1499                     <tr>
     1500                        <td class="left">compress</td>
     1501                        <td class="left">UNIX "compress" program method</td>
     1502                        <td class="left"><a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 6.2.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>
     1503                        </td>
     1504                     </tr>
     1505                     <tr>
     1506                        <td class="left">deflate</td>
     1507                        <td class="left">"deflate" compression mechanism (<a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>) used inside the "zlib" data format (<a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a>)
     1508                        </td>
     1509                        <td class="left"><a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 6.2.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>
     1510                        </td>
     1511                     </tr>
     1512                     <tr>
     1513                        <td class="left">gzip</td>
     1514                        <td class="left">Same as GNU zip <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a></td>
     1515                        <td class="left"><a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 6.2.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>
     1516                        </td>
     1517                     </tr>
     1518                     <tr>
     1519                        <td class="left">identity</td>
     1520                        <td class="left">No transformation</td>
     1521                        <td class="left"><a href="#content.codings" title="Content Codings">Section&nbsp;2.2</a>
     1522                        </td>
     1523                     </tr>
     1524                  </tbody>
     1525               </table>
     1526            </div>
     1527         </div>
    12231528      </div>
    1224       <div id="rfc.iref.c.7"></div>
    1225       <div id="rfc.iref.h.5"></div>
    1226       <h2 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a>&nbsp;<a id="header.content-encoding" href="#header.content-encoding">Content-Encoding</a></h2>
    1227       <p id="rfc.section.6.5.p.1">The "Content-Encoding" header field indicates what content-codings have been applied to the representation, and thus what
    1228          decoding mechanisms must be applied in order to obtain the media-type referenced by the Content-Type header field. Content-Encoding
    1229          is primarily used to allow a representation to be compressed without losing the identity of its underlying media type.
    1230       </p>
    1231       <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.20"></span>  <a href="#header.content-encoding" class="smpl">Content-Encoding</a> = 1#<a href="#content.codings" class="smpl">content-coding</a>
    1232 </pre><p id="rfc.section.6.5.p.3">Content codings are defined in <a href="#content.codings" title="Content Codings">Section&nbsp;2.2</a>. An example of its use is
    1233       </p>
    1234       <div id="rfc.figure.u.22"></div><pre class="text">  Content-Encoding: gzip
    1235 </pre><p id="rfc.section.6.5.p.5">The content-coding is a characteristic of the representation. Typically, the representation body is stored with this encoding
    1236          and is only decoded before rendering or analogous usage. However, a transforming proxy <em class="bcp14">MAY</em> modify the content-coding if the new coding is known to be acceptable to the recipient, unless the "no-transform" cache-control
    1237          directive is present in the message.
    1238       </p>
    1239       <p id="rfc.section.6.5.p.6">If the content-coding of a representation is not "identity", then the representation metadata <em class="bcp14">MUST</em> include a Content-Encoding header field (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.3" title="Content-Encoding">Section&nbsp;6.5</a>) that lists the non-identity content-coding(s) used.
    1240       </p>
    1241       <p id="rfc.section.6.5.p.7">If the content-coding of a representation in a request message is not acceptable to the origin server, the server <em class="bcp14">SHOULD</em> respond with a status code of 415 (Unsupported Media Type).
    1242       </p>
    1243       <p id="rfc.section.6.5.p.8">If multiple encodings have been applied to a representation, the content codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
    1244       </p>
    1245       <div id="rfc.iref.c.8"></div>
    1246       <div id="rfc.iref.h.6"></div>
    1247       <h2 id="rfc.section.6.6"><a href="#rfc.section.6.6">6.6</a>&nbsp;<a id="header.content-language" href="#header.content-language">Content-Language</a></h2>
    1248       <p id="rfc.section.6.6.p.1">The "Content-Language" header field describes the natural language(s) of the intended audience for the representation. Note
    1249          that this might not be equivalent to all the languages used within the representation.
    1250       </p>
    1251       <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.21"></span>  <a href="#header.content-language" class="smpl">Content-Language</a> = 1#<a href="#language.tags" class="smpl">language-tag</a>
    1252 </pre><p id="rfc.section.6.6.p.3">Language tags are defined in <a href="#language.tags" title="Language Tags">Section&nbsp;2.4</a>. The primary purpose of Content-Language is to allow a user to identify and differentiate representations according to the
    1253          user's own preferred language. Thus, if the body content is intended only for a Danish-literate audience, the appropriate
    1254          field is
    1255       </p>
    1256       <div id="rfc.figure.u.24"></div><pre class="text">  Content-Language: da
    1257 </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
    1258          that the sender does not consider it to be specific to any natural language, or that the sender does not know for which language
    1259          it is intended.
    1260       </p>
    1261       <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
    1262          simultaneously in the original Maori and English versions, would call for
    1263       </p>
    1264       <div id="rfc.figure.u.25"></div><pre class="text">  Content-Language: mi, en
    1265 </pre><p id="rfc.section.6.6.p.8">However, just because multiple languages are present within a representation does not mean that it is intended for multiple
    1266          linguistic audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin", which is clearly
    1267          intended to be used by an English-literate audience. In this case, the Content-Language would properly only include "en".
    1268       </p>
    1269       <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.
    1270       </p>
    1271       <div id="rfc.iref.c.9"></div>
    1272       <div id="rfc.iref.h.7"></div>
    1273       <h2 id="rfc.section.6.7"><a href="#rfc.section.6.7">6.7</a>&nbsp;<a id="header.content-location" href="#header.content-location">Content-Location</a></h2>
    1274       <p id="rfc.section.6.7.p.1">The "Content-Location" header field supplies a URI that can be used as a specific identifier for the representation in this
    1275          message. In other words, if one were to perform a GET on this URI at the time of this message's generation, then a 200 response
    1276          would contain the same representation that is enclosed as payload in this message.
    1277       </p>
    1278       <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.22"></span>  <a href="#header.content-location" class="smpl">Content-Location</a> = <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a>
    1279 </pre><p id="rfc.section.6.7.p.3">The Content-Location value is not a replacement for the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME
    1280          body parts in <a href="http://tools.ietf.org/html/rfc2557#section-4">Section 4</a> of <a href="#RFC2557" id="rfc.xref.RFC2557.1"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a>. However, its appearance in an HTTP message has some special implications for HTTP recipients.
    1281       </p>
    1282       <p id="rfc.section.6.7.p.4">If Content-Location is included in a response message and its value is the same as the effective request URI, then the response
    1283          payload <em class="bcp14">SHOULD</em> be considered the current representation of that resource. For a GET or HEAD request, this is the same as the default semantics
    1284          when no Content-Location is provided by the server. For a state-changing request like PUT or POST, it implies that the server's
    1285          response contains the new representation of that resource, thereby distinguishing it from representations that might only
    1286          report about the action (e.g., "It worked!"). This allows authoring applications to update their local copies without the
    1287          need for a subsequent GET request.
    1288       </p>
    1289       <p id="rfc.section.6.7.p.5">If Content-Location is included in a response message and its value differs from the effective request URI, then the origin
    1290          server is informing recipients that this representation has its own, presumably more specific, identifier. For a GET or HEAD
    1291          request, this is an indication that the effective request URI identifies a resource that is subject to content negotiation
    1292          and the representation selected for this response can also be found at the identified URI. For other methods, such a Content-Location
    1293          indicates that this representation contains a report on the action's status and the same report is available (for future access
    1294          with GET) at the given URI. For example, a purchase transaction made via a POST request might include a receipt document as
    1295          the payload of the 200 response; the Content-Location value provides an identifier for retrieving a copy of that same receipt
    1296          in the future.
    1297       </p>
    1298       <p id="rfc.section.6.7.p.6">If Content-Location is included in a request message, then it <em class="bcp14">MAY</em> be interpreted by the origin server as an indication of where the user agent originally obtained the content of the enclosed
    1299          representation (prior to any subsequent modification of the content by that user agent). In other words, the user agent is
    1300          providing the same representation metadata that it received with the original representation. However, such interpretation <em class="bcp14">MUST NOT</em> be used to alter the semantics of the method requested by the client. For example, if a client makes a PUT request on a negotiated
    1301          resource and the origin server accepts that PUT (without redirection), then the new set of values for that resource is expected
    1302          to be consistent with the one representation supplied in that PUT; the Content-Location cannot be used as a form of reverse
    1303          content selection that identifies only one of the negotiated representations to be updated. If the user agent had wanted the
    1304          latter semantics, it would have applied the PUT directly to the Content-Location URI.
    1305       </p>
    1306       <p id="rfc.section.6.7.p.7">A Content-Location field received in a request message is transitory information that <em class="bcp14">SHOULD NOT</em> be saved with other representation metadata for use in later responses. The Content-Location's value might be saved for use
    1307          in other contexts, such as within source links or other metadata.
    1308       </p>
    1309       <p id="rfc.section.6.7.p.8">A cache cannot assume that a representation with a Content-Location different from the URI used to retrieve it can be used
    1310          to respond to later requests on that Content-Location URI.
    1311       </p>
    1312       <p id="rfc.section.6.7.p.9">If the Content-Location value is a partial URI, the partial URI is interpreted relative to the effective request URI.</p>
    1313       <div id="rfc.iref.c.10"></div>
    1314       <div id="rfc.iref.h.8"></div>
    1315       <h2 id="rfc.section.6.8"><a href="#rfc.section.6.8">6.8</a>&nbsp;<a id="header.content-type" href="#header.content-type">Content-Type</a></h2>
    1316       <p id="rfc.section.6.8.p.1">The "Content-Type" header field indicates the media type of the representation. In the case of responses to the HEAD method,
    1317          the media type is that which would have been sent had the request been a GET.
    1318       </p>
    1319       <div id="rfc.figure.u.27"></div><pre class="inline"><span id="rfc.iref.g.23"></span>  <a href="#header.content-type" class="smpl">Content-Type</a> = <a href="#media.types" class="smpl">media-type</a>
    1320 </pre><p id="rfc.section.6.8.p.3">Media types are defined in <a href="#media.types" title="Media Types">Section&nbsp;2.3</a>. An example of the field is
    1321       </p>
    1322       <div id="rfc.figure.u.28"></div><pre class="text">  Content-Type: text/html; charset=ISO-8859-4
    1323 </pre><p id="rfc.section.6.8.p.5">Further discussion of Content-Type is provided in <a href="#representation.data" title="Representation Data">Section&nbsp;4.2</a>.
    1324       </p>
    1325       <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
    1326       <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;<a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2>
    1327       <p id="rfc.section.7.1.p.1">The Message Header Field Registry located at &lt;<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>&gt; shall be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):
    1328       </p>
    1329       <div id="rfc.table.1">
    1330          <div id="iana.header.registration.table"></div>
    1331          <table class="tt full left" cellpadding="3" cellspacing="0">
    1332             <thead>
    1333                <tr>
    1334                   <th>Header Field Name</th>
    1335                   <th>Protocol</th>
    1336                   <th>Status</th>
    1337                   <th>Reference</th>
    1338                </tr>
    1339             </thead>
    1340             <tbody>
    1341                <tr>
    1342                   <td class="left">Accept</td>
    1343                   <td class="left">http</td>
    1344                   <td class="left">standard</td>
    1345                   <td class="left"> <a href="#header.accept" id="rfc.xref.header.accept.3" title="Accept">Section&nbsp;6.1</a>
    1346                   </td>
    1347                </tr>
    1348                <tr>
    1349                   <td class="left">Accept-Charset</td>
    1350                   <td class="left">http</td>
    1351                   <td class="left">standard</td>
    1352                   <td class="left"> <a href="#header.accept-charset" id="rfc.xref.header.accept-charset.2" title="Accept-Charset">Section&nbsp;6.2</a>
    1353                   </td>
    1354                </tr>
    1355                <tr>
    1356                   <td class="left">Accept-Encoding</td>
    1357                   <td class="left">http</td>
    1358                   <td class="left">standard</td>
    1359                   <td class="left"> <a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.3" title="Accept-Encoding">Section&nbsp;6.3</a>
    1360                   </td>
    1361                </tr>
    1362                <tr>
    1363                   <td class="left">Accept-Language</td>
    1364                   <td class="left">http</td>
    1365                   <td class="left">standard</td>
    1366                   <td class="left"> <a href="#header.accept-language" id="rfc.xref.header.accept-language.2" title="Accept-Language">Section&nbsp;6.4</a>
    1367                   </td>
    1368                </tr>
    1369                <tr>
    1370                   <td class="left">Content-Encoding</td>
    1371                   <td class="left">http</td>
    1372                   <td class="left">standard</td>
    1373                   <td class="left"> <a href="#header.content-encoding" id="rfc.xref.header.content-encoding.4" title="Content-Encoding">Section&nbsp;6.5</a>
    1374                   </td>
    1375                </tr>
    1376                <tr>
    1377                   <td class="left">Content-Language</td>
    1378                   <td class="left">http</td>
    1379                   <td class="left">standard</td>
    1380                   <td class="left"> <a href="#header.content-language" id="rfc.xref.header.content-language.2" title="Content-Language">Section&nbsp;6.6</a>
    1381                   </td>
    1382                </tr>
    1383                <tr>
    1384                   <td class="left">Content-Location</td>
    1385                   <td class="left">http</td>
    1386                   <td class="left">standard</td>
    1387                   <td class="left"> <a href="#header.content-location" id="rfc.xref.header.content-location.2" title="Content-Location">Section&nbsp;6.7</a>
    1388                   </td>
    1389                </tr>
    1390                <tr>
    1391                   <td class="left">Content-Type</td>
    1392                   <td class="left">http</td>
    1393                   <td class="left">standard</td>
    1394                   <td class="left"> <a href="#header.content-type" id="rfc.xref.header.content-type.3" title="Content-Type">Section&nbsp;6.8</a>
    1395                   </td>
    1396                </tr>
    1397                <tr>
    1398                   <td class="left">MIME-Version</td>
    1399                   <td class="left">http</td>
    1400                   <td class="left">standard</td>
    1401                   <td class="left"> <a href="#mime-version" id="rfc.xref.mime-version.1" title="MIME-Version">Appendix&nbsp;A.1</a>
    1402                   </td>
    1403                </tr>
    1404             </tbody>
    1405          </table>
     1529      <div id="security.considerations">
     1530         <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a href="#security.considerations">Security Considerations</a></h1>
     1531         <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
     1532            as described by this document. The discussion does not include definitive solutions to the problems revealed, though it does
     1533            make some suggestions for reducing security risks.
     1534         </p>
     1535         <div id="privacy.issues.connected.to.accept.header.fields">
     1536            <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a>&nbsp;<a href="#privacy.issues.connected.to.accept.header.fields">Privacy Issues Connected to Accept Header Fields</a></h2>
     1537            <p id="rfc.section.8.1.p.1">Accept headers fields can reveal information about the user to all servers which are accessed. The Accept-Language header
     1538               field in particular can reveal information the user would consider to be of a private nature, because the understanding of
     1539               particular languages is often strongly correlated to the membership of a particular ethnic group. User agents which offer
     1540               the option to configure the contents of an Accept-Language header field to be sent in every request are strongly encouraged
     1541               to let the configuration process include a message which makes the user aware of the loss of privacy involved.
     1542            </p>
     1543            <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 header fields
     1544               by default, and to ask the user whether or not to start sending Accept-Language header fields to a server if it detects, by
     1545               looking for any Vary header fields generated by the server, that such sending could improve the quality of service.
     1546            </p>
     1547            <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
     1548               used by servers as relatively reliable and long-lived user identifiers. Such user identifiers would allow content providers
     1549               to do click-trail tracking, and would allow collaborating content providers to match cross-server click-trails or form submissions
     1550               of individual users. Note that for many users not behind a proxy, the network address of the host running the user agent will
     1551               also serve as a long-lived user identifier. In environments where proxies are used to enhance privacy, user agents ought to
     1552               be conservative in offering accept header configuration options to end users. As an extreme privacy measure, proxies could
     1553               filter the accept header fields in relayed requests. General purpose user agents which provide a high degree of header configurability <em class="bcp14">SHOULD</em> warn users about the loss of privacy which can be involved.
     1554            </p>
     1555         </div>
    14061556      </div>
    1407       <p id="rfc.section.7.1.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>
    1408       <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;<a id="content.coding.registration" href="#content.coding.registration">Content Coding Registry</a></h2>
    1409       <p id="rfc.section.7.2.p.1">The registration procedure for HTTP Content Codings is now defined by <a href="#content.coding.registry" title="Content Coding Registry">Section&nbsp;2.2.1</a> of this document.
    1410       </p>
    1411       <p id="rfc.section.7.2.p.2">The HTTP Content Codings Registry located at &lt;<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>&gt; shall be updated with the registration below:
    1412       </p>
    1413       <div id="rfc.table.2">
    1414          <div id="iana.content.coding.registration.table"></div>
    1415          <table class="tt full left" cellpadding="3" cellspacing="0">
    1416             <thead>
    1417                <tr>
    1418                   <th>Name</th>
    1419                   <th>Description</th>
    1420                   <th>Reference</th>
    1421                </tr>
    1422             </thead>
    1423             <tbody>
    1424                <tr>
    1425                   <td class="left">compress</td>
    1426                   <td class="left">UNIX "compress" program method</td>
    1427                   <td class="left"> <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 6.2.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>
    1428                   </td>
    1429                </tr>
    1430                <tr>
    1431                   <td class="left">deflate</td>
    1432                   <td class="left">"deflate" compression mechanism (<a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>) used inside the "zlib" data format (<a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a>)
    1433                   </td>
    1434                   <td class="left"> <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 6.2.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>
    1435                   </td>
    1436                </tr>
    1437                <tr>
    1438                   <td class="left">gzip</td>
    1439                   <td class="left">Same as GNU zip <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a></td>
    1440                   <td class="left"> <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 6.2.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>
    1441                   </td>
    1442                </tr>
    1443                <tr>
    1444                   <td class="left">identity</td>
    1445                   <td class="left">No transformation</td>
    1446                   <td class="left"> <a href="#content.codings" title="Content Codings">Section&nbsp;2.2</a>
    1447                   </td>
    1448                </tr>
    1449             </tbody>
    1450          </table>
     1557      <div id="ack">
     1558         <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a href="#ack">Acknowledgments</a></h1>
    14511559      </div>
    1452       <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>
    1453       <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
    1454          as described by this document. The discussion does not include definitive solutions to the problems revealed, though it does
    1455          make some suggestions for reducing security risks.
    1456       </p>
    1457       <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a>&nbsp;<a id="privacy.issues.connected.to.accept.header.fields" href="#privacy.issues.connected.to.accept.header.fields">Privacy Issues Connected to Accept Header Fields</a></h2>
    1458       <p id="rfc.section.8.1.p.1">Accept headers fields can reveal information about the user to all servers which are accessed. The Accept-Language header
    1459          field in particular can reveal information the user would consider to be of a private nature, because the understanding of
    1460          particular languages is often strongly correlated to the membership of a particular ethnic group. User agents which offer
    1461          the option to configure the contents of an Accept-Language header field to be sent in every request are strongly encouraged
    1462          to let the configuration process include a message which makes the user aware of the loss of privacy involved.
    1463       </p>
    1464       <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 header fields
    1465          by default, and to ask the user whether or not to start sending Accept-Language header fields to a server if it detects, by
    1466          looking for any Vary header fields generated by the server, that such sending could improve the quality of service.
    1467       </p>
    1468       <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
    1469          used by servers as relatively reliable and long-lived user identifiers. Such user identifiers would allow content providers
    1470          to do click-trail tracking, and would allow collaborating content providers to match cross-server click-trails or form submissions
    1471          of individual users. Note that for many users not behind a proxy, the network address of the host running the user agent will
    1472          also serve as a long-lived user identifier. In environments where proxies are used to enhance privacy, user agents ought to
    1473          be conservative in offering accept header configuration options to end users. As an extreme privacy measure, proxies could
    1474          filter the accept header fields in relayed requests. General purpose user agents which provide a high degree of header configurability <em class="bcp14">SHOULD</em> warn users about the loss of privacy which can be involved.
    1475       </p>
    1476       <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="ack" href="#ack">Acknowledgments</a></h1>
    14771560      <h1 id="rfc.references"><a id="rfc.section.10" href="#rfc.section.10">10.</a> References
    14781561      </h1>
    14791562      <h2 id="rfc.references.1"><a href="#rfc.section.10.1" id="rfc.section.10.1">10.1</a> Normative References
    14801563      </h2>
    1481       <table>                           
     1564      <table>
    14821565         <tr>
    14831566            <td class="reference"><b id="Part1">[Part1]</b></td>
    1484             <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p1-messaging-14 (work in progress), April&nbsp;2011.
     1567            <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="https://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-14">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p1-messaging-14 (work in progress), April&nbsp;2011.
    14851568            </td>
    14861569         </tr>
    14871570         <tr>
    14881571            <td class="reference"><b id="Part2">[Part2]</b></td>
    1489             <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-14">HTTP/1.1, part 2: Message Semantics</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p2-semantics-14 (work in progress), April&nbsp;2011.
     1572            <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="https://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-14">HTTP/1.1, part 2: Message Semantics</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p2-semantics-14 (work in progress), April&nbsp;2011.
    14901573            </td>
    14911574         </tr>
    14921575         <tr>
    14931576            <td class="reference"><b id="Part4">[Part4]</b></td>
    1494             <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-14">HTTP/1.1, part 4: Conditional Requests</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p4-conditional-14 (work in progress), April&nbsp;2011.
     1577            <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="https://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-14">HTTP/1.1, part 4: Conditional Requests</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p4-conditional-14 (work in progress), April&nbsp;2011.
    14951578            </td>
    14961579         </tr>
    14971580         <tr>
    14981581            <td class="reference"><b id="Part5">[Part5]</b></td>
    1499             <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-14">HTTP/1.1, part 5: Range Requests and Partial Responses</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p5-range-14 (work in progress), April&nbsp;2011.
     1582            <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="https://tools.ietf.org/html/draft-ietf-httpbis-p5-range-14">HTTP/1.1, part 5: Range Requests and Partial Responses</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p5-range-14 (work in progress), April&nbsp;2011.
    15001583            </td>
    15011584         </tr>
    15021585         <tr>
    15031586            <td class="reference"><b id="Part6">[Part6]</b></td>
    1504             <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, <a href="mailto:mnot@mnot.net">Nottingham, M., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-14">HTTP/1.1, part 6: Caching</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p6-cache-14 (work in progress), April&nbsp;2011.
     1587            <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:jg@freedesktop.org" title="Alcatel-Lucent Bell Labs">Gettys, J.</a>, <a href="mailto:JeffMogul@acm.org" title="Hewlett-Packard Company">Mogul, J.</a>, <a href="mailto:henrikn@microsoft.com" title="Microsoft Corporation">Frystyk, H.</a>, <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, <a href="mailto:mnot@mnot.net">Nottingham, M., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="https://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-14">HTTP/1.1, part 6: Caching</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p6-cache-14 (work in progress), April&nbsp;2011.
    15051588            </td>
    15061589         </tr>
    15071590         <tr>
    15081591            <td class="reference"><b id="RFC1950">[RFC1950]</b></td>
    1509             <td class="top"><a href="mailto:ghost@aladdin.com" title="Aladdin Enterprises">Deutsch, L.</a> and J-L. Gailly, “<a href="http://tools.ietf.org/html/rfc1950">ZLIB Compressed Data Format Specification version 3.3</a>”, RFC&nbsp;1950, May&nbsp;1996.<br>RFC 1950 is an Informational RFC, thus it might be less stable than this specification. On the other hand, this downward reference
     1592            <td class="top"><a href="mailto:ghost@aladdin.com" title="Aladdin Enterprises">Deutsch, L.</a> and J-L. Gailly, “<a href="https://tools.ietf.org/html/rfc1950">ZLIB Compressed Data Format Specification version 3.3</a>”, RFC&nbsp;1950, May&nbsp;1996.<br>RFC 1950 is an Informational RFC, thus it might be less stable than this specification. On the other hand, this downward reference
    15101593               was present since the publication of RFC 2068 in 1997 (<a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>), therefore it is unlikely to cause problems in practice. See also <a href="#BCP97" id="rfc.xref.BCP97.1"><cite title="Handling Normative References to Standards-Track Documents">[BCP97]</cite></a>.
    15111594            </td>
     
    15131596         <tr>
    15141597            <td class="reference"><b id="RFC1951">[RFC1951]</b></td>
    1515             <td class="top"><a href="mailto:ghost@aladdin.com" title="Aladdin Enterprises">Deutsch, P.</a>, “<a href="http://tools.ietf.org/html/rfc1951">DEFLATE Compressed Data Format Specification version 1.3</a>”, RFC&nbsp;1951, May&nbsp;1996.<br>RFC 1951 is an Informational RFC, thus it might be less stable than this specification. On the other hand, this downward reference
     1598            <td class="top"><a href="mailto:ghost@aladdin.com" title="Aladdin Enterprises">Deutsch, P.</a>, “<a href="https://tools.ietf.org/html/rfc1951">DEFLATE Compressed Data Format Specification version 1.3</a>”, RFC&nbsp;1951, May&nbsp;1996.<br>RFC 1951 is an Informational RFC, thus it might be less stable than this specification. On the other hand, this downward reference
    15161599               was present since the publication of RFC 2068 in 1997 (<a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>), therefore it is unlikely to cause problems in practice. See also <a href="#BCP97" id="rfc.xref.BCP97.2"><cite title="Handling Normative References to Standards-Track Documents">[BCP97]</cite></a>.
    15171600            </td>
     
    15191602         <tr>
    15201603            <td class="reference"><b id="RFC1952">[RFC1952]</b></td>
    1521             <td class="top"><a href="mailto:ghost@aladdin.com" title="Aladdin Enterprises">Deutsch, P.</a>, <a href="mailto:gzip@prep.ai.mit.edu">Gailly, J-L.</a>, <a href="mailto:madler@alumni.caltech.edu">Adler, M.</a>, <a href="mailto:ghost@aladdin.com">Deutsch, L.</a>, and <a href="mailto:randeg@alumni.rpi.edu">G. Randers-Pehrson</a>, “<a href="http://tools.ietf.org/html/rfc1952">GZIP file format specification version 4.3</a>”, RFC&nbsp;1952, May&nbsp;1996.<br>RFC 1952 is an Informational RFC, thus it might be less stable than this specification. On the other hand, this downward reference
     1604            <td class="top"><a href="mailto:ghost@aladdin.com" title="Aladdin Enterprises">Deutsch, P.</a>, <a href="mailto:gzip@prep.ai.mit.edu">Gailly, J-L.</a>, <a href="mailto:madler@alumni.caltech.edu">Adler, M.</a>, <a href="mailto:ghost@aladdin.com">Deutsch, L.</a>, and <a href="mailto:randeg@alumni.rpi.edu">G. Randers-Pehrson</a>, “<a href="https://tools.ietf.org/html/rfc1952">GZIP file format specification version 4.3</a>”, RFC&nbsp;1952, May&nbsp;1996.<br>RFC 1952 is an Informational RFC, thus it might be less stable than this specification. On the other hand, this downward reference
    15221605               was present since the publication of RFC 2068 in 1997 (<a href="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>), therefore it is unlikely to cause problems in practice. See also <a href="#BCP97" id="rfc.xref.BCP97.3"><cite title="Handling Normative References to Standards-Track Documents">[BCP97]</cite></a>.
    15231606            </td>
     
    15251608         <tr>
    15261609            <td class="reference"><b id="RFC2045">[RFC2045]</b></td>
    1527             <td class="top"><a href="mailto:ned@innosoft.com" title="Innosoft International, Inc.">Freed, N.</a> and <a href="mailto:nsb@nsb.fv.com" title="First Virtual Holdings">N. Borenstein</a>, “<a href="http://tools.ietf.org/html/rfc2045">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</a>”, RFC&nbsp;2045, November&nbsp;1996.
     1610            <td class="top"><a href="mailto:ned@innosoft.com" title="Innosoft International, Inc.">Freed, N.</a> and <a href="mailto:nsb@nsb.fv.com" title="First Virtual Holdings">N. Borenstein</a>, “<a href="https://tools.ietf.org/html/rfc2045">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</a>”, RFC&nbsp;2045, November&nbsp;1996.
    15281611            </td>
    15291612         </tr>
    15301613         <tr>
    15311614            <td class="reference"><b id="RFC2046">[RFC2046]</b></td>
    1532             <td class="top"><a href="mailto:ned@innosoft.com" title="Innosoft International, Inc.">Freed, N.</a> and <a href="mailto:nsb@nsb.fv.com" title="First Virtual Holdings">N. Borenstein</a>, “<a href="http://tools.ietf.org/html/rfc2046">Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</a>”, RFC&nbsp;2046, November&nbsp;1996.
     1615            <td class="top"><a href="mailto:ned@innosoft.com" title="Innosoft International, Inc.">Freed, N.</a> and <a href="mailto:nsb@nsb.fv.com" title="First Virtual Holdings">N. Borenstein</a>, “<a href="https://tools.ietf.org/html/rfc2046">Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</a>”, RFC&nbsp;2046, November&nbsp;1996.
    15331616            </td>
    15341617         </tr>
    15351618         <tr>
    15361619            <td class="reference"><b id="RFC2119">[RFC2119]</b></td>
    1537             <td class="top"><a href="mailto:sob@harvard.edu" title="Harvard University">Bradner, S.</a>, “<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>”, BCP&nbsp;14, RFC&nbsp;2119, March&nbsp;1997.
     1620            <td class="top"><a href="mailto:sob@harvard.edu" title="Harvard University">Bradner, S.</a>, “<a href="https://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>”, BCP&nbsp;14, RFC&nbsp;2119, March&nbsp;1997.
    15381621            </td>
    15391622         </tr>
    15401623         <tr>
    15411624            <td class="reference"><b id="RFC4647">[RFC4647]</b></td>
    1542             <td class="top"><a href="mailto:addison@inter-locale.com" title="Yahoo! Inc.">Phillips, A., Ed.</a> and <a href="mailto:mark.davis@macchiato.com" title="Google">M. Davis, Ed.</a>, “<a href="http://tools.ietf.org/html/rfc4647">Matching of Language Tags</a>”, BCP&nbsp;47, RFC&nbsp;4647, September&nbsp;2006.
     1625            <td class="top"><a href="mailto:addison@inter-locale.com" title="Yahoo! Inc.">Phillips, A., Ed.</a> and <a href="mailto:mark.davis@macchiato.com" title="Google">M. Davis, Ed.</a>, “<a href="https://tools.ietf.org/html/rfc4647">Matching of Language Tags</a>”, BCP&nbsp;47, RFC&nbsp;4647, September&nbsp;2006.
    15431626            </td>
    15441627         </tr>
    15451628         <tr>
    15461629            <td class="reference"><b id="RFC5234">[RFC5234]</b></td>
    1547             <td class="top"><a href="mailto:dcrocker@bbiw.net" title="Brandenburg InternetWorking">Crocker, D., Ed.</a> and <a href="mailto:paul.overell@thus.net" title="THUS plc.">P. Overell</a>, “<a href="http://tools.ietf.org/html/rfc5234">Augmented BNF for Syntax Specifications: ABNF</a>”, STD&nbsp;68, RFC&nbsp;5234, January&nbsp;2008.
     1630            <td class="top"><a href="mailto:dcrocker@bbiw.net" title="Brandenburg InternetWorking">Crocker, D., Ed.</a> and <a href="mailto:paul.overell@thus.net" title="THUS plc.">P. Overell</a>, “<a href="https://tools.ietf.org/html/rfc5234">Augmented BNF for Syntax Specifications: ABNF</a>”, STD&nbsp;68, RFC&nbsp;5234, January&nbsp;2008.
    15481631            </td>
    15491632         </tr>
    15501633         <tr>
    15511634            <td class="reference"><b id="RFC5646">[RFC5646]</b></td>
    1552             <td class="top"><a href="mailto:addison@inter-locale.com" title="Lab126">Phillips, A., Ed.</a> and <a href="mailto:mark.davis@google.com" title="Google">M. Davis, Ed.</a>, “<a href="http://tools.ietf.org/html/rfc5646">Tags for Identifying Languages</a>”, BCP&nbsp;47, RFC&nbsp;5646, September&nbsp;2009.
     1635            <td class="top"><a href="mailto:addison@inter-locale.com" title="Lab126">Phillips, A., Ed.</a> and <a href="mailto:mark.davis@google.com" title="Google">M. Davis, Ed.</a>, “<a href="https://tools.ietf.org/html/rfc5646">Tags for Identifying Languages</a>”, BCP&nbsp;47, RFC&nbsp;5646, September&nbsp;2009.
    15531636            </td>
    15541637         </tr>
     
    15561639      <h2 id="rfc.references.2"><a href="#rfc.section.10.2" id="rfc.section.10.2">10.2</a> Informative References
    15571640      </h2>
    1558       <table>                                 
     1641      <table>
    15591642         <tr>
    15601643            <td class="reference"><b id="BCP97">[BCP97]</b></td>
    1561             <td class="top"><a href="mailto:klensin+ietf@jck.com">Klensin, J.</a> and <a href="mailto:hartmans-ietf@mit.edu" title="MIT">S. Hartman</a>, “<a href="http://tools.ietf.org/html/rfc4897">Handling Normative References to Standards-Track Documents</a>”, BCP&nbsp;97, RFC&nbsp;4897, June&nbsp;2007.
     1644            <td class="top"><a href="mailto:klensin+ietf@jck.com">Klensin, J.</a> and <a href="mailto:hartmans-ietf@mit.edu" title="MIT">S. Hartman</a>, “<a href="https://tools.ietf.org/html/rfc4897">Handling Normative References to Standards-Track Documents</a>”, BCP&nbsp;97, RFC&nbsp;4897, June&nbsp;2007.
    15621645            </td>
    15631646         </tr>
    15641647         <tr>
    15651648            <td class="reference"><b id="RFC1945">[RFC1945]</b></td>
    1566             <td class="top"><a href="mailto:timbl@w3.org" title="MIT, Laboratory for Computer Science">Berners-Lee, T.</a>, <a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine, Department of Information and Computer Science">Fielding, R.</a>, and <a href="mailto:frystyk@w3.org" title="W3 Consortium, MIT Laboratory for Computer Science">H. Nielsen</a>, “<a href="http://tools.ietf.org/html/rfc1945">Hypertext Transfer Protocol -- HTTP/1.0</a>”, RFC&nbsp;1945, May&nbsp;1996.
     1649            <td class="top"><a href="mailto:timbl@w3.org" title="MIT, Laboratory for Computer Science">Berners-Lee, T.</a>, <a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine, Department of Information and Computer Science">Fielding, R.</a>, and <a href="mailto:frystyk@w3.org" title="W3 Consortium, MIT Laboratory for Computer Science">H. Nielsen</a>, “<a href="https://tools.ietf.org/html/rfc1945">Hypertext Transfer Protocol -- HTTP/1.0</a>”, RFC&nbsp;1945, May&nbsp;1996.
    15671650            </td>
    15681651         </tr>
    15691652         <tr>
    15701653            <td class="reference"><b id="RFC2049">[RFC2049]</b></td>
    1571             <td class="top"><a href="mailto:ned@innosoft.com" title="Innosoft International, Inc.">Freed, N.</a> and <a href="mailto:nsb@nsb.fv.com" title="First Virtual Holdings">N. Borenstein</a>, “<a href="http://tools.ietf.org/html/rfc2049">Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples</a>”, RFC&nbsp;2049, November&nbsp;1996.
     1654            <td class="top"><a href="mailto:ned@innosoft.com" title="Innosoft International, Inc.">Freed, N.</a> and <a href="mailto:nsb@nsb.fv.com" title="First Virtual Holdings">N. Borenstein</a>, “<a href="https://tools.ietf.org/html/rfc2049">Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples</a>”, RFC&nbsp;2049, November&nbsp;1996.
    15721655            </td>
    15731656         </tr>
    15741657         <tr>
    15751658            <td class="reference"><b id="RFC2068">[RFC2068]</b></td>
    1576             <td class="top"><a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine, Department of Information and Computer Science">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="MIT Laboratory for Computer Science">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Digital Equipment Corporation, Western Research Laboratory">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="MIT Laboratory for Computer Science">Nielsen, H.</a>, and <a href="mailto:timbl@w3.org" title="MIT Laboratory for Computer Science">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2068">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC&nbsp;2068, January&nbsp;1997.
     1659            <td class="top"><a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine, Department of Information and Computer Science">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="MIT Laboratory for Computer Science">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Digital Equipment Corporation, Western Research Laboratory">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="MIT Laboratory for Computer Science">Nielsen, H.</a>, and <a href="mailto:timbl@w3.org" title="MIT Laboratory for Computer Science">T. Berners-Lee</a>, “<a href="https://tools.ietf.org/html/rfc2068">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC&nbsp;2068, January&nbsp;1997.
    15771660            </td>
    15781661         </tr>
    15791662         <tr>
    15801663            <td class="reference"><b id="RFC2076">[RFC2076]</b></td>
    1581             <td class="top"><a href="mailto:jpalme@dsv.su.se" title="Stockholm University/KTH">Palme, J.</a>, “<a href="http://tools.ietf.org/html/rfc2076">Common Internet Message Headers</a>”, RFC&nbsp;2076, February&nbsp;1997.
     1664            <td class="top"><a href="mailto:jpalme@dsv.su.se" title="Stockholm University/KTH">Palme, J.</a>, “<a href="https://tools.ietf.org/html/rfc2076">Common Internet Message Headers</a>”, RFC&nbsp;2076, February&nbsp;1997.
    15821665            </td>
    15831666         </tr>
    15841667         <tr>
    15851668            <td class="reference"><b id="RFC2277">[RFC2277]</b></td>
    1586             <td class="top"><a href="mailto:Harald.T.Alvestrand@uninett.no" title="UNINETT">Alvestrand, H.</a>, “<a href="http://tools.ietf.org/html/rfc2277">IETF Policy on Character Sets and Languages</a>”, BCP&nbsp;18, RFC&nbsp;2277, January&nbsp;1998.
     1669            <td class="top"><a href="mailto:Harald.T.Alvestrand@uninett.no" title="UNINETT">Alvestrand, H.</a>, “<a href="https://tools.ietf.org/html/rfc2277">IETF Policy on Character Sets and Languages</a>”, BCP&nbsp;18, RFC&nbsp;2277, January&nbsp;1998.
    15871670            </td>
    15881671         </tr>
    15891672         <tr>
    15901673            <td class="reference"><b id="RFC2295">[RFC2295]</b></td>
    1591             <td class="top"><a href="mailto:koen@win.tue.nl" title="Technische Universiteit Eindhoven">Holtman, K.</a> and <a href="mailto:mutz@hpl.hp.com" title="Hewlett-Packard Company">A. Mutz</a>, “<a href="http://tools.ietf.org/html/rfc2295">Transparent Content Negotiation in HTTP</a>”, RFC&nbsp;2295, March&nbsp;1998.
     1674            <td class="top"><a href="mailto:koen@win.tue.nl" title="Technische Universiteit Eindhoven">Holtman, K.</a> and <a href="mailto:mutz@hpl.hp.com" title="Hewlett-Packard Company">A. Mutz</a>, “<a href="https://tools.ietf.org/html/rfc2295">Transparent Content Negotiation in HTTP</a>”, RFC&nbsp;2295, March&nbsp;1998.
    15921675            </td>
    15931676         </tr>
    15941677         <tr>
    15951678            <td class="reference"><b id="RFC2388">[RFC2388]</b></td>
    1596             <td class="top"><a href="mailto:masinter@parc.xerox.com" title="Xerox Palo Alto Research Center">Masinter, L.</a>, “<a href="http://tools.ietf.org/html/rfc2388">Returning Values from Forms: multipart/form-data</a>”, RFC&nbsp;2388, August&nbsp;1998.
     1679            <td class="top"><a href="mailto:masinter@parc.xerox.com" title="Xerox Palo Alto Research Center">Masinter, L.</a>, “<a href="https://tools.ietf.org/html/rfc2388">Returning Values from Forms: multipart/form-data</a>”, RFC&nbsp;2388, August&nbsp;1998.
    15971680            </td>
    15981681         </tr>
    15991682         <tr>
    16001683            <td class="reference"><b id="RFC2557">[RFC2557]</b></td>
    1601             <td class="top"><a href="mailto:jpalme@dsv.su.se" title="Stockholm University and KTH">Palme, F.</a>, <a href="mailto:alexhop@microsoft.com" title="Microsoft Corporation">Hopmann, A.</a>, <a href="mailto:Shelness@lotus.com" title="Lotus Development Corporation">Shelness, N.</a>, and <a href="mailto:stef@nma.com">E. Stefferud</a>, “<a href="http://tools.ietf.org/html/rfc2557">MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)</a>”, RFC&nbsp;2557, March&nbsp;1999.
     1684            <td class="top"><a href="mailto:jpalme@dsv.su.se" title="Stockholm University and KTH">Palme, F.</a>, <a href="mailto:alexhop@microsoft.com" title="Microsoft Corporation">Hopmann, A.</a>, <a href="mailto:Shelness@lotus.com" title="Lotus Development Corporation">Shelness, N.</a>, and <a href="mailto:stef@nma.com">E. Stefferud</a>, “<a href="https://tools.ietf.org/html/rfc2557">MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)</a>”, RFC&nbsp;2557, March&nbsp;1999.
    16021685            </td>
    16031686         </tr>
    16041687         <tr>
    16051688            <td class="reference"><b id="RFC2616">[RFC2616]</b></td>
    1606             <td class="top"><a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="W3C">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Compaq Computer Corporation">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="MIT Laboratory for Computer Science">Frystyk, H.</a>, <a href="mailto:masinter@parc.xerox.com" title="Xerox Corporation">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, and <a href="mailto:timbl@w3.org" title="W3C">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC&nbsp;2616, June&nbsp;1999.
     1689            <td class="top"><a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="W3C">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Compaq Computer Corporation">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="MIT Laboratory for Computer Science">Frystyk, H.</a>, <a href="mailto:masinter@parc.xerox.com" title="Xerox Corporation">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, and <a href="mailto:timbl@w3.org" title="W3C">T. Berners-Lee</a>, “<a href="https://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC&nbsp;2616, June&nbsp;1999.
    16071690            </td>
    16081691         </tr>
    16091692         <tr>
    16101693            <td class="reference"><b id="RFC3629">[RFC3629]</b></td>
    1611             <td class="top"><a href="mailto:fyergeau@alis.com" title="Alis Technologies">Yergeau, F.</a>, “<a href="http://tools.ietf.org/html/rfc3629">UTF-8, a transformation format of ISO 10646</a>”, STD&nbsp;63, RFC&nbsp;3629, November&nbsp;2003.
     1694            <td class="top"><a href="mailto:fyergeau@alis.com" title="Alis Technologies">Yergeau, F.</a>, “<a href="https://tools.ietf.org/html/rfc3629">UTF-8, a transformation format of ISO 10646</a>”, STD&nbsp;63, RFC&nbsp;3629, November&nbsp;2003.
    16121695            </td>
    16131696         </tr>
    16141697         <tr>
    16151698            <td class="reference"><b id="RFC3864">[RFC3864]</b></td>
    1616             <td class="top"><a href="mailto:GK-IETF@ninebynine.org" title="Nine by Nine">Klyne, G.</a>, <a href="mailto:mnot@pobox.com" title="BEA Systems">Nottingham, M.</a>, and <a href="mailto:JeffMogul@acm.org" title="HP Labs">J. Mogul</a>, “<a href="http://tools.ietf.org/html/rfc3864">Registration Procedures for Message Header Fields</a>”, BCP&nbsp;90, RFC&nbsp;3864, September&nbsp;2004.
     1699            <td class="top"><a href="mailto:GK-IETF@ninebynine.org" title="Nine by Nine">Klyne, G.</a>, <a href="mailto:mnot@pobox.com" title="BEA Systems">Nottingham, M.</a>, and <a href="mailto:JeffMogul@acm.org" title="HP Labs">J. Mogul</a>, “<a href="https://tools.ietf.org/html/rfc3864">Registration Procedures for Message Header Fields</a>”, BCP&nbsp;90, RFC&nbsp;3864, September&nbsp;2004.
    16171700            </td>
    16181701         </tr>
    16191702         <tr>
    16201703            <td class="reference"><b id="RFC4288">[RFC4288]</b></td>
    1621             <td class="top"><a href="mailto:ned.freed@mrochek.com" title="Sun Microsystems">Freed, N.</a> and <a href="mailto:klensin+ietf@jck.com">J. Klensin</a>, “<a href="http://tools.ietf.org/html/rfc4288">Media Type Specifications and Registration Procedures</a>”, BCP&nbsp;13, RFC&nbsp;4288, December&nbsp;2005.
     1704            <td class="top"><a href="mailto:ned.freed@mrochek.com" title="Sun Microsystems">Freed, N.</a> and <a href="mailto:klensin+ietf@jck.com">J. Klensin</a>, “<a href="https://tools.ietf.org/html/rfc4288">Media Type Specifications and Registration Procedures</a>”, BCP&nbsp;13, RFC&nbsp;4288, December&nbsp;2005.
    16221705            </td>
    16231706         </tr>
    16241707         <tr>
    16251708            <td class="reference"><b id="RFC5226">[RFC5226]</b></td>
    1626             <td class="top"><a href="mailto:narten@us.ibm.com" title="IBM">Narten, T.</a> and <a href="mailto:Harald@Alvestrand.no" title="Google">H. Alvestrand</a>, “<a href="http://tools.ietf.org/html/rfc5226">Guidelines for Writing an IANA Considerations Section in RFCs</a>”, BCP&nbsp;26, RFC&nbsp;5226, May&nbsp;2008.
     1709            <td class="top"><a href="mailto:narten@us.ibm.com" title="IBM">Narten, T.</a> and <a href="mailto:Harald@Alvestrand.no" title="Google">H. Alvestrand</a>, “<a href="https://tools.ietf.org/html/rfc5226">Guidelines for Writing an IANA Considerations Section in RFCs</a>”, BCP&nbsp;26, RFC&nbsp;5226, May&nbsp;2008.
    16271710            </td>
    16281711         </tr>
    16291712         <tr>
    16301713            <td class="reference"><b id="RFC5322">[RFC5322]</b></td>
    1631             <td class="top">Resnick, P., “<a href="http://tools.ietf.org/html/rfc5322">Internet Message Format</a>”, RFC&nbsp;5322, October&nbsp;2008.
     1714            <td class="top">Resnick, P., “<a href="https://tools.ietf.org/html/rfc5322">Internet Message Format</a>”, RFC&nbsp;5322, October&nbsp;2008.
    16321715            </td>
    16331716         </tr>
    16341717         <tr>
    16351718            <td class="reference"><b id="RFC6151">[RFC6151]</b></td>
    1636             <td class="top">Turner, S. and L. Chen, “<a href="http://tools.ietf.org/html/rfc6151">Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms</a>”, RFC&nbsp;6151, March&nbsp;2011.
     1719            <td class="top">Turner, S. and L. Chen, “<a href="https://tools.ietf.org/html/rfc6151">Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms</a>”, RFC&nbsp;6151, March&nbsp;2011.
    16371720            </td>
    16381721         </tr>
    16391722         <tr>
    16401723            <td class="reference"><b id="draft-ietf-httpbis-content-disp">[draft-ietf-httpbis-content-disp]</b></td>
    1641             <td class="top"><a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">Reschke, J.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-content-disp-09">Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-content-disp-09 (work in progress), March&nbsp;2011.
     1724            <td class="top"><a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">Reschke, J.</a>, “<a href="https://tools.ietf.org/html/draft-ietf-httpbis-content-disp-09">Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-content-disp-09 (work in progress), March&nbsp;2011.
    16421725            </td>
    16431726         </tr>
    16441727      </table>
    1645       <div class="avoidbreak">
    1646          <h1 id="rfc.authors"><a href="#rfc.authors">Authors' Addresses</a></h1>
    1647          <address class="vcard"><span class="vcardline"><span class="fn">Roy T. Fielding</span>
    1648                (editor)
    1649                <span class="n hidden"><span class="family-name">Fielding</span><span class="given-name">Roy T.</span></span></span><span class="org vcardline">Adobe Systems Incorporated</span><span class="adr"><span class="street-address vcardline">345 Park Ave</span><span class="vcardline"><span class="locality">San Jose</span>, <span class="region">CA</span>&nbsp;<span class="postal-code">95110</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">Email: <a href="mailto:fielding@gbiv.com"><span class="email">fielding@gbiv.com</span></a></span><span class="vcardline">URI: <a href="http://roy.gbiv.com/" class="url">http://roy.gbiv.com/</a></span></address>
    1650          <address class="vcard"><span class="vcardline"><span class="fn">Jim Gettys</span><span class="n hidden"><span class="family-name">Gettys</span><span class="given-name">Jim</span></span></span><span class="org vcardline">Alcatel-Lucent Bell Labs</span><span class="adr"><span class="street-address vcardline">21 Oak Knoll Road</span><span class="vcardline"><span class="locality">Carlisle</span>, <span class="region">MA</span>&nbsp;<span class="postal-code">01741</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">Email: <a href="mailto:jg@freedesktop.org"><span class="email">jg@freedesktop.org</span></a></span><span class="vcardline">URI: <a href="http://gettys.wordpress.com/" class="url">http://gettys.wordpress.com/</a></span></address>
    1651          <address class="vcard"><span class="vcardline"><span class="fn">Jeffrey C. Mogul</span><span class="n hidden"><span class="family-name">Mogul</span><span class="given-name">Jeffrey C.</span></span></span><span class="org vcardline">Hewlett-Packard Company</span><span class="adr"><span class="street-address vcardline">HP Labs, Large Scale Systems Group</span><span class="street-address vcardline">1501 Page Mill Road, MS 1177</span><span class="vcardline"><span class="locality">Palo Alto</span>, <span class="region">CA</span>&nbsp;<span class="postal-code">94304</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">Email: <a href="mailto:JeffMogul@acm.org"><span class="email">JeffMogul@acm.org</span></a></span></address>
    1652          <address class="vcard"><span class="vcardline"><span class="fn">Henrik Frystyk Nielsen</span><span class="n hidden"><span class="family-name">Frystyk</span></span></span><span class="org vcardline">Microsoft Corporation</span><span class="adr"><span class="street-address vcardline">1 Microsoft Way</span><span class="vcardline"><span class="locality">Redmond</span>, <span class="region">WA</span>&nbsp;<span class="postal-code">98052</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">Email: <a href="mailto:henrikn@microsoft.com"><span class="email">henrikn@microsoft.com</span></a></span></address>
    1653          <address class="vcard"><span class="vcardline"><span class="fn">Larry Masinter</span><span class="n hidden"><span class="family-name">Masinter</span><span class="given-name">Larry</span></span></span><span class="org vcardline">Adobe Systems Incorporated</span><span class="adr"><span class="street-address vcardline">345 Park Ave</span><span class="vcardline"><span class="locality">San Jose</span>, <span class="region">CA</span>&nbsp;<span class="postal-code">95110</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">Email: <a href="mailto:LMM@acm.org"><span class="email">LMM@acm.org</span></a></span><span class="vcardline">URI: <a href="http://larry.masinter.net/" class="url">http://larry.masinter.net/</a></span></address>
    1654          <address class="vcard"><span class="vcardline"><span class="fn">Paul J. Leach</span><span class="n hidden"><span class="family-name">Leach</span><span class="given-name">Paul J.</span></span></span><span class="org vcardline">Microsoft Corporation</span><span class="adr"><span class="street-address vcardline">1 Microsoft Way</span><span class="vcardline"><span class="locality">Redmond</span>, <span class="region">WA</span>&nbsp;<span class="postal-code">98052</span></span></span><span class="vcardline">Email: <a href="mailto:paulle@microsoft.com"><span class="email">paulle@microsoft.com</span></a></span></address>
    1655          <address class="vcard"><span class="vcardline"><span class="fn">Tim Berners-Lee</span><span class="n hidden"><span class="family-name">Berners-Lee</span><span class="given-name">Tim</span></span></span><span class="org vcardline">World Wide Web Consortium</span><span class="adr"><span class="street-address vcardline">MIT Computer Science and Artificial Intelligence Laboratory</span><span class="street-address vcardline">The Stata Center, Building 32</span><span class="street-address vcardline">32 Vassar Street</span><span class="vcardline"><span class="locality">Cambridge</span>, <span class="region">MA</span>&nbsp;<span class="postal-code">02139</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">Email: <a href="mailto:timbl@w3.org"><span class="email">timbl@w3.org</span></a></span><span class="vcardline">URI: <a href="http://www.w3.org/People/Berners-Lee/" class="url">http://www.w3.org/People/Berners-Lee/</a></span></address>
    1656          <address class="vcard"><span class="vcardline"><span class="fn">Yves Lafon</span>
    1657                (editor)
    1658                <span class="n hidden"><span class="family-name">Lafon</span><span class="given-name">Yves</span></span></span><span class="org vcardline">World Wide Web Consortium</span><span class="adr"><span class="street-address vcardline">W3C / ERCIM</span><span class="street-address vcardline">2004, rte des Lucioles</span><span class="vcardline"><span class="locality">Sophia-Antipolis</span>, <span class="region">AM</span>&nbsp;<span class="postal-code">06902</span></span><span class="country-name vcardline">France</span></span><span class="vcardline">Email: <a href="mailto:ylafon@w3.org"><span class="email">ylafon@w3.org</span></a></span><span class="vcardline">URI: <a href="http://www.raubacapeu.net/people/yves/" class="url">http://www.raubacapeu.net/people/yves/</a></span></address>
    1659          <address class="vcard"><span class="vcardline"><span class="fn">Julian F. Reschke</span>
    1660                (editor)
    1661                <span class="n hidden"><span class="family-name">Reschke</span><span class="given-name">Julian F.</span></span></span><span class="org vcardline">greenbytes GmbH</span><span class="adr"><span class="street-address vcardline">Hafenweg 16</span><span class="vcardline"><span class="locality">Muenster</span>, <span class="region">NW</span>&nbsp;<span class="postal-code">48155</span></span><span class="country-name vcardline">Germany</span></span><span class="vcardline tel">Phone: <a href="tel:+492512807760"><span class="value">+49 251 2807760</span></a></span><span class="vcardline tel"><span class="type">Fax</span>: <a href="fax:+492512807761"><span class="value">+49 251 2807761</span></a></span><span class="vcardline">Email: <a href="mailto:julian.reschke@greenbytes.de"><span class="email">julian.reschke@greenbytes.de</span></a></span><span class="vcardline">URI: <a href="http://greenbytes.de/tech/webdav/" class="url">http://greenbytes.de/tech/webdav/</a></span></address>
     1728      <div id="differences.between.http.and.mime">
     1729         <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;<a href="#differences.between.http.and.mime">Differences between HTTP and MIME</a></h1>
     1730         <p id="rfc.section.A.p.1">HTTP/1.1 uses many of the constructs defined for Internet Mail (<a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a>) and the Multipurpose Internet Mail Extensions (MIME <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>) to allow a message-body to be transmitted in an open variety of representations and with extensible mechanisms. However,
     1731            RFC 2045 discusses mail, and HTTP has a few features that are different from those described in MIME. These differences were
     1732            carefully chosen to optimize performance over binary connections, to allow greater freedom in the use of new media types,
     1733            to make date comparisons easier, and to acknowledge the practice of some early HTTP servers and clients.
     1734         </p>
     1735         <p id="rfc.section.A.p.2">This appendix describes specific areas where HTTP differs from MIME. Proxies and gateways to strict MIME environments <em class="bcp14">SHOULD</em> be aware of these differences and provide the appropriate conversions where necessary. Proxies and gateways from MIME environments
     1736            to HTTP also need to be aware of the differences because some conversions might be required.
     1737         </p>
     1738         <div id="mime-version">
     1739            <div id="rfc.iref.m.1"></div>
     1740            <div id="rfc.iref.h.9"></div>
     1741            <h2 id="rfc.section.A.1"><a href="#rfc.section.A.1">A.1</a>&nbsp;<a href="#mime-version">MIME-Version</a></h2>
     1742            <p id="rfc.section.A.1.p.1">HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages <em class="bcp14">MAY</em> include a single MIME-Version header field to indicate what version of the MIME protocol was used to construct the message.
     1743               Use of the MIME-Version header field indicates that the message is in full compliance with the MIME protocol (as defined in <a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>). Proxies/gateways are responsible for ensuring full compliance (where possible) when exporting HTTP messages to strict MIME
     1744               environments.
     1745            </p>
     1746            <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.24"></span>  <a href="#mime-version" class="smpl">MIME-Version</a> = 1*<a href="#notation" class="smpl">DIGIT</a> "." 1*<a href="#notation" class="smpl">DIGIT</a>
     1747</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
     1748               document and not the MIME specification.
     1749            </p>
     1750         </div>
     1751         <div id="conversion.to.canonical.form">
     1752            <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a>&nbsp;<a href="#conversion.to.canonical.form">Conversion to Canonical Form</a></h2>
     1753            <p id="rfc.section.A.2.p.1">MIME requires that an Internet mail body-part be converted to canonical form prior to being transferred, as described in <a href="https://tools.ietf.org/html/rfc2049#section-4">Section 4</a> of <a href="#RFC2049" id="rfc.xref.RFC2049.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples">[RFC2049]</cite></a>. <a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section&nbsp;2.3.1</a> of this document describes the forms allowed for subtypes of the "text" media type when transmitted over HTTP. <a href="#RFC2046" id="rfc.xref.RFC2046.4"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> requires that content with a type of "text" represent line breaks as CRLF and forbids the use of CR or LF outside of line
     1754               break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a line break within text content when a message is transmitted
     1755               over HTTP.
     1756            </p>
     1757            <p id="rfc.section.A.2.p.2">Where it is possible, a proxy or gateway from HTTP to a strict MIME environment <em class="bcp14">SHOULD</em> translate all line breaks within the text media types described in <a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section&nbsp;2.3.1</a> of this document to the RFC 2049 canonical form of CRLF. Note, however, that this might be complicated by the presence of
     1758               a Content-Encoding and by the fact that HTTP allows the use of some character encodings which do not use octets 13 and 10
     1759               to represent CR and LF, respectively, as is the case for some multi-byte character encodings.
     1760            </p>
     1761            <p id="rfc.section.A.2.p.3">Conversion will break any cryptographic checksums applied to the original content unless the original content is already in
     1762               canonical form. Therefore, the canonical form is recommended for any content that uses such checksums in HTTP.
     1763            </p>
     1764         </div>
     1765         <div id="conversion.of.date.formats">
     1766            <h2 id="rfc.section.A.3"><a href="#rfc.section.A.3">A.3</a>&nbsp;<a href="#conversion.of.date.formats">Conversion of Date Formats</a></h2>
     1767            <p id="rfc.section.A.3.p.1">HTTP/1.1 uses a restricted set of date formats (<a href="p1-messaging.html#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) to simplify the process of date comparison. Proxies and gateways from other protocols <em class="bcp14">SHOULD</em> ensure that any Date header field present in a message conforms to one of the HTTP/1.1 formats and rewrite the date if necessary.
     1768            </p>
     1769         </div>
     1770         <div id="introduction.of.content-encoding">
     1771            <h2 id="rfc.section.A.4"><a href="#rfc.section.A.4">A.4</a>&nbsp;<a href="#introduction.of.content-encoding">Introduction of Content-Encoding</a></h2>
     1772            <p id="rfc.section.A.4.p.1">MIME does not include any concept equivalent to HTTP/1.1's Content-Encoding header field. Since this acts as a modifier on
     1773               the media type, proxies and gateways from HTTP to MIME-compliant protocols <em class="bcp14">MUST</em> either change the value of the Content-Type header field or decode the representation before forwarding the message. (Some
     1774               experimental applications of Content-Type for Internet mail have used a media-type parameter of ";conversions=&lt;content-coding&gt;"
     1775               to perform a function equivalent to Content-Encoding. However, this parameter is not part of the MIME standards).
     1776            </p>
     1777         </div>
     1778         <div id="no.content-transfer-encoding">
     1779            <h2 id="rfc.section.A.5"><a href="#rfc.section.A.5">A.5</a>&nbsp;<a href="#no.content-transfer-encoding">No Content-Transfer-Encoding</a></h2>
     1780            <p id="rfc.section.A.5.p.1">HTTP does not use the Content-Transfer-Encoding field of MIME. Proxies and gateways from MIME-compliant protocols to HTTP <em class="bcp14">MUST</em> remove any Content-Transfer-Encoding prior to delivering the response message to an HTTP client.
     1781            </p>
     1782            <p id="rfc.section.A.5.p.2">Proxies and gateways from HTTP to MIME-compliant protocols are responsible for ensuring that the message is in the correct
     1783               format and encoding for safe transport on that protocol, where "safe transport" is defined by the limitations of the protocol
     1784               being used. Such a proxy or gateway <em class="bcp14">SHOULD</em> label the data with an appropriate Content-Transfer-Encoding if doing so will improve the likelihood of safe transport over
     1785               the destination protocol.
     1786            </p>
     1787         </div>
     1788         <div id="introduction.of.transfer-encoding">
     1789            <h2 id="rfc.section.A.6"><a href="#rfc.section.A.6">A.6</a>&nbsp;<a href="#introduction.of.transfer-encoding">Introduction of Transfer-Encoding</a></h2>
     1790            <p id="rfc.section.A.6.p.1">HTTP/1.1 introduces the Transfer-Encoding header field (<a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 9.7</a> of <a href="#Part1" id="rfc.xref.Part1.23"><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.
     1791            </p>
     1792         </div>
     1793         <div id="mhtml.line.length">
     1794            <h2 id="rfc.section.A.7"><a href="#rfc.section.A.7">A.7</a>&nbsp;<a href="#mhtml.line.length">MHTML and Line Length Limitations</a></h2>
     1795            <p id="rfc.section.A.7.p.1">HTTP implementations which share code with MHTML <a href="#RFC2557" id="rfc.xref.RFC2557.2"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a> implementations need to be aware of MIME line length limitations. Since HTTP does not have this limitation, HTTP does not
     1796               fold long lines. MHTML messages being transported by HTTP follow all conventions of MHTML, including line length limitations
     1797               and folding, canonicalization, etc., since HTTP transports all message-bodies as payload (see <a href="#multipart.types" title="Multipart Types">Section&nbsp;2.3.2</a>) and does not interpret the content or any MIME header lines that might be contained therein.
     1798            </p>
     1799         </div>
    16621800      </div>
    1663       <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;<a id="differences.between.http.and.mime" href="#differences.between.http.and.mime">Differences between HTTP and MIME</a></h1>
    1664       <p id="rfc.section.A.p.1">HTTP/1.1 uses many of the constructs defined for Internet Mail (<a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a>) and the Multipurpose Internet Mail Extensions (MIME <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>) to allow a message-body to be transmitted in an open variety of representations and with extensible mechanisms. However,
    1665          RFC 2045 discusses mail, and HTTP has a few features that are different from those described in MIME. These differences were
    1666          carefully chosen to optimize performance over binary connections, to allow greater freedom in the use of new media types,
    1667          to make date comparisons easier, and to acknowledge the practice of some early HTTP servers and clients.
    1668       </p>
    1669       <p id="rfc.section.A.p.2">This appendix describes specific areas where HTTP differs from MIME. Proxies and gateways to strict MIME environments <em class="bcp14">SHOULD</em> be aware of these differences and provide the appropriate conversions where necessary. Proxies and gateways from MIME environments
    1670          to HTTP also need to be aware of the differences because some conversions might be required.
    1671       </p>
    1672       <div id="rfc.iref.m.1"></div>
    1673       <div id="rfc.iref.h.9"></div>
    1674       <h2 id="rfc.section.A.1"><a href="#rfc.section.A.1">A.1</a>&nbsp;<a id="mime-version" href="#mime-version">MIME-Version</a></h2>
    1675       <p id="rfc.section.A.1.p.1">HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages <em class="bcp14">MAY</em> include a single MIME-Version header field to indicate what version of the MIME protocol was used to construct the message.
    1676          Use of the MIME-Version header field indicates that the message is in full compliance with the MIME protocol (as defined in <a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>). Proxies/gateways are responsible for ensuring full compliance (where possible) when exporting HTTP messages to strict MIME
    1677          environments.
    1678       </p>
    1679       <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.24"></span>  <a href="#mime-version" class="smpl">MIME-Version</a> = 1*<a href="#notation" class="smpl">DIGIT</a> "." 1*<a href="#notation" class="smpl">DIGIT</a>
    1680 </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
    1681          document and not the MIME specification.
    1682       </p>
    1683       <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a>&nbsp;<a id="conversion.to.canonical.form" href="#conversion.to.canonical.form">Conversion to Canonical Form</a></h2>
    1684       <p id="rfc.section.A.2.p.1">MIME requires that an Internet mail body-part be converted to canonical form prior to being transferred, as described in <a href="http://tools.ietf.org/html/rfc2049#section-4">Section 4</a> of <a href="#RFC2049" id="rfc.xref.RFC2049.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples">[RFC2049]</cite></a>. <a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section&nbsp;2.3.1</a> of this document describes the forms allowed for subtypes of the "text" media type when transmitted over HTTP. <a href="#RFC2046" id="rfc.xref.RFC2046.4"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> requires that content with a type of "text" represent line breaks as CRLF and forbids the use of CR or LF outside of line
    1685          break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a line break within text content when a message is transmitted
    1686          over HTTP.
    1687       </p>
    1688       <p id="rfc.section.A.2.p.2">Where it is possible, a proxy or gateway from HTTP to a strict MIME environment <em class="bcp14">SHOULD</em> translate all line breaks within the text media types described in <a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section&nbsp;2.3.1</a> of this document to the RFC 2049 canonical form of CRLF. Note, however, that this might be complicated by the presence of
    1689          a Content-Encoding and by the fact that HTTP allows the use of some character encodings which do not use octets 13 and 10
    1690          to represent CR and LF, respectively, as is the case for some multi-byte character encodings.
    1691       </p>
    1692       <p id="rfc.section.A.2.p.3">Conversion will break any cryptographic checksums applied to the original content unless the original content is already in
    1693          canonical form. Therefore, the canonical form is recommended for any content that uses such checksums in HTTP.
    1694       </p>
    1695       <h2 id="rfc.section.A.3"><a href="#rfc.section.A.3">A.3</a>&nbsp;<a id="conversion.of.date.formats" href="#conversion.of.date.formats">Conversion of Date Formats</a></h2>
    1696       <p id="rfc.section.A.3.p.1">HTTP/1.1 uses a restricted set of date formats (<a href="p1-messaging.html#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) to simplify the process of date comparison. Proxies and gateways from other protocols <em class="bcp14">SHOULD</em> ensure that any Date header field present in a message conforms to one of the HTTP/1.1 formats and rewrite the date if necessary.
    1697       </p>
    1698       <h2 id="rfc.section.A.4"><a href="#rfc.section.A.4">A.4</a>&nbsp;<a id="introduction.of.content-encoding" href="#introduction.of.content-encoding">Introduction of Content-Encoding</a></h2>
    1699       <p id="rfc.section.A.4.p.1">MIME does not include any concept equivalent to HTTP/1.1's Content-Encoding header field. Since this acts as a modifier on
    1700          the media type, proxies and gateways from HTTP to MIME-compliant protocols <em class="bcp14">MUST</em> either change the value of the Content-Type header field or decode the representation before forwarding the message. (Some
    1701          experimental applications of Content-Type for Internet mail have used a media-type parameter of ";conversions=&lt;content-coding&gt;"
    1702          to perform a function equivalent to Content-Encoding. However, this parameter is not part of the MIME standards).
    1703       </p>
    1704       <h2 id="rfc.section.A.5"><a href="#rfc.section.A.5">A.5</a>&nbsp;<a id="no.content-transfer-encoding" href="#no.content-transfer-encoding">No Content-Transfer-Encoding</a></h2>
    1705       <p id="rfc.section.A.5.p.1">HTTP does not use the Content-Transfer-Encoding field of MIME. Proxies and gateways from MIME-compliant protocols to HTTP <em class="bcp14">MUST</em> remove any Content-Transfer-Encoding prior to delivering the response message to an HTTP client.
    1706       </p>
    1707       <p id="rfc.section.A.5.p.2">Proxies and gateways from HTTP to MIME-compliant protocols are responsible for ensuring that the message is in the correct
    1708          format and encoding for safe transport on that protocol, where "safe transport" is defined by the limitations of the protocol
    1709          being used. Such a proxy or gateway <em class="bcp14">SHOULD</em> label the data with an appropriate Content-Transfer-Encoding if doing so will improve the likelihood of safe transport over
    1710          the destination protocol.
    1711       </p>
    1712       <h2 id="rfc.section.A.6"><a href="#rfc.section.A.6">A.6</a>&nbsp;<a id="introduction.of.transfer-encoding" href="#introduction.of.transfer-encoding">Introduction of Transfer-Encoding</a></h2>
    1713       <p id="rfc.section.A.6.p.1">HTTP/1.1 introduces the Transfer-Encoding header field (<a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 9.7</a> of <a href="#Part1" id="rfc.xref.Part1.23"><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.
    1714       </p>
    1715       <h2 id="rfc.section.A.7"><a href="#rfc.section.A.7">A.7</a>&nbsp;<a id="mhtml.line.length" href="#mhtml.line.length">MHTML and Line Length Limitations</a></h2>
    1716       <p id="rfc.section.A.7.p.1">HTTP implementations which share code with MHTML <a href="#RFC2557" id="rfc.xref.RFC2557.2"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a> implementations need to be aware of MIME line length limitations. Since HTTP does not have this limitation, HTTP does not
    1717          fold long lines. MHTML messages being transported by HTTP follow all conventions of MHTML, including line length limitations
    1718          and folding, canonicalization, etc., since HTTP transports all message-bodies as payload (see <a href="#multipart.types" title="Multipart Types">Section&nbsp;2.3.2</a>) and does not interpret the content or any MIME header lines that might be contained therein.
    1719       </p>
    1720       <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="additional.features" href="#additional.features">Additional Features</a></h1>
    1721       <p id="rfc.section.B.p.1"> <a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a> and <a href="#RFC2068" id="rfc.xref.RFC2068.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> document protocol elements used by some existing HTTP implementations, but not consistently and correctly across most HTTP/1.1
    1722          applications. Implementors are advised to be aware of these features, but cannot rely upon their presence in, or interoperability
    1723          with, other HTTP/1.1 applications. Some of these describe proposed experimental features, and some describe features that
    1724          experimental deployment found lacking that are now addressed in the base HTTP/1.1 specification.
    1725       </p>
    1726       <p id="rfc.section.B.p.2">A number of other header fields, such as Content-Disposition and Title, from SMTP and MIME are also often implemented (see <a href="#draft-ietf-httpbis-content-disp" id="rfc.xref.draft-ietf-httpbis-content-disp.1"><cite title="Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)">[draft-ietf-httpbis-content-disp]</cite></a> and <a href="#RFC2076" id="rfc.xref.RFC2076.1"><cite title="Common Internet Message Headers">[RFC2076]</cite></a>).
    1727       </p>
    1728       <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h1>
    1729       <p id="rfc.section.C.p.1">Clarify contexts that charset is used in. (<a href="#character.sets" title="Character Encodings (charset)">Section&nbsp;2.1</a>)
    1730       </p>
    1731       <p id="rfc.section.C.p.2">Remove the default character encoding for text media types; the default now is whatever the media type definition says. (<a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section&nbsp;2.3.1</a>)
    1732       </p>
    1733       <p id="rfc.section.C.p.3">Change ABNF productions for header fields to only define the field value. (<a href="#header.fields" title="Header Field Definitions">Section&nbsp;6</a>)
    1734       </p>
    1735       <p id="rfc.section.C.p.4">Remove definition of Content-MD5 header field because it was inconsistently implemented with respect to partial responses,
    1736          and also because of known deficiencies in the hash algorithm itself (see <a href="#RFC6151" id="rfc.xref.RFC6151.1"><cite title="Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms">[RFC6151]</cite></a> for details). (<a href="#header.fields" title="Header Field Definitions">Section&nbsp;6</a>)
    1737       </p>
    1738       <p id="rfc.section.C.p.5">Remove ISO-8859-1 special-casing in Accept-Charset. (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.3" title="Accept-Charset">Section&nbsp;6.2</a>)
    1739       </p>
    1740       <p id="rfc.section.C.p.6">Remove base URI setting semantics for Content-Location due to poor implementation support, which was caused by too many broken
    1741          servers emitting bogus Content-Location header fields, and also the potentially undesirable effect of potentially breaking
    1742          relative links in content-negotiated resources. (<a href="#header.content-location" id="rfc.xref.header.content-location.3" title="Content-Location">Section&nbsp;6.7</a>)
    1743       </p>
    1744       <p id="rfc.section.C.p.7">Remove discussion of Content-Disposition header field, it is now defined by <a href="#draft-ietf-httpbis-content-disp" id="rfc.xref.draft-ietf-httpbis-content-disp.2"><cite title="Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)">[draft-ietf-httpbis-content-disp]</cite></a>. (<a href="#additional.features" title="Additional Features">Appendix&nbsp;B</a>)
    1745       </p>
    1746       <p id="rfc.section.C.p.8">Remove reference to non-existant identity transfer-coding value tokens. (<a href="#no.content-transfer-encoding" title="No Content-Transfer-Encoding">Appendix&nbsp;A.5</a>)
    1747       </p>
    1748       <h1 id="rfc.section.D"><a href="#rfc.section.D">D.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    1749       <div id="rfc.figure.u.30"></div> <pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
    1750  OWS media-range [ accept-params ] ] ) ]
    1751 <a href="#header.accept-charset" class="smpl">Accept-Charset</a> = *( "," OWS ) ( charset / "*" ) [ OWS ";" OWS "q="
    1752  qvalue ] *( OWS "," [ OWS ( charset / "*" ) [ OWS ";" OWS "q="
    1753  qvalue ] ] )
     1801      <div id="additional.features">
     1802         <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a href="#additional.features">Additional Features</a></h1>
     1803         <p id="rfc.section.B.p.1"><a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a> and <a href="#RFC2068" id="rfc.xref.RFC2068.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> document protocol elements used by some existing HTTP implementations, but not consistently and correctly across most HTTP/1.1
     1804            applications. Implementors are advised to be aware of these features, but cannot rely upon their presence in, or interoperability
     1805            with, other HTTP/1.1 applications. Some of these describe proposed experimental features, and some describe features that
     1806            experimental deployment found lacking that are now addressed in the base HTTP/1.1 specification.
     1807         </p>
     1808         <p id="rfc.section.B.p.2">A number of other header fields, such as Content-Disposition and Title, from SMTP and MIME are also often implemented (see <a href="#draft-ietf-httpbis-content-disp" id="rfc.xref.draft-ietf-httpbis-content-disp.1"><cite title="Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)">[draft-ietf-httpbis-content-disp]</cite></a> and <a href="#RFC2076" id="rfc.xref.RFC2076.1"><cite title="Common Internet Message Headers">[RFC2076]</cite></a>).
     1809         </p>
     1810      </div>
     1811      <div id="changes.from.rfc.2616">
     1812         <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a href="#changes.from.rfc.2616">Changes from RFC 2616</a></h1>
     1813         <p id="rfc.section.C.p.1">Clarify contexts that charset is used in. (<a href="#character.sets" title="Character Encodings (charset)">Section&nbsp;2.1</a>)
     1814         </p>
     1815         <p id="rfc.section.C.p.2">Remove the default character encoding for text media types; the default now is whatever the media type definition says. (<a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section&nbsp;2.3.1</a>)
     1816         </p>
     1817         <p id="rfc.section.C.p.3">Change ABNF productions for header fields to only define the field value. (<a href="#header.fields" title="Header Field Definitions">Section&nbsp;6</a>)
     1818         </p>
     1819         <p id="rfc.section.C.p.4">Remove definition of Content-MD5 header field because it was inconsistently implemented with respect to partial responses,
     1820            and also because of known deficiencies in the hash algorithm itself (see <a href="#RFC6151" id="rfc.xref.RFC6151.1"><cite title="Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms">[RFC6151]</cite></a> for details). (<a href="#header.fields" title="Header Field Definitions">Section&nbsp;6</a>)
     1821         </p>
     1822         <p id="rfc.section.C.p.5">Remove ISO-8859-1 special-casing in Accept-Charset. (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.3" title="Accept-Charset">Section&nbsp;6.2</a>)
     1823         </p>
     1824         <p id="rfc.section.C.p.6">Remove base URI setting semantics for Content-Location due to poor implementation support, which was caused by too many broken
     1825            servers emitting bogus Content-Location header fields, and also the potentially undesirable effect of potentially breaking
     1826            relative links in content-negotiated resources. (<a href="#header.content-location" id="rfc.xref.header.content-location.3" title="Content-Location">Section&nbsp;6.7</a>)
     1827         </p>
     1828         <p id="rfc.section.C.p.7">Remove discussion of Content-Disposition header field, it is now defined by <a href="#draft-ietf-httpbis-content-disp" id="rfc.xref.draft-ietf-httpbis-content-disp.2"><cite title="Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)">[draft-ietf-httpbis-content-disp]</cite></a>. (<a href="#additional.features" title="Additional Features">Appendix&nbsp;B</a>)
     1829         </p>
     1830         <p id="rfc.section.C.p.8">Remove reference to non-existant identity transfer-coding value tokens. (<a href="#no.content-transfer-encoding" title="No Content-Transfer-Encoding">Appendix&nbsp;A.5</a>)
     1831         </p>
     1832      </div>
     1833      <div id="collected.abnf">
     1834         <h1 id="rfc.section.D"><a href="#rfc.section.D">D.</a>&nbsp;<a href="#collected.abnf">Collected ABNF</a></h1>
     1835         <div id="rfc.figure.u.30"></div><pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
     1836 OWS ( media-range [ accept-params ] ) ] ) ]
     1837<a href="#header.accept-charset" class="smpl">Accept-Charset</a> = *( "," OWS ) ( ( charset / "*" ) [ OWS ";" OWS "q="
     1838 qvalue ] ) *( OWS "," [ OWS ( ( charset / "*" ) [ OWS ";" OWS "q="
     1839 qvalue ] ) ] )
    17541840<a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> = [ ( "," / ( codings [ OWS ";" OWS "q=" qvalue ] ) )
    1755  *( OWS "," [ OWS codings [ OWS ";" OWS "q=" qvalue ] ] ) ]
    1756 <a href="#header.accept-language" class="smpl">Accept-Language</a> = *( "," OWS ) language-range [ OWS ";" OWS "q="
    1757  qvalue ] *( OWS "," [ OWS language-range [ OWS ";" OWS "q=" qvalue ]
    1758  ] )
     1841 *( OWS "," [ OWS ( codings [ OWS ";" OWS "q=" qvalue ] ) ] ) ]
     1842<a href="#header.accept-language" class="smpl">Accept-Language</a> = *( "," OWS ) ( language-range [ OWS ";" OWS "q="
     1843 qvalue ] ) *( OWS "," [ OWS ( language-range [ OWS ";" OWS "q="
     1844 qvalue ] ) ] )
    17591845
    17601846<a href="#header.content-encoding" class="smpl">Content-Encoding</a> = *( "," OWS ) content-coding *( OWS "," [ OWS
     
    17981884
    17991885<a href="#core.rules" class="smpl">word</a> = &lt;word, defined in [Part1], Section 1.2.2&gt;
    1800 </pre> <div id="rfc.figure.u.31"></div>
    1801       <p>ABNF diagnostics:</p><pre class="inline">; Accept defined but not used
     1886</pre><div id="rfc.figure.u.31"></div>
     1887         <p>ABNF diagnostics:</p><pre class="inline">; Accept defined but not used
    18021888; Accept-Charset defined but not used
    18031889; Accept-Encoding defined but not used
     
    18081894; Content-Type defined but not used
    18091895; MIME-Version defined but not used
    1810 </pre><h1 id="rfc.section.E"><a href="#rfc.section.E">E.</a>&nbsp;<a id="change.log" href="#change.log">Change Log (to be removed by RFC Editor before publication)</a></h1>
    1811       <h2 id="rfc.section.E.1"><a href="#rfc.section.E.1">E.1</a>&nbsp;Since RFC 2616
    1812       </h2>
    1813       <p id="rfc.section.E.1.p.1">Extracted relevant partitions from <a href="#RFC2616" id="rfc.xref.RFC2616.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.
    1814       </p>
    1815       <h2 id="rfc.section.E.2"><a href="#rfc.section.E.2">E.2</a>&nbsp;Since draft-ietf-httpbis-p3-payload-00
    1816       </h2>
    1817       <p id="rfc.section.E.2.p.1">Closed issues: </p>
    1818       <ul>
    1819          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/8">http://tools.ietf.org/wg/httpbis/trac/ticket/8</a>&gt;: "Media Type Registrations" (&lt;<a href="http://purl.org/NET/http-errata#media-reg">http://purl.org/NET/http-errata#media-reg</a>&gt;)
    1820          </li>
    1821          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/14">http://tools.ietf.org/wg/httpbis/trac/ticket/14</a>&gt;: "Clarification regarding quoting of charset values" (&lt;<a href="http://purl.org/NET/http-errata#charactersets">http://purl.org/NET/http-errata#charactersets</a>&gt;)
    1822          </li>
    1823          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/16">http://tools.ietf.org/wg/httpbis/trac/ticket/16</a>&gt;: "Remove 'identity' token references" (&lt;<a href="http://purl.org/NET/http-errata#identity">http://purl.org/NET/http-errata#identity</a>&gt;)
    1824          </li>
    1825          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/25">http://tools.ietf.org/wg/httpbis/trac/ticket/25</a>&gt;: "Accept-Encoding BNF"
    1826          </li>
    1827          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/35">http://tools.ietf.org/wg/httpbis/trac/ticket/35</a>&gt;: "Normative and Informative references"
    1828          </li>
    1829          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/46">http://tools.ietf.org/wg/httpbis/trac/ticket/46</a>&gt;: "RFC1700 references"
    1830          </li>
    1831          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/55">http://tools.ietf.org/wg/httpbis/trac/ticket/55</a>&gt;: "Updating to RFC4288"
    1832          </li>
    1833          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/65">http://tools.ietf.org/wg/httpbis/trac/ticket/65</a>&gt;: "Informative references"
    1834          </li>
    1835          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/66">http://tools.ietf.org/wg/httpbis/trac/ticket/66</a>&gt;: "ISO-8859-1 Reference"
    1836          </li>
    1837          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/68">http://tools.ietf.org/wg/httpbis/trac/ticket/68</a>&gt;: "Encoding References Normative"
    1838          </li>
    1839          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/86">http://tools.ietf.org/wg/httpbis/trac/ticket/86</a>&gt;: "Normative up-to-date references"
    1840          </li>
    1841       </ul>
    1842       <h2 id="rfc.section.E.3"><a href="#rfc.section.E.3">E.3</a>&nbsp;Since draft-ietf-httpbis-p3-payload-01
    1843       </h2>
    1844       <p id="rfc.section.E.3.p.1">Ongoing work on ABNF conversion (&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>&gt;):
    1845       </p>
    1846       <ul>
    1847          <li>Add explicit references to BNF syntax and rules imported from other parts of the specification.</li>
    1848       </ul>
    1849       <h2 id="rfc.section.E.4"><a href="#rfc.section.E.4">E.4</a>&nbsp;<a id="changes.since.02" href="#changes.since.02">Since draft-ietf-httpbis-p3-payload-02</a></h2>
    1850       <p id="rfc.section.E.4.p.1">Closed issues: </p>
    1851       <ul>
    1852          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/67">http://tools.ietf.org/wg/httpbis/trac/ticket/67</a>&gt;: "Quoting Charsets"
    1853          </li>
    1854          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/105">http://tools.ietf.org/wg/httpbis/trac/ticket/105</a>&gt;: "Classification for Allow header"
    1855          </li>
    1856          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/115">http://tools.ietf.org/wg/httpbis/trac/ticket/115</a>&gt;: "missing default for qvalue in description of Accept-Encoding"
    1857          </li>
    1858       </ul>
    1859       <p id="rfc.section.E.4.p.2">Ongoing work on IANA Message Header Field Registration (&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>&gt;):
    1860       </p>
    1861       <ul>
    1862          <li>Reference RFC 3984, and update header field registrations for headers defined in this document.</li>
    1863       </ul>
    1864       <h2 id="rfc.section.E.5"><a href="#rfc.section.E.5">E.5</a>&nbsp;<a id="changes.since.03" href="#changes.since.03">Since draft-ietf-httpbis-p3-payload-03</a></h2>
    1865       <p id="rfc.section.E.5.p.1">Closed issues: </p>
    1866       <ul>
    1867          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/67">http://tools.ietf.org/wg/httpbis/trac/ticket/67</a>&gt;: "Quoting Charsets"
    1868          </li>
    1869          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/113">http://tools.ietf.org/wg/httpbis/trac/ticket/113</a>&gt;: "language tag matching (Accept-Language) vs RFC4647"
    1870          </li>
    1871          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/121">http://tools.ietf.org/wg/httpbis/trac/ticket/121</a>&gt;: "RFC 1806 has been replaced by RFC2183"
    1872          </li>
    1873       </ul>
    1874       <p id="rfc.section.E.5.p.2">Other changes: </p>
    1875       <ul>
    1876          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/68">http://tools.ietf.org/wg/httpbis/trac/ticket/68</a>&gt;: "Encoding References Normative" — rephrase the annotation and reference <a href="#BCP97" id="rfc.xref.BCP97.4"><cite title="Handling Normative References to Standards-Track Documents">[BCP97]</cite></a>.
    1877          </li>
    1878       </ul>
    1879       <h2 id="rfc.section.E.6"><a href="#rfc.section.E.6">E.6</a>&nbsp;<a id="changes.since.04" href="#changes.since.04">Since draft-ietf-httpbis-p3-payload-04</a></h2>
    1880       <p id="rfc.section.E.6.p.1">Closed issues: </p>
    1881       <ul>
    1882          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/132">http://tools.ietf.org/wg/httpbis/trac/ticket/132</a>&gt;: "RFC 2822 is updated by RFC 5322"
    1883          </li>
    1884       </ul>
    1885       <p id="rfc.section.E.6.p.2">Ongoing work on ABNF conversion (&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>&gt;):
    1886       </p>
    1887       <ul>
    1888          <li>Use "/" instead of "|" for alternatives.</li>
    1889          <li>Introduce new ABNF rules for "bad" whitespace ("BWS"), optional whitespace ("OWS") and required whitespace ("RWS").</li>
    1890          <li>Rewrite ABNFs to spell out whitespace rules, factor out header field value format definitions.</li>
    1891       </ul>
    1892       <h2 id="rfc.section.E.7"><a href="#rfc.section.E.7">E.7</a>&nbsp;<a id="changes.since.05" href="#changes.since.05">Since draft-ietf-httpbis-p3-payload-05</a></h2>
    1893       <p id="rfc.section.E.7.p.1">Closed issues: </p>
    1894       <ul>
    1895          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/118">http://tools.ietf.org/wg/httpbis/trac/ticket/118</a>&gt;: "Join "Differences Between HTTP Entities and RFC 2045 Entities"?"
    1896          </li>
    1897       </ul>
    1898       <p id="rfc.section.E.7.p.2">Final work on ABNF conversion (&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>&gt;):
    1899       </p>
    1900       <ul>
    1901          <li>Add appendix containing collected and expanded ABNF, reorganize ABNF introduction.</li>
    1902       </ul>
    1903       <p id="rfc.section.E.7.p.3">Other changes: </p>
    1904       <ul>
    1905          <li>Move definition of quality values into Part 1.</li>
    1906       </ul>
    1907       <h2 id="rfc.section.E.8"><a href="#rfc.section.E.8">E.8</a>&nbsp;<a id="changes.since.06" href="#changes.since.06">Since draft-ietf-httpbis-p3-payload-06</a></h2>
    1908       <p id="rfc.section.E.8.p.1">Closed issues: </p>
    1909       <ul>
    1910          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/80">http://tools.ietf.org/wg/httpbis/trac/ticket/80</a>&gt;: "Content-Location isn't special"
    1911          </li>
    1912          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/155">http://tools.ietf.org/wg/httpbis/trac/ticket/155</a>&gt;: "Content Sniffing"
    1913          </li>
    1914       </ul>
    1915       <h2 id="rfc.section.E.9"><a href="#rfc.section.E.9">E.9</a>&nbsp;<a id="changes.since.07" href="#changes.since.07">Since draft-ietf-httpbis-p3-payload-07</a></h2>
    1916       <p id="rfc.section.E.9.p.1">Closed issues: </p>
    1917       <ul>
    1918          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/13">http://tools.ietf.org/wg/httpbis/trac/ticket/13</a>&gt;: "Updated reference for language tags"
    1919          </li>
    1920          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/110">http://tools.ietf.org/wg/httpbis/trac/ticket/110</a>&gt;: "Clarify rules for determining what entities a response carries"
    1921          </li>
    1922          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/154">http://tools.ietf.org/wg/httpbis/trac/ticket/154</a>&gt;: "Content-Location base-setting problems"
    1923          </li>
    1924          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/155">http://tools.ietf.org/wg/httpbis/trac/ticket/155</a>&gt;: "Content Sniffing"
    1925          </li>
    1926          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/188">http://tools.ietf.org/wg/httpbis/trac/ticket/188</a>&gt;: "pick IANA policy (RFC5226) for Transfer Coding / Content Coding"
    1927          </li>
    1928          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/189">http://tools.ietf.org/wg/httpbis/trac/ticket/189</a>&gt;: "move definitions of gzip/deflate/compress to part 1"
    1929          </li>
    1930       </ul>
    1931       <p id="rfc.section.E.9.p.2">Partly resolved issues: </p>
    1932       <ul>
    1933          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/148">http://tools.ietf.org/wg/httpbis/trac/ticket/148</a>&gt;: "update IANA requirements wrt Transfer-Coding values" (add the IANA Considerations subsection)
    1934          </li>
    1935          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/149">http://tools.ietf.org/wg/httpbis/trac/ticket/149</a>&gt;: "update IANA requirements wrt Content-Coding values" (add the IANA Considerations subsection)
    1936          </li>
    1937       </ul>
    1938       <h2 id="rfc.section.E.10"><a href="#rfc.section.E.10">E.10</a>&nbsp;<a id="changes.since.08" href="#changes.since.08">Since draft-ietf-httpbis-p3-payload-08</a></h2>
    1939       <p id="rfc.section.E.10.p.1">Closed issues: </p>
    1940       <ul>
    1941          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/81">http://tools.ietf.org/wg/httpbis/trac/ticket/81</a>&gt;: "Content Negotiation for media types"
    1942          </li>
    1943          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/181">http://tools.ietf.org/wg/httpbis/trac/ticket/181</a>&gt;: "Accept-Language: which RFC4647 filtering?"
    1944          </li>
    1945       </ul>
    1946       <h2 id="rfc.section.E.11"><a href="#rfc.section.E.11">E.11</a>&nbsp;<a id="changes.since.09" href="#changes.since.09">Since draft-ietf-httpbis-p3-payload-09</a></h2>
    1947       <p id="rfc.section.E.11.p.1">Closed issues: </p>
    1948       <ul>
    1949          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/122">http://tools.ietf.org/wg/httpbis/trac/ticket/122</a>&gt;: "MIME-Version not listed in P1, general header fields"
    1950          </li>
    1951          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/143">http://tools.ietf.org/wg/httpbis/trac/ticket/143</a>&gt;: "IANA registry for content/transfer encodings"
    1952          </li>
    1953          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/155">http://tools.ietf.org/wg/httpbis/trac/ticket/155</a>&gt;: "Content Sniffing"
    1954          </li>
    1955          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/200">http://tools.ietf.org/wg/httpbis/trac/ticket/200</a>&gt;: "use of term "word" when talking about header structure"
    1956          </li>
    1957       </ul>
    1958       <p id="rfc.section.E.11.p.2">Partly resolved issues: </p>
    1959       <ul>
    1960          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/196">http://tools.ietf.org/wg/httpbis/trac/ticket/196</a>&gt;: "Term for the requested resource's URI"
    1961          </li>
    1962       </ul>
    1963       <h2 id="rfc.section.E.12"><a href="#rfc.section.E.12">E.12</a>&nbsp;<a id="changes.since.10" href="#changes.since.10">Since draft-ietf-httpbis-p3-payload-10</a></h2>
    1964       <p id="rfc.section.E.12.p.1">Closed issues: </p>
    1965       <ul>
    1966          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/69">http://tools.ietf.org/wg/httpbis/trac/ticket/69</a>&gt;: "Clarify 'Requested Variant'"
    1967          </li>
    1968          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/80">http://tools.ietf.org/wg/httpbis/trac/ticket/80</a>&gt;: "Content-Location isn't special"
    1969          </li>
    1970          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/90">http://tools.ietf.org/wg/httpbis/trac/ticket/90</a>&gt;: "Delimiting messages with multipart/byteranges"
    1971          </li>
    1972          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/109">http://tools.ietf.org/wg/httpbis/trac/ticket/109</a>&gt;: "Clarify entity / representation / variant terminology"
    1973          </li>
    1974          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/136">http://tools.ietf.org/wg/httpbis/trac/ticket/136</a>&gt;: "confusing req. language for Content-Location"
    1975          </li>
    1976          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/167">http://tools.ietf.org/wg/httpbis/trac/ticket/167</a>&gt;: "Content-Location on 304 responses"
    1977          </li>
    1978          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/183">http://tools.ietf.org/wg/httpbis/trac/ticket/183</a>&gt;: "'requested resource' in content-encoding definition"
    1979          </li>
    1980          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/220">http://tools.ietf.org/wg/httpbis/trac/ticket/220</a>&gt;: "consider removing the 'changes from 2068' sections"
    1981          </li>
    1982       </ul>
    1983       <p id="rfc.section.E.12.p.2">Partly resolved issues: </p>
    1984       <ul>
    1985          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/178">http://tools.ietf.org/wg/httpbis/trac/ticket/178</a>&gt;: "Content-MD5 and partial responses"
    1986          </li>
    1987       </ul>
    1988       <h2 id="rfc.section.E.13"><a href="#rfc.section.E.13">E.13</a>&nbsp;<a id="changes.since.11" href="#changes.since.11">Since draft-ietf-httpbis-p3-payload-11</a></h2>
    1989       <p id="rfc.section.E.13.p.1">Closed issues: </p>
    1990       <ul>
    1991          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/123">http://tools.ietf.org/wg/httpbis/trac/ticket/123</a>&gt;: "Factor out Content-Disposition"
    1992          </li>
    1993       </ul>
    1994       <h2 id="rfc.section.E.14"><a href="#rfc.section.E.14">E.14</a>&nbsp;<a id="changes.since.12" href="#changes.since.12">Since draft-ietf-httpbis-p3-payload-12</a></h2>
    1995       <p id="rfc.section.E.14.p.1">Closed issues: </p>
    1996       <ul>
    1997          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/224">http://tools.ietf.org/wg/httpbis/trac/ticket/224</a>&gt;: "Header Classification"
    1998          </li>
    1999          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/276">http://tools.ietf.org/wg/httpbis/trac/ticket/276</a>&gt;: "untangle ABNFs for header fields"
    2000          </li>
    2001          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/277">http://tools.ietf.org/wg/httpbis/trac/ticket/277</a>&gt;: "potentially misleading MAY in media-type def"
    2002          </li>
    2003       </ul>
    2004       <h2 id="rfc.section.E.15"><a href="#rfc.section.E.15">E.15</a>&nbsp;<a id="changes.since.13" href="#changes.since.13">Since draft-ietf-httpbis-p3-payload-13</a></h2>
    2005       <p id="rfc.section.E.15.p.1">Closed issues: </p>
    2006       <ul>
    2007          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/20">http://tools.ietf.org/wg/httpbis/trac/ticket/20</a>&gt;: "Default charsets for text media types"
    2008          </li>
    2009          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/178">http://tools.ietf.org/wg/httpbis/trac/ticket/178</a>&gt;: "Content-MD5 and partial responses"
    2010          </li>
    2011          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/276">http://tools.ietf.org/wg/httpbis/trac/ticket/276</a>&gt;: "untangle ABNFs for header fields"
    2012          </li>
    2013          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/281">http://tools.ietf.org/wg/httpbis/trac/ticket/281</a>&gt;: "confusing undefined parameter in media range example"
    2014          </li>
    2015       </ul>
     1896</pre></div>
     1897      <div id="change.log">
     1898         <h1 id="rfc.section.E"><a href="#rfc.section.E">E.</a>&nbsp;<a href="#change.log">Change Log (to be removed by RFC Editor before publication)</a></h1>
     1899         <div>
     1900            <h2 id="rfc.section.E.1"><a href="#rfc.section.E.1">E.1</a>&nbsp;Since RFC 2616
     1901            </h2>
     1902            <p id="rfc.section.E.1.p.1">Extracted relevant partitions from <a href="#RFC2616" id="rfc.xref.RFC2616.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.
     1903            </p>
     1904         </div>
     1905         <div>
     1906            <h2 id="rfc.section.E.2"><a href="#rfc.section.E.2">E.2</a>&nbsp;Since draft-ietf-httpbis-p3-payload-00
     1907            </h2>
     1908            <p id="rfc.section.E.2.p.1">Closed issues: </p>
     1909            <ul>
     1910               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/8">http://tools.ietf.org/wg/httpbis/trac/ticket/8</a>&gt;: "Media Type Registrations" (&lt;<a href="http://purl.org/NET/http-errata#media-reg">http://purl.org/NET/http-errata#media-reg</a>&gt;)
     1911               </li>
     1912               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/14">http://tools.ietf.org/wg/httpbis/trac/ticket/14</a>&gt;: "Clarification regarding quoting of charset values" (&lt;<a href="http://purl.org/NET/http-errata#charactersets">http://purl.org/NET/http-errata#charactersets</a>&gt;)
     1913               </li>
     1914               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/16">http://tools.ietf.org/wg/httpbis/trac/ticket/16</a>&gt;: "Remove 'identity' token references" (&lt;<a href="http://purl.org/NET/http-errata#identity">http://purl.org/NET/http-errata#identity</a>&gt;)
     1915               </li>
     1916               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/25">http://tools.ietf.org/wg/httpbis/trac/ticket/25</a>&gt;: "Accept-Encoding BNF"
     1917               </li>
     1918               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/35">http://tools.ietf.org/wg/httpbis/trac/ticket/35</a>&gt;: "Normative and Informative references"
     1919               </li>
     1920               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/46">http://tools.ietf.org/wg/httpbis/trac/ticket/46</a>&gt;: "RFC1700 references"
     1921               </li>
     1922               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/55">http://tools.ietf.org/wg/httpbis/trac/ticket/55</a>&gt;: "Updating to RFC4288"
     1923               </li>
     1924               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/65">http://tools.ietf.org/wg/httpbis/trac/ticket/65</a>&gt;: "Informative references"
     1925               </li>
     1926               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/66">http://tools.ietf.org/wg/httpbis/trac/ticket/66</a>&gt;: "ISO-8859-1 Reference"
     1927               </li>
     1928               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/68">http://tools.ietf.org/wg/httpbis/trac/ticket/68</a>&gt;: "Encoding References Normative"
     1929               </li>
     1930               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/86">http://tools.ietf.org/wg/httpbis/trac/ticket/86</a>&gt;: "Normative up-to-date references"
     1931               </li>
     1932            </ul>
     1933         </div>
     1934         <div>
     1935            <h2 id="rfc.section.E.3"><a href="#rfc.section.E.3">E.3</a>&nbsp;Since draft-ietf-httpbis-p3-payload-01
     1936            </h2>
     1937            <p id="rfc.section.E.3.p.1">Ongoing work on ABNF conversion (&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>&gt;):
     1938            </p>
     1939            <ul>
     1940               <li>Add explicit references to BNF syntax and rules imported from other parts of the specification.</li>
     1941            </ul>
     1942         </div>
     1943         <div id="changes.since.02">
     1944            <h2 id="rfc.section.E.4"><a href="#rfc.section.E.4">E.4</a>&nbsp;<a href="#changes.since.02">Since draft-ietf-httpbis-p3-payload-02</a></h2>
     1945            <p id="rfc.section.E.4.p.1">Closed issues: </p>
     1946            <ul>
     1947               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/67">http://tools.ietf.org/wg/httpbis/trac/ticket/67</a>&gt;: "Quoting Charsets"
     1948               </li>
     1949               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/105">http://tools.ietf.org/wg/httpbis/trac/ticket/105</a>&gt;: "Classification for Allow header"
     1950               </li>
     1951               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/115">http://tools.ietf.org/wg/httpbis/trac/ticket/115</a>&gt;: "missing default for qvalue in description of Accept-Encoding"
     1952               </li>
     1953            </ul>
     1954            <p id="rfc.section.E.4.p.2">Ongoing work on IANA Message Header Field Registration (&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/40">http://tools.ietf.org/wg/httpbis/trac/ticket/40</a>&gt;):
     1955            </p>
     1956            <ul>
     1957               <li>Reference RFC 3984, and update header field registrations for headers defined in this document.</li>
     1958            </ul>
     1959         </div>
     1960         <div id="changes.since.03">
     1961            <h2 id="rfc.section.E.5"><a href="#rfc.section.E.5">E.5</a>&nbsp;<a href="#changes.since.03">Since draft-ietf-httpbis-p3-payload-03</a></h2>
     1962            <p id="rfc.section.E.5.p.1">Closed issues: </p>
     1963            <ul>
     1964               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/67">http://tools.ietf.org/wg/httpbis/trac/ticket/67</a>&gt;: "Quoting Charsets"
     1965               </li>
     1966               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/113">http://tools.ietf.org/wg/httpbis/trac/ticket/113</a>&gt;: "language tag matching (Accept-Language) vs RFC4647"
     1967               </li>
     1968               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/121">http://tools.ietf.org/wg/httpbis/trac/ticket/121</a>&gt;: "RFC 1806 has been replaced by RFC2183"
     1969               </li>
     1970            </ul>
     1971            <p id="rfc.section.E.5.p.2">Other changes: </p>
     1972            <ul>
     1973               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/68">http://tools.ietf.org/wg/httpbis/trac/ticket/68</a>&gt;: "Encoding References Normative" — rephrase the annotation and reference <a href="#BCP97" id="rfc.xref.BCP97.4"><cite title="Handling Normative References to Standards-Track Documents">[BCP97]</cite></a>.
     1974               </li>
     1975            </ul>
     1976         </div>
     1977         <div id="changes.since.04">
     1978            <h2 id="rfc.section.E.6"><a href="#rfc.section.E.6">E.6</a>&nbsp;<a href="#changes.since.04">Since draft-ietf-httpbis-p3-payload-04</a></h2>
     1979            <p id="rfc.section.E.6.p.1">Closed issues: </p>
     1980            <ul>
     1981               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/132">http://tools.ietf.org/wg/httpbis/trac/ticket/132</a>&gt;: "RFC 2822 is updated by RFC 5322"
     1982               </li>
     1983            </ul>
     1984            <p id="rfc.section.E.6.p.2">Ongoing work on ABNF conversion (&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>&gt;):
     1985            </p>
     1986            <ul>
     1987               <li>Use "/" instead of "|" for alternatives.</li>
     1988               <li>Introduce new ABNF rules for "bad" whitespace ("BWS"), optional whitespace ("OWS") and required whitespace ("RWS").</li>
     1989               <li>Rewrite ABNFs to spell out whitespace rules, factor out header field value format definitions.</li>
     1990            </ul>
     1991         </div>
     1992         <div id="changes.since.05">
     1993            <h2 id="rfc.section.E.7"><a href="#rfc.section.E.7">E.7</a>&nbsp;<a href="#changes.since.05">Since draft-ietf-httpbis-p3-payload-05</a></h2>
     1994            <p id="rfc.section.E.7.p.1">Closed issues: </p>
     1995            <ul>
     1996               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/118">http://tools.ietf.org/wg/httpbis/trac/ticket/118</a>&gt;: "Join "Differences Between HTTP Entities and RFC 2045 Entities"?"
     1997               </li>
     1998            </ul>
     1999            <p id="rfc.section.E.7.p.2">Final work on ABNF conversion (&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>&gt;):
     2000            </p>
     2001            <ul>
     2002               <li>Add appendix containing collected and expanded ABNF, reorganize ABNF introduction.</li>
     2003            </ul>
     2004            <p id="rfc.section.E.7.p.3">Other changes: </p>
     2005            <ul>
     2006               <li>Move definition of quality values into Part 1.</li>
     2007            </ul>
     2008         </div>
     2009         <div id="changes.since.06">
     2010            <h2 id="rfc.section.E.8"><a href="#rfc.section.E.8">E.8</a>&nbsp;<a href="#changes.since.06">Since draft-ietf-httpbis-p3-payload-06</a></h2>
     2011            <p id="rfc.section.E.8.p.1">Closed issues: </p>
     2012            <ul>
     2013               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/80">http://tools.ietf.org/wg/httpbis/trac/ticket/80</a>&gt;: "Content-Location isn't special"
     2014               </li>
     2015               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/155">http://tools.ietf.org/wg/httpbis/trac/ticket/155</a>&gt;: "Content Sniffing"
     2016               </li>
     2017            </ul>
     2018         </div>
     2019         <div id="changes.since.07">
     2020            <h2 id="rfc.section.E.9"><a href="#rfc.section.E.9">E.9</a>&nbsp;<a href="#changes.since.07">Since draft-ietf-httpbis-p3-payload-07</a></h2>
     2021            <p id="rfc.section.E.9.p.1">Closed issues: </p>
     2022            <ul>
     2023               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/13">http://tools.ietf.org/wg/httpbis/trac/ticket/13</a>&gt;: "Updated reference for language tags"
     2024               </li>
     2025               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/110">http://tools.ietf.org/wg/httpbis/trac/ticket/110</a>&gt;: "Clarify rules for determining what entities a response carries"
     2026               </li>
     2027               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/154">http://tools.ietf.org/wg/httpbis/trac/ticket/154</a>&gt;: "Content-Location base-setting problems"
     2028               </li>
     2029               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/155">http://tools.ietf.org/wg/httpbis/trac/ticket/155</a>&gt;: "Content Sniffing"
     2030               </li>
     2031               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/188">http://tools.ietf.org/wg/httpbis/trac/ticket/188</a>&gt;: "pick IANA policy (RFC5226) for Transfer Coding / Content Coding"
     2032               </li>
     2033               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/189">http://tools.ietf.org/wg/httpbis/trac/ticket/189</a>&gt;: "move definitions of gzip/deflate/compress to part 1"
     2034               </li>
     2035            </ul>
     2036            <p id="rfc.section.E.9.p.2">Partly resolved issues: </p>
     2037            <ul>
     2038               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/148">http://tools.ietf.org/wg/httpbis/trac/ticket/148</a>&gt;: "update IANA requirements wrt Transfer-Coding values" (add the IANA Considerations subsection)
     2039               </li>
     2040               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/149">http://tools.ietf.org/wg/httpbis/trac/ticket/149</a>&gt;: "update IANA requirements wrt Content-Coding values" (add the IANA Considerations subsection)
     2041               </li>
     2042            </ul>
     2043         </div>
     2044         <div id="changes.since.08">
     2045            <h2 id="rfc.section.E.10"><a href="#rfc.section.E.10">E.10</a>&nbsp;<a href="#changes.since.08">Since draft-ietf-httpbis-p3-payload-08</a></h2>
     2046            <p id="rfc.section.E.10.p.1">Closed issues: </p>
     2047            <ul>
     2048               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/81">http://tools.ietf.org/wg/httpbis/trac/ticket/81</a>&gt;: "Content Negotiation for media types"
     2049               </li>
     2050               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/181">http://tools.ietf.org/wg/httpbis/trac/ticket/181</a>&gt;: "Accept-Language: which RFC4647 filtering?"
     2051               </li>
     2052            </ul>
     2053         </div>
     2054         <div id="changes.since.09">
     2055            <h2 id="rfc.section.E.11"><a href="#rfc.section.E.11">E.11</a>&nbsp;<a href="#changes.since.09">Since draft-ietf-httpbis-p3-payload-09</a></h2>
     2056            <p id="rfc.section.E.11.p.1">Closed issues: </p>
     2057            <ul>
     2058               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/122">http://tools.ietf.org/wg/httpbis/trac/ticket/122</a>&gt;: "MIME-Version not listed in P1, general header fields"
     2059               </li>
     2060               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/143">http://tools.ietf.org/wg/httpbis/trac/ticket/143</a>&gt;: "IANA registry for content/transfer encodings"
     2061               </li>
     2062               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/155">http://tools.ietf.org/wg/httpbis/trac/ticket/155</a>&gt;: "Content Sniffing"
     2063               </li>
     2064               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/200">http://tools.ietf.org/wg/httpbis/trac/ticket/200</a>&gt;: "use of term "word" when talking about header structure"
     2065               </li>
     2066            </ul>
     2067            <p id="rfc.section.E.11.p.2">Partly resolved issues: </p>
     2068            <ul>
     2069               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/196">http://tools.ietf.org/wg/httpbis/trac/ticket/196</a>&gt;: "Term for the requested resource's URI"
     2070               </li>
     2071            </ul>
     2072         </div>
     2073         <div id="changes.since.10">
     2074            <h2 id="rfc.section.E.12"><a href="#rfc.section.E.12">E.12</a>&nbsp;<a href="#changes.since.10">Since draft-ietf-httpbis-p3-payload-10</a></h2>
     2075            <p id="rfc.section.E.12.p.1">Closed issues: </p>
     2076            <ul>
     2077               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/69">http://tools.ietf.org/wg/httpbis/trac/ticket/69</a>&gt;: "Clarify 'Requested Variant'"
     2078               </li>
     2079               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/80">http://tools.ietf.org/wg/httpbis/trac/ticket/80</a>&gt;: "Content-Location isn't special"
     2080               </li>
     2081               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/90">http://tools.ietf.org/wg/httpbis/trac/ticket/90</a>&gt;: "Delimiting messages with multipart/byteranges"
     2082               </li>
     2083               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/109">http://tools.ietf.org/wg/httpbis/trac/ticket/109</a>&gt;: "Clarify entity / representation / variant terminology"
     2084               </li>
     2085               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/136">http://tools.ietf.org/wg/httpbis/trac/ticket/136</a>&gt;: "confusing req. language for Content-Location"
     2086               </li>
     2087               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/167">http://tools.ietf.org/wg/httpbis/trac/ticket/167</a>&gt;: "Content-Location on 304 responses"
     2088               </li>
     2089               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/183">http://tools.ietf.org/wg/httpbis/trac/ticket/183</a>&gt;: "'requested resource' in content-encoding definition"
     2090               </li>
     2091               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/220">http://tools.ietf.org/wg/httpbis/trac/ticket/220</a>&gt;: "consider removing the 'changes from 2068' sections"
     2092               </li>
     2093            </ul>
     2094            <p id="rfc.section.E.12.p.2">Partly resolved issues: </p>
     2095            <ul>
     2096               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/178">http://tools.ietf.org/wg/httpbis/trac/ticket/178</a>&gt;: "Content-MD5 and partial responses"
     2097               </li>
     2098            </ul>
     2099         </div>
     2100         <div id="changes.since.11">
     2101            <h2 id="rfc.section.E.13"><a href="#rfc.section.E.13">E.13</a>&nbsp;<a href="#changes.since.11">Since draft-ietf-httpbis-p3-payload-11</a></h2>
     2102            <p id="rfc.section.E.13.p.1">Closed issues: </p>
     2103            <ul>
     2104               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/123">http://tools.ietf.org/wg/httpbis/trac/ticket/123</a>&gt;: "Factor out Content-Disposition"
     2105               </li>
     2106            </ul>
     2107         </div>
     2108         <div id="changes.since.12">
     2109            <h2 id="rfc.section.E.14"><a href="#rfc.section.E.14">E.14</a>&nbsp;<a href="#changes.since.12">Since draft-ietf-httpbis-p3-payload-12</a></h2>
     2110            <p id="rfc.section.E.14.p.1">Closed issues: </p>
     2111            <ul>
     2112               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/224">http://tools.ietf.org/wg/httpbis/trac/ticket/224</a>&gt;: "Header Classification"
     2113               </li>
     2114               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/276">http://tools.ietf.org/wg/httpbis/trac/ticket/276</a>&gt;: "untangle ABNFs for header fields"
     2115               </li>
     2116               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/277">http://tools.ietf.org/wg/httpbis/trac/ticket/277</a>&gt;: "potentially misleading MAY in media-type def"
     2117               </li>
     2118            </ul>
     2119         </div>
     2120         <div id="changes.since.13">
     2121            <h2 id="rfc.section.E.15"><a href="#rfc.section.E.15">E.15</a>&nbsp;<a href="#changes.since.13">Since draft-ietf-httpbis-p3-payload-13</a></h2>
     2122            <p id="rfc.section.E.15.p.1">Closed issues: </p>
     2123            <ul>
     2124               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/20">http://tools.ietf.org/wg/httpbis/trac/ticket/20</a>&gt;: "Default charsets for text media types"
     2125               </li>
     2126               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/178">http://tools.ietf.org/wg/httpbis/trac/ticket/178</a>&gt;: "Content-MD5 and partial responses"
     2127               </li>
     2128               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/276">http://tools.ietf.org/wg/httpbis/trac/ticket/276</a>&gt;: "untangle ABNFs for header fields"
     2129               </li>
     2130               <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/281">http://tools.ietf.org/wg/httpbis/trac/ticket/281</a>&gt;: "confusing undefined parameter in media range example"
     2131               </li>
     2132            </ul>
     2133         </div>
     2134      </div>
    20162135      <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1>
    20172136      <p class="noprint"><a href="#rfc.index.A">A</a> <a href="#rfc.index.B">B</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.D">D</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a>
     
    22032322         </ul>
    22042323      </div>
     2324      <div class="avoidbreak">
     2325         <h1 id="rfc.authors"><a href="#rfc.authors">Authors' Addresses</a></h1>
     2326         <p><b>Roy T. Fielding</b>
     2327            (editor)
     2328            <br>Adobe Systems Incorporated<br>345 Park Ave<br>San Jose, CA&nbsp;95110<br>USA<br>Email: <a href="mailto:fielding@gbiv.com">fielding@gbiv.com</a><br>URI: <a href="http://roy.gbiv.com/">http://roy.gbiv.com/</a></p>
     2329         <p><b>Jim Gettys</b><br>Alcatel-Lucent Bell Labs<br>21 Oak Knoll Road<br>Carlisle, MA&nbsp;01741<br>USA<br>Email: <a href="mailto:jg@freedesktop.org">jg@freedesktop.org</a><br>URI: <a href="http://gettys.wordpress.com/">http://gettys.wordpress.com/</a></p>
     2330         <p><b>Jeffrey C. Mogul</b><br>Hewlett-Packard Company<br>HP Labs, Large Scale Systems Group<br>1501 Page Mill Road, MS 1177<br>Palo Alto, CA&nbsp;94304<br>USA<br>Email: <a href="mailto:JeffMogul@acm.org">JeffMogul@acm.org</a></p>
     2331         <p><b>Henrik Frystyk Nielsen</b><br>Microsoft Corporation<br>1 Microsoft Way<br>Redmond, WA&nbsp;98052<br>USA<br>Email: <a href="mailto:henrikn@microsoft.com">henrikn@microsoft.com</a></p>
     2332         <p><b>Larry Masinter</b><br>Adobe Systems Incorporated<br>345 Park Ave<br>San Jose, CA&nbsp;95110<br>USA<br>Email: <a href="mailto:LMM@acm.org">LMM@acm.org</a><br>URI: <a href="http://larry.masinter.net/">http://larry.masinter.net/</a></p>
     2333         <p><b>Paul J. Leach</b><br>Microsoft Corporation<br>1 Microsoft Way<br>Redmond, WA&nbsp;98052<br>Email: <a href="mailto:paulle@microsoft.com">paulle@microsoft.com</a></p>
     2334         <p><b>Tim Berners-Lee</b><br>World Wide Web Consortium<br>MIT Computer Science and Artificial Intelligence Laboratory<br>The Stata Center, Building 32<br>32 Vassar Street<br>Cambridge, MA&nbsp;02139<br>USA<br>Email: <a href="mailto:timbl@w3.org">timbl@w3.org</a><br>URI: <a href="http://www.w3.org/People/Berners-Lee/">http://www.w3.org/People/Berners-Lee/</a></p>
     2335         <p><b>Yves Lafon</b>
     2336            (editor)
     2337            <br>World Wide Web Consortium<br>W3C / ERCIM<br>2004, rte des Lucioles<br>Sophia-Antipolis, AM&nbsp;06902<br>France<br>Email: <a href="mailto:ylafon@w3.org">ylafon@w3.org</a><br>URI: <a href="http://www.raubacapeu.net/people/yves/">http://www.raubacapeu.net/people/yves/</a></p>
     2338         <p><b>Julian F. Reschke</b>
     2339            (editor)
     2340            <br>greenbytes GmbH<br>Hafenweg 16<br>Muenster, NW&nbsp;48155<br>Germany<br>Phone: <a href="tel:+492512807760">+49 251 2807760</a><br>Fax: <a href="fax:+492512807761">+49 251 2807761</a><br>Email: <a href="mailto:julian.reschke@greenbytes.de">julian.reschke@greenbytes.de</a><br>URI: <a href="http://greenbytes.de/tech/webdav/">http://greenbytes.de/tech/webdav/</a></p>
     2341      </div>
    22052342   </body>
    22062343</html>
Note: See TracChangeset for help on using the changeset viewer.