Source: https://trac.ietf.org/trac/httpbis/changeset/1335/draft-ietf-httpbis/latest
Timestamp: 2019-12-10 02:47:16
Document Index: 491787210

Matched Legal Cases: ['art3', 'art3', 'art 3', 'art3', 'art3', 'art3', 'art3', 'art3', 'art3', 'art3', 'art3', 'art3', 'art3', 'art3', 'art3', 'art3', 'art3', 'art3', 'art3', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1', 'art1']

Changeset 1335 for draft-ietf-httpbis/latest – Hypertext Transfer Protocol Wiki
Changeset 1335 for draft-ietf-httpbis/latest
Jul 19, 2011, 12:13:24 AM (8 years ago)
Tune strength of requirements on Accept re: 406 (see #285)
p3-payload.html (modified) (19 diffs)
content: "Expires January 20, 2012";
<meta name="dct.issued" scheme="ISO8601" content="2011-07-19">
<td class="left">Expires: January 20, 2012</td>
<td class="right">July 19, 2011</td>
<p>This Internet-Draft will expire on January 20, 2012.</p>
<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>
<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
not acceptable according to the accept header fields sent in the request.
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>).
<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
<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>
<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>
<li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.8">8.4.7</a></li>
<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>
<!ENTITY p3-header-fields "<xref target='Part3' x:rel='#header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
<section title="Since draft-ietf-httpbis-p2-semantics-15" anchor="changes.since.15">
<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/285"/>:
"Strength of requirements on Accept re: 406"
is present in a request, but the server cannot send a response which is acceptable, then the server can either send a response
in another format, or a 406 (Not Acceptable) response.
header field is present in a request, but the server cannot send a response which is acceptable, then the server can either
use another character encoding, or send a 406 (Not Acceptable) response.
<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).
<p id="rfc.section.E.17.p.1">None yet.</p>
<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>
Server-driven negotiation allows the user agent to specify its preferences,
but it cannot expect responses to always honour them. For example, the origin
server might not implement server-driven negotiation, or it might decide that
sending a response that doesn't conform to them is better than sending a 406
(Not Acceptable) response.
Many of the mechanisms for expressing preferences use quality values to
declare relative preference. See &qvalue; for more information.
client accepts all media types. If an Accept header field is present in a
request, but the server cannot send a response which is acceptable, then
the server can either send a response in another format, or a 406 (Not
Acceptable) response.
character encoding is acceptable. If an Accept-Charset header field is
present in a request, but the server cannot send a response which is
acceptable, then the server can either use another character encoding, or
If an Accept-Encoding field is present in a request, but the server cannot
send a response which is acceptable, then the server &SHOULD; send a
response without any encoding (i.e., the "identity" encoding).
<section title="Since draft-ietf-httpbis-p3-payload-15" anchor="changes.since.15">