Ignore:
Timestamp:
Jul 19, 2011, 12:13:24 AM (8 years ago)
Author:
julian.reschke@…
Message:

Tune strength of requirements on Accept re: 406 (see #285)

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

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p2-semantics.html

    r1333 r1335  
    359359  }
    360360  @bottom-center {
    361        content: "Expires January 19, 2012";
     361       content: "Expires January 20, 2012";
    362362  }
    363363  @bottom-right {
    … …  
    409409      <meta name="dct.creator" content="Reschke, J. F.">
    410410      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    411       <meta name="dct.issued" scheme="ISO8601" content="2011-07-18">
     411      <meta name="dct.issued" scheme="ISO8601" content="2011-07-19">
    412412      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    413413      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields.">
    … …  
    440440            </tr>
    441441            <tr>
    442                <td class="left">Expires: January 19, 2012</td>
     442               <td class="left">Expires: January 20, 2012</td>
    443443               <td class="right">HP</td>
    444444            </tr>
    … …  
    493493            <tr>
    494494               <td class="left"></td>
    495                <td class="right">July 18, 2011</td>
     495               <td class="right">July 19, 2011</td>
    496496            </tr>
    497497         </tbody>
    … …  
    522522         in progress”.
    523523      </p>
    524       <p>This Internet-Draft will expire on January 19, 2012.</p>
     524      <p>This Internet-Draft will expire on January 20, 2012.</p>
    525525      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    526526      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    18011801      <h3 id="rfc.section.8.4.7"><a href="#rfc.section.8.4.7">8.4.7</a>&nbsp;<a id="status.406" href="#status.406">406 Not Acceptable</a></h3>
    18021802      <p id="rfc.section.8.4.7.p.1">The resource identified by the request is only capable of generating response representations which have content characteristics
    1803          not acceptable according to the accept header fields sent in the request.
     1803         not acceptable according to the Accept and Accept-* header fields sent in the request (see <a href="p3-payload.html#header.fields" title="Header Field Definitions">Section 6</a> of <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>).
    18041804      </p>
    18051805      <p id="rfc.section.8.4.7.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include a representation containing a list of available representation characteristics and location(s) from which the user
    … …  
    20502050      </div>
    20512051      <div class="note" id="rfc.section.9.4.p.9">
    2052          <p> <b>Note:</b> The Content-Location header field (<a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation.
     2052         <p> <b>Note:</b> The Content-Location header field (<a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation.
    20532053            It is therefore possible for a response to contain header fields for both Location and Content-Location.
    20542054         </p>
    … …  
    30623062      </ul>
    30633063      <h2 id="rfc.section.C.17"><a href="#rfc.section.C.17">C.17</a>&nbsp;<a id="changes.since.15" href="#changes.since.15">Since draft-ietf-httpbis-p2-semantics-15</a></h2>
    3064       <p id="rfc.section.C.17.p.1">None yet.</p>
     3064      <p id="rfc.section.C.17.p.1">Closed issues: </p>
     3065      <ul>
     3066         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/285">http://tools.ietf.org/wg/httpbis/trac/ticket/285</a>&gt;: "Strength of requirements on Accept re: 406"
     3067         </li>
     3068      </ul>
    30653069      <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1>
    30663070      <p class="noprint"><a href="#rfc.index.1">1</a> <a href="#rfc.index.2">2</a> <a href="#rfc.index.3">3</a> <a href="#rfc.index.4">4</a> <a href="#rfc.index.5">5</a> <a href="#rfc.index.A">A</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.D">D</a> <a href="#rfc.index.E">E</a> <a href="#rfc.index.F">F</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.L">L</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.O">O</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.T">T</a> <a href="#rfc.index.U">U</a>
    … …  
    32363240                     </ul>
    32373241                  </li>
    3238                   <li><em>Part3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.1">3</a>, <a href="#rfc.xref.Part3.2">3</a>, <a href="#rfc.xref.Part3.3">3</a>, <a href="#rfc.xref.Part3.4">3</a>, <a href="#rfc.xref.Part3.5">6</a>, <a href="#rfc.xref.Part3.6">7.5</a>, <a href="#rfc.xref.Part3.7">8.3.1</a>, <a href="#rfc.xref.Part3.8">9.4</a>, <a href="#Part3"><b>13.1</b></a><ul>
     3242                  <li><em>Part3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.1">3</a>, <a href="#rfc.xref.Part3.2">3</a>, <a href="#rfc.xref.Part3.3">3</a>, <a href="#rfc.xref.Part3.4">3</a>, <a href="#rfc.xref.Part3.5">6</a>, <a href="#rfc.xref.Part3.6">7.5</a>, <a href="#rfc.xref.Part3.7">8.3.1</a>, <a href="#rfc.xref.Part3.8">8.4.7</a>, <a href="#rfc.xref.Part3.9">9.4</a>, <a href="#Part3"><b>13.1</b></a><ul>
    32393243                        <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.7">8.3.1</a></li>
    32403244                        <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.1">3</a></li>
     3245                        <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.8">8.4.7</a></li>
    32413246                        <li><em>Section 6.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.2">3</a></li>
    32423247                        <li><em>Section 6.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.3">3</a></li>
    32433248                        <li><em>Section 6.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.4">3</a></li>
    3244                         <li><em>Section 6.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.6">7.5</a>, <a href="#rfc.xref.Part3.8">9.4</a></li>
     3249                        <li><em>Section 6.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.6">7.5</a>, <a href="#rfc.xref.Part3.9">9.4</a></li>
    32453250                     </ul>
    32463251                  </li>

  • draft-ietf-httpbis/latest/p2-semantics.xml

    r1326 r1335  
    7474  <!ENTITY status-412                 "<xref target='Part4' x:rel='#status.412' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    7575  <!ENTITY status-416                 "<xref target='Part5' x:rel='#status.416' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     76  <!ENTITY p3-header-fields           "<xref target='Part3' x:rel='#header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    7677  <!ENTITY p4-status-codes            "<xref target='Part4' x:rel='#status.code.definitions' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    7778  <!ENTITY p5-status-codes            "<xref target='Part5' x:rel='#status.code.definitions' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    18171818   The resource identified by the request is only capable of generating
    18181819   response representations which have content characteristics not acceptable
    1819    according to the accept header fields sent in the request.
     1820   according to the Accept and Accept-* header fields sent in the request
     1821   (see &p3-header-fields;).
    18201822</t>
    18211823<t>
    … …  
    41584160<section title="Since draft-ietf-httpbis-p2-semantics-15" anchor="changes.since.15">
    41594161<t>
    4160   None yet.
     4162  Closed issues:
     4163  <list style="symbols">
     4164    <t>
     4165      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/285"/>:
     4166      "Strength of requirements on Accept re: 406"
     4167    </t>
     4168  </list>
    41614169</t>
    41624170</section>

  • draft-ietf-httpbis/latest/p3-payload.html

    r1333 r1335  
    359359  }
    360360  @bottom-center {
    361        content: "Expires January 19, 2012";
     361       content: "Expires January 20, 2012";
    362362  }
    363363  @bottom-right {
    … …  
    408408      <meta name="dct.creator" content="Reschke, J. F.">
    409409      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest">
    410       <meta name="dct.issued" scheme="ISO8601" content="2011-07-18">
     410      <meta name="dct.issued" scheme="ISO8601" content="2011-07-19">
    411411      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    412412      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 3 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation.">
    … …  
    434434            </tr>
    435435            <tr>
    436                <td class="left">Expires: January 19, 2012</td>
     436               <td class="left">Expires: January 20, 2012</td>
    437437               <td class="right">J. Mogul</td>
    438438            </tr>
    … …  
    491491            <tr>
    492492               <td class="left"></td>
    493                <td class="right">July 18, 2011</td>
     493               <td class="right">July 19, 2011</td>
    494494            </tr>
    495495         </tbody>
    … …  
    519519         in progress”.
    520520      </p>
    521       <p>This Internet-Draft will expire on January 19, 2012.</p>
     521      <p>This Internet-Draft will expire on January 20, 2012.</p>
    522522      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    523523      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    989989         <li>It might limit a public cache's ability to use the same response for multiple user's requests.</li>
    990990      </ol>
    991       <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
     991      <p id="rfc.section.5.1.p.4">Server-driven negotiation allows the user agent to specify its preferences, but it cannot expect responses to always honour
     992         them. For example, the origin server might not implement server-driven negotiation, or it might decide that sending a response
     993         that doesn't conform to them is better than sending a 406 (Not Acceptable) response.
     994      </p>
     995      <p id="rfc.section.5.1.p.5">Many of the mechanisms for expressing preferences use quality values to declare relative preference. See <a href="p1-messaging.html#quality.values" title="Quality Values">Section 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> for more information.
     996      </p>
     997      <p id="rfc.section.5.1.p.6">HTTP/1.1 includes the following header fields for enabling server-driven negotiation through description of user agent capabilities
    992998         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
    993999         within extension header fields not defined by this specification.
    9941000      </p>
    995       <div class="note" id="rfc.section.5.1.p.5">
     1001      <div class="note" id="rfc.section.5.1.p.7">
    9961002         <p> <b>Note:</b> In practice, User-Agent based negotiation is fragile, because new clients might not be recognized.
    9971003         </p>
    9981004      </div>
    999       <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.
     1005      <p id="rfc.section.5.1.p.8">The Vary header field (<a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.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.
    10001006      </p>
    10011007      <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>
    … …  
    10401046      <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
    10411047         "q" parameter (if any) separates the media-range parameter(s) from the accept-params. Quality factors allow the user or user
    1042          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.
     1048         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.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The default value is q=1.
    10431049      </p>
    10441050      <div class="note" id="rfc.section.6.1.p.5">
    … …  
    10551061      </p>
    10561062      <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
    1057          is present, and if the server cannot send a response which is acceptable according to the combined Accept field value, then
    1058          the server <em class="bcp14">SHOULD</em> send a 406 (Not Acceptable) response.
     1063         is present in a request, but the server cannot send a response which is acceptable, then the server can either send a response
     1064         in another format, or a 406 (Not Acceptable) response.
    10591065      </p>
    10601066      <p id="rfc.section.6.1.p.10">A more elaborate example is</p>
    … …  
    11381144      </p>
    11391145      <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
    1140          header field is present, and if the server cannot send a response which is acceptable according to the Accept-Charset header
    1141          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.
     1146         header field is present in a request, but the server cannot send a response which is acceptable, then the server can either
     1147         use another character encoding, or send a 406 (Not Acceptable) response.
    11421148      </p>
    11431149      <div id="rfc.iref.a.3"></div>
    … …  
    11591165      <ol>
    11601166         <li>If the content-coding is one of the content-codings listed in the Accept-Encoding field, then it is acceptable, unless it
    1161             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".)
     1167            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.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, a qvalue of 0 means "not acceptable".)
    11621168         </li>
    11631169         <li>The special "*" symbol in an Accept-Encoding field matches any available content-coding not explicitly listed in the header
    … …  
    11701176         </li>
    11711177      </ol>
    1172       <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
    1173          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.
     1178      <p id="rfc.section.6.3.p.7">If an Accept-Encoding field is present in a request, but the server cannot send a response which is acceptable, then the server <em class="bcp14">SHOULD</em> send a response without any encoding (i.e., the "identity" encoding).
    11741179      </p>
    11751180      <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,
    … …  
    12791284      </p>
    12801285      <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>
    1281 </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
     1286</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.19"><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
    12821287         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.
    12831288      </p>
    … …  
    14271432                  <td class="left">compress</td>
    14281433                  <td class="left">UNIX "compress" program method</td>
    1429                   <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>
     1434                  <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.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>
    14301435                  </td>
    14311436               </tr>
    … …  
    14341439                  <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>)
    14351440                  </td>
    1436                   <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>
     1441                  <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.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>
    14371442                  </td>
    14381443               </tr>
    … …  
    14401445                  <td class="left">gzip</td>
    14411446                  <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>
    1442                   <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>
     1447                  <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.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>
    14431448                  </td>
    14441449               </tr>
    … …  
    16961701      </p>
    16971702      <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>
    1698       <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.
     1703      <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.23"><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.
    16991704      </p>
    17001705      <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>
    … …  
    17131718      </p>
    17141719      <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>
    1715       <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.
     1720      <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.24"><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.
    17161721      </p>
    17171722      <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>
    … …  
    20192024      <p id="rfc.section.E.16.p.1">None.</p>
    20202025      <h2 id="rfc.section.E.17"><a href="#rfc.section.E.17">E.17</a>&nbsp;<a id="changes.since.15" href="#changes.since.15">Since draft-ietf-httpbis-p3-payload-15</a></h2>
    2021       <p id="rfc.section.E.17.p.1">None yet.</p>
     2026      <p id="rfc.section.E.17.p.1">Closed issues: </p>
     2027      <ul>
     2028         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/285">http://tools.ietf.org/wg/httpbis/trac/ticket/285</a>&gt;: "Strength of requirements on Accept re: 406"
     2029         </li>
     2030      </ul>
    20222031      <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1>
    20232032      <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>
    … …  
    21132122            </li>
    21142123            <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
    2115                   <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.3</a>, <a href="#rfc.xref.Part1.2">1.3.1</a>, <a href="#rfc.xref.Part1.3">1.3.1</a>, <a href="#rfc.xref.Part1.4">1.3.1</a>, <a href="#rfc.xref.Part1.5">1.3.1</a>, <a href="#rfc.xref.Part1.6">1.3.2</a>, <a href="#rfc.xref.Part1.7">1.3.2</a>, <a href="#rfc.xref.Part1.8">1.3.2</a>, <a href="#rfc.xref.Part1.9">2.2</a>, <a href="#rfc.xref.Part1.10">2.2</a>, <a href="#rfc.xref.Part1.11">2.2</a>, <a href="#rfc.xref.Part1.12">2.2.1</a>, <a href="#rfc.xref.Part1.13">2.2.1</a>, <a href="#rfc.xref.Part1.14">3.1</a>, <a href="#rfc.xref.Part1.15">3.2</a>, <a href="#rfc.xref.Part1.16">6.1</a>, <a href="#rfc.xref.Part1.17">6.3</a>, <a href="#rfc.xref.Part1.18">6.7</a>, <a href="#rfc.xref.Part1.19">7.2</a>, <a href="#rfc.xref.Part1.20">7.2</a>, <a href="#rfc.xref.Part1.21">7.2</a>, <a href="#Part1"><b>10.1</b></a>, <a href="#rfc.xref.Part1.22">A.3</a>, <a href="#rfc.xref.Part1.23">A.6</a><ul>
     2124                  <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.3</a>, <a href="#rfc.xref.Part1.2">1.3.1</a>, <a href="#rfc.xref.Part1.3">1.3.1</a>, <a href="#rfc.xref.Part1.4">1.3.1</a>, <a href="#rfc.xref.Part1.5">1.3.1</a>, <a href="#rfc.xref.Part1.6">1.3.2</a>, <a href="#rfc.xref.Part1.7">1.3.2</a>, <a href="#rfc.xref.Part1.8">1.3.2</a>, <a href="#rfc.xref.Part1.9">2.2</a>, <a href="#rfc.xref.Part1.10">2.2</a>, <a href="#rfc.xref.Part1.11">2.2</a>, <a href="#rfc.xref.Part1.12">2.2.1</a>, <a href="#rfc.xref.Part1.13">2.2.1</a>, <a href="#rfc.xref.Part1.14">3.1</a>, <a href="#rfc.xref.Part1.15">3.2</a>, <a href="#rfc.xref.Part1.16">5.1</a>, <a href="#rfc.xref.Part1.17">6.1</a>, <a href="#rfc.xref.Part1.18">6.3</a>, <a href="#rfc.xref.Part1.19">6.7</a>, <a href="#rfc.xref.Part1.20">7.2</a>, <a href="#rfc.xref.Part1.21">7.2</a>, <a href="#rfc.xref.Part1.22">7.2</a>, <a href="#Part1"><b>10.1</b></a>, <a href="#rfc.xref.Part1.23">A.3</a>, <a href="#rfc.xref.Part1.24">A.6</a><ul>
    21162125                        <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1.3</a></li>
    21172126                        <li><em>Section 1.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.2">1.3.1</a>, <a href="#rfc.xref.Part1.3">1.3.1</a>, <a href="#rfc.xref.Part1.4">1.3.1</a>, <a href="#rfc.xref.Part1.5">1.3.1</a></li>
    21182127                        <li><em>Section 2.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.6">1.3.2</a>, <a href="#rfc.xref.Part1.7">1.3.2</a></li>
    21192128                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.15">3.2</a></li>
    2120                         <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.18">6.7</a></li>
    2121                         <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.22">A.3</a></li>
     2129                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.19">6.7</a></li>
     2130                        <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.23">A.3</a></li>
    21222131                        <li><em>Section 6.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.12">2.2.1</a></li>
    2123                         <li><em>Section 6.2.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.9">2.2</a>, <a href="#rfc.xref.Part1.19">7.2</a></li>
     2132                        <li><em>Section 6.2.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.9">2.2</a>, <a href="#rfc.xref.Part1.20">7.2</a></li>
    21242133                        <li><em>Section 6.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.13">2.2.1</a></li>
    2125                         <li><em>Section 6.2.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.10">2.2</a>, <a href="#rfc.xref.Part1.20">7.2</a></li>
    2126                         <li><em>Section 6.2.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.11">2.2</a>, <a href="#rfc.xref.Part1.21">7.2</a></li>
    2127                         <li><em>Section 6.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.8">1.3.2</a>, <a href="#rfc.xref.Part1.16">6.1</a>, <a href="#rfc.xref.Part1.17">6.3</a></li>
     2134                        <li><em>Section 6.2.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.10">2.2</a>, <a href="#rfc.xref.Part1.21">7.2</a></li>
     2135                        <li><em>Section 6.2.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.11">2.2</a>, <a href="#rfc.xref.Part1.22">7.2</a></li>
     2136                        <li><em>Section 6.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.8">1.3.2</a>, <a href="#rfc.xref.Part1.16">5.1</a>, <a href="#rfc.xref.Part1.17">6.1</a>, <a href="#rfc.xref.Part1.18">6.3</a></li>
    21282137                        <li><em>Section 9.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.14">3.1</a></li>
    2129                         <li><em>Section 9.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.23">A.6</a></li>
     2138                        <li><em>Section 9.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.24">A.6</a></li>
    21302139                     </ul>
    21312140                  </li>

  • draft-ietf-httpbis/latest/p3-payload.xml

    r1328 r1335  
    845845</t>
    846846<t>
     847   Server-driven negotiation allows the user agent to specify its preferences,
     848   but it cannot expect responses to always honour them. For example, the origin
     849   server might not implement server-driven negotiation, or it might decide that
     850   sending a response that doesn't conform to them is better than sending a 406
     851   (Not Acceptable) response.
     852</t>
     853<t>
     854   Many of the mechanisms for expressing preferences use quality values to
     855   declare relative preference. See &qvalue; for more information.
     856</t>
     857<t>
    847858   HTTP/1.1 includes the following header fields for enabling
    848859   server-driven negotiation through description of user agent
    … …  
    973984<t>
    974985   If no Accept header field is present, then it is assumed that the
    975    client accepts all media types. If an Accept header field is present,
    976    and if the server cannot send a response which is acceptable
    977    according to the combined Accept field value, then the server &SHOULD;
    978    send a 406 (Not Acceptable) response.
     986   client accepts all media types. If an Accept header field is present in a
     987   request, but the server cannot send a response which is acceptable, then
     988   the server can either send a response in another format, or a 406 (Not
     989   Acceptable) response.
    979990</t>
    980991<t>
    … …  
    10701081<t>
    10711082   If no Accept-Charset header field is present, the default is that any
    1072    character encoding is acceptable. If an Accept-Charset header field is present,
    1073    and if the server cannot send a response which is acceptable
    1074    according to the Accept-Charset header field, then the server &SHOULD; send
    1075    an error response with the 406 (Not Acceptable) status code, though
    1076    the sending of an unacceptable response is also allowed.
     1083   character encoding is acceptable. If an Accept-Charset header field is
     1084   present in a request, but the server cannot send a response which is
     1085   acceptable, then the server can either use another character encoding, or
     1086   send a 406 (Not Acceptable) response.
    10771087</t>
    10781088</section>
    … …  
    11311141</t>
    11321142<t>
    1133    If an Accept-Encoding field is present in a request, and if the
    1134    server cannot send a response which is acceptable according to the
    1135    Accept-Encoding header field, then the server &SHOULD; send an error response
    1136    with the 406 (Not Acceptable) status code.
     1143   If an Accept-Encoding field is present in a request, but the server cannot
     1144   send a response which is acceptable, then the server &SHOULD; send a
     1145   response without any encoding (i.e., the "identity" encoding).
    11371146</t>
    11381147<t>
    … …  
    30113020<section title="Since draft-ietf-httpbis-p3-payload-15" anchor="changes.since.15">
    30123021<t>
    3013   None yet.
     3022  Closed issues:
     3023  <list style="symbols">
     3024    <t>
     3025      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/285"/>:
     3026      "Strength of requirements on Accept re: 406"
     3027    </t>
     3028  </list>
    30143029</t>
    30153030</section>
Note: See TracChangeset for help on using the changeset viewer.