Ignore:
Timestamp:
Jul 4, 2012, 10:59:15 AM (7 years ago)
Author:
julian.reschke@…
Message:

Work-in-progress: hyperlink status codes definitions (4xx range)

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

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r1710 r1713  
    11711171      </p>
    11721172      <p id="rfc.section.3.1.1.p.8">Unfortunately, some user agents fail to properly encode hypertext references that have embedded whitespace, sending the characters
    1173          directly instead of properly percent-encoding the disallowed characters. Recipients of an invalid request-line <em class="bcp14">SHOULD</em> respond with either a 400 (Bad Request) error or a 301 (Moved Permanently) redirect with the request-target properly encoded.
    1174          Recipients <em class="bcp14">SHOULD NOT</em> attempt to autocorrect and then process the request without a redirect, since the invalid request-line might be deliberately
     1173         directly instead of properly percent-encoding the disallowed characters. Recipients of an invalid request-line <em class="bcp14">SHOULD</em> respond with either a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> error or a 301 (Moved Permanently) redirect with the request-target properly encoded. Recipients <em class="bcp14">SHOULD NOT</em> attempt to autocorrect and then process the request without a redirect, since the invalid request-line might be deliberately
    11751174         crafted to bypass security filters along the request chain.
    11761175      </p>
    11771176      <p id="rfc.section.3.1.1.p.9">HTTP does not place a pre-defined limit on the length of a request-line. A server that receives a method longer than any that
    1178          it implements <em class="bcp14">SHOULD</em> respond with either a 405 (Not Allowed), if it is an origin server, or a <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a> status code. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the 414 (URI Too Long) status code if the received request-target
    1179          would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 4.6.12</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     1177         it implements <em class="bcp14">SHOULD</em> respond with either a <a href="p2-semantics.html#status.405" class="smpl">405 (Method Not Allowed)</a>, if it is an origin server, or a <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a> status code. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the <a href="p2-semantics.html#status.414" class="smpl">414 (URI Too Long)</a> status code if the received request-target would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 4.6.12</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    11801178      </p>
    11811179      <p id="rfc.section.3.1.1.p.10">Various ad-hoc limitations on request-line length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support, at a minimum, request-line lengths of up to 8000 octets.
     
    14661464               the message body length is determined by reading the connection until it is closed by the server. If a Transfer-Encoding header
    14671465               field is present in a request and the "chunked" transfer-coding is not the final encoding, the message body length cannot
    1468                be determined reliably; the server <em class="bcp14">MUST</em> respond with the 400 (Bad Request) status code and then close the connection.
     1466               be determined reliably; the server <em class="bcp14">MUST</em> respond with the <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> status code and then close the connection.
    14691467            </p>
    14701468            <p>If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the Transfer-Encoding
     
    14761474         <li>
    14771475            <p>If a message is received without Transfer-Encoding and with either multiple Content-Length header fields having differing
    1478                field-values or a single Content-Length header field having an invalid value, then the message framing is invalid and <em class="bcp14">MUST</em> be treated as an error to prevent request or response smuggling. If this is a request message, the server <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status code and then close the connection. If this is a response message received by a proxy,
    1479                the proxy <em class="bcp14">MUST</em> discard the received response, send a <a href="p2-semantics.html#status.502" class="smpl">502 (Bad Gateway)</a> status code as its downstream response, and then close the connection. If this is a response message received by a user-agent,
     1476               field-values or a single Content-Length header field having an invalid value, then the message framing is invalid and <em class="bcp14">MUST</em> be treated as an error to prevent request or response smuggling. If this is a request message, the server <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> status code and then close the connection. If this is a response message received by a proxy, the proxy <em class="bcp14">MUST</em> discard the received response, send a <a href="p2-semantics.html#status.502" class="smpl">502 (Bad Gateway)</a> status code as its downstream response, and then close the connection. If this is a response message received by a user-agent,
    14801477               it <em class="bcp14">MUST</em> be treated as an error by discarding the message and closing the connection.
    14811478            </p>
     
    15011498         with HTTP/1.0.
    15021499      </p>
    1503       <p id="rfc.section.3.3.3.p.4">A server <em class="bcp14">MAY</em> reject a request that contains a message body but not a Content-Length by responding with 411 (Length Required).
     1500      <p id="rfc.section.3.3.3.p.4">A server <em class="bcp14">MAY</em> reject a request that contains a message body but not a Content-Length by responding with <a href="p2-semantics.html#status.411" class="smpl">411 (Length Required)</a>.
    15041501      </p>
    15051502      <p id="rfc.section.3.3.3.p.5">Unless a transfer-coding other than "chunked" has been applied, a client that sends a request containing a message body <em class="bcp14">SHOULD</em> use a valid Content-Length header field if the message body length is known in advance, rather than the "chunked" encoding,
    1506          since some existing services respond to "chunked" with a 411 (Length Required) status code even though they understand the
    1507          chunked encoding. This is typically because such services are implemented via a gateway that requires a content-length in
    1508          advance of being called and the server is unable or unwilling to buffer the entire request before processing.
     1503         since some existing services respond to "chunked" with a <a href="p2-semantics.html#status.411" class="smpl">411 (Length Required)</a> status code even though they understand the chunked encoding. This is typically because such services are implemented via
     1504         a gateway that requires a content-length in advance of being called and the server is unable or unwilling to buffer the entire
     1505         request before processing.
    15091506      </p>
    15101507      <p id="rfc.section.3.3.3.p.6">A client that sends a request containing a message body <em class="bcp14">MUST</em> include a valid Content-Length header field if it does not know the server will handle HTTP/1.1 (or later) requests; such
     
    15421539      <p id="rfc.section.3.5.p.3">When a server listening only for HTTP request messages, or processing what appears from the start-line to be an HTTP request
    15431540         message, receives a sequence of octets that does not match the HTTP-message grammar aside from the robustness exceptions listed
    1544          above, the server <em class="bcp14">MUST</em> respond with an HTTP/1.1 400 (Bad Request) response.
     1541         above, the server <em class="bcp14">MUST</em> respond with an HTTP/1.1 <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> response.
    15451542      </p>
    15461543      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="transfer.codings" href="#transfer.codings">Transfer Codings</a></h1>
     
    18561853         without first verifying that the intercepted connection is targeting a valid IP address for that host.
    18571854      </p>
    1858       <p id="rfc.section.5.4.p.9">A server <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status code to any HTTP/1.1 request message that lacks a Host header field and to any request
    1859          message that contains more than one Host header field or a Host header field with an invalid field-value.
     1855      <p id="rfc.section.5.4.p.9">A server <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> status code to any HTTP/1.1 request message that lacks a Host header field and to any request message that contains more than
     1856         one Host header field or a Host header field with an invalid field-value.
    18601857      </p>
    18611858      <div id="rfc.iref.e.1"></div>
     
    21822179      </ul>
    21832180      <p id="rfc.section.6.4.3.p.3">Because of the presence of older implementations, the protocol allows ambiguous situations in which a client might send "Expect:
    2184          100-continue" without receiving either a 417 (Expectation Failed) or a 100 (Continue) status code. Therefore, when a client
    2185          sends this header field to an origin server (possibly via a proxy) from which it has never seen a 100 (Continue) status code,
    2186          the client <em class="bcp14">SHOULD NOT</em> wait for an indefinite period before sending the request body.
     2181         100-continue" without receiving either a <a href="p2-semantics.html#status.417" class="smpl">417 (Expectation Failed)</a> or a 100 (Continue) status code. Therefore, when a client sends this header field to an origin server (possibly via a proxy)
     2182         from which it has never seen a 100 (Continue) status code, the client <em class="bcp14">SHOULD NOT</em> wait for an indefinite period before sending the request body.
    21872183      </p>
    21882184      <p id="rfc.section.6.4.3.p.4">Requirements for HTTP/1.1 origin servers: </p>
     
    22162212            it <em class="bcp14">MUST</em> forward the request, including the Expect header field.
    22172213         </li>
    2218          <li>If the proxy knows that the version of the next-hop server is HTTP/1.0 or lower, it <em class="bcp14">MUST NOT</em> forward the request, and it <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed) status code.
     2214         <li>If the proxy knows that the version of the next-hop server is HTTP/1.0 or lower, it <em class="bcp14">MUST NOT</em> forward the request, and it <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.417" class="smpl">417 (Expectation Failed)</a> status code.
    22192215         </li>
    22202216         <li>Proxies <em class="bcp14">SHOULD</em> maintain a record of the HTTP version numbers received from recently-referenced next-hop servers.
     
    22622258      </p>
    22632259      <p id="rfc.section.6.5.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in 101 (Switching Protocols) responses to indicate which protocol(s) are being switched
    2264          to, and <em class="bcp14">MUST</em> include it in 426 (Upgrade Required) responses to indicate acceptable protocols to upgrade to. Servers <em class="bcp14">MAY</em> include it in any other response to indicate that they are willing to upgrade to one of the specified protocols.
     2260         to, and <em class="bcp14">MUST</em> include it in <a href="p2-semantics.html#status.426" class="smpl">426 (Upgrade Required)</a> responses to indicate acceptable protocols to upgrade to. Servers <em class="bcp14">MAY</em> include it in any other response to indicate that they are willing to upgrade to one of the specified protocols.
    22652261      </p>
    22662262      <p id="rfc.section.6.5.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1710 r1713  
    10601060   directly instead of properly percent-encoding the disallowed characters.
    10611061   Recipients of an invalid request-line &SHOULD; respond with either a
    1062    400 (Bad Request) error or a 301 (Moved Permanently) redirect with the
     1062   <x:ref>400 (Bad Request)</x:ref> error or a 301 (Moved Permanently) redirect with the
    10631063   request-target properly encoded.  Recipients &SHOULD-NOT; attempt to
    10641064   autocorrect and then process the request without a redirect, since the
     
    10691069   HTTP does not place a pre-defined limit on the length of a request-line.
    10701070   A server that receives a method longer than any that it implements
    1071    &SHOULD; respond with either a 405 (Not Allowed), if it is an origin
     1071   &SHOULD; respond with either a <x:ref>405 (Method Not Allowed)</x:ref>, if it is an origin
    10721072   server, or a <x:ref>501 (Not Implemented)</x:ref> status code.
    10731073   A server &MUST; be prepared to receive URIs of unbounded length and
    1074    respond with the 414 (URI Too Long) status code if the received
     1074   respond with the <x:ref>414 (URI Too Long)</x:ref> status code if the received
    10751075   request-target would be longer than the server wishes to handle
    10761076   (see &status-414;).
     
    16691669     "chunked" transfer-coding is not the final encoding, the message body
    16701670     length cannot be determined reliably; the server &MUST; respond with
    1671      the 400 (Bad Request) status code and then close the connection.
     1671     the <x:ref>400 (Bad Request)</x:ref> status code and then close the connection.
    16721672    </t>
    16731673    <t>
     
    16881688     prevent request or response smuggling.
    16891689     If this is a request message, the server &MUST; respond with
    1690      a 400 (Bad Request) status code and then close the connection.
     1690     a <x:ref>400 (Bad Request)</x:ref> status code and then close the connection.
    16911691     If this is a response message received by a proxy, the proxy
    16921692     &MUST; discard the received response, send a <x:ref>502 (Bad Gateway)</x:ref>
     
    17301730<t>
    17311731   A server &MAY; reject a request that contains a message body but
    1732    not a Content-Length by responding with 411 (Length Required).
     1732   not a Content-Length by responding with <x:ref>411 (Length Required)</x:ref>.
    17331733</t>
    17341734<t>
     
    17371737   use a valid Content-Length header field if the message body length
    17381738   is known in advance, rather than the "chunked" encoding, since some
    1739    existing services respond to "chunked" with a 411 (Length Required)
     1739   existing services respond to "chunked" with a <x:ref>411 (Length Required)</x:ref>
    17401740   status code even though they understand the chunked encoding.  This
    17411741   is typically because such services are implemented via a gateway that
     
    18211821   receives a sequence of octets that does not match the HTTP-message
    18221822   grammar aside from the robustness exceptions listed above, the
    1823    server &MUST; respond with an HTTP/1.1 400 (Bad Request) response. 
     1823   server &MUST; respond with an HTTP/1.1 <x:ref>400 (Bad Request)</x:ref> response. 
    18241824</t>
    18251825</section>
     
    24102410</t>
    24112411<t>
    2412    A server &MUST; respond with a 400 (Bad Request) status code to
    2413    any HTTP/1.1 request message that lacks a Host header field and
     2412   A server &MUST; respond with a <x:ref>400 (Bad Request)</x:ref> status code
     2413   to any HTTP/1.1 request message that lacks a Host header field and
    24142414   to any request message that contains more than one Host header field
    24152415   or a Host header field with an invalid field-value.
     
    31173117   Because of the presence of older implementations, the protocol allows
    31183118   ambiguous situations in which a client might send "Expect: 100-continue"
    3119    without receiving either a 417 (Expectation Failed)
     3119   without receiving either a <x:ref>417 (Expectation Failed)</x:ref>
    31203120   or a 100 (Continue) status code. Therefore, when a client sends this
    31213121   header field to an origin server (possibly via a proxy) from which it
     
    31853185    <t> If the proxy knows that the version of the next-hop server is
    31863186        HTTP/1.0 or lower, it &MUST-NOT; forward the request, and it &MUST;
    3187         respond with a 417 (Expectation Failed) status code.
     3187        respond with a <x:ref>417 (Expectation Failed)</x:ref> status code.
    31883188    </t>
    31893189    <t> Proxies &SHOULD; maintain a record of the HTTP version
     
    32773277   Servers &MUST; include the "Upgrade" header field in 101 (Switching
    32783278   Protocols) responses to indicate which protocol(s) are being switched to,
    3279    and &MUST; include it in 426 (Upgrade Required) responses to indicate
     3279   and &MUST; include it in <x:ref>426 (Upgrade Required)</x:ref> responses to indicate
    32803280   acceptable protocols to upgrade to. Servers &MAY; include it in any other
    32813281   response to indicate that they are willing to upgrade to one of the
     
    41094109  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-&ID-VERSION;"/>
    41104110  <x:source href="p2-semantics.xml" basename="p2-semantics">
     4111    <x:defines>400 (Bad Request)</x:defines>
     4112    <x:defines>405 (Method Not Allowed)</x:defines>
     4113    <x:defines>411 (Length Required)</x:defines>
     4114    <x:defines>414 (URI Too Long)</x:defines>
     4115    <x:defines>417 (Expectation Failed)</x:defines>
     4116    <x:defines>426 (Upgrade Required)</x:defines>
    41114117    <x:defines>501 (Not Implemented)</x:defines>
    41124118    <x:defines>502 (Bad Gateway)</x:defines>
  • draft-ietf-httpbis/latest/p2-semantics.html

    r1712 r1713  
    891891      <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.1"></span>  <a href="#methods" class="smpl">method</a>         = <a href="#core.rules" class="smpl">token</a>
    892892</pre><p id="rfc.section.2.p.3">The list of methods allowed by a resource can be specified in an Allow header field (<a href="#header.allow" id="rfc.xref.header.allow.1" title="Allow">Section&nbsp;9.5</a>). The status code of the response always notifies the client whether a method is currently allowed on a resource, since the
    893          set of allowed methods can change dynamically. An origin server <em class="bcp14">SHOULD</em> respond with the status code 405 (Method Not Allowed) if the method is known by the origin server but not allowed for the
    894          resource, and <a href="#status.501" class="smpl">501 (Not Implemented)</a> if the method is unrecognized or not implemented by the origin server. The methods GET and HEAD <em class="bcp14">MUST</em> be supported by all general-purpose servers. All other methods are <em class="bcp14">OPTIONAL</em>; however, if the above methods are implemented, they <em class="bcp14">MUST</em> be implemented with the same semantics as those specified in <a href="#method.definitions" title="Method Definitions">Section&nbsp;2.3</a>.
     893         set of allowed methods can change dynamically. An origin server <em class="bcp14">SHOULD</em> respond with the status code <a href="#status.405" class="smpl">405 (Method Not Allowed)</a> if the method is known by the origin server but not allowed for the resource, and <a href="#status.501" class="smpl">501 (Not Implemented)</a> if the method is unrecognized or not implemented by the origin server. The methods GET and HEAD <em class="bcp14">MUST</em> be supported by all general-purpose servers. All other methods are <em class="bcp14">OPTIONAL</em>; however, if the above methods are implemented, they <em class="bcp14">MUST</em> be implemented with the same semantics as those specified in <a href="#method.definitions" title="Method Definitions">Section&nbsp;2.3</a>.
    895894      </p>
    896895      <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="safe.and.idempotent" href="#safe.and.idempotent">Safe and Idempotent Methods</a></h2>
     
    10541053         related to the URI in order to set the values for representation metadata on GET responses. When a PUT representation is inconsistent
    10551054         with the target resource, the origin server <em class="bcp14">SHOULD</em> either make them consistent, by transforming the representation or changing the resource configuration, or respond with an
    1056          appropriate error message containing sufficient information to explain why the representation is unsuitable. The 409 (Conflict)
    1057          or 415 (Unsupported Media Type) status codes are suggested, with the latter being specific to constraints on Content-Type
    1058          values.
     1055         appropriate error message containing sufficient information to explain why the representation is unsuitable. The <a href="#status.409" class="smpl">409 (Conflict)</a> or <a href="#status.415" class="smpl">415 (Unsupported Media Type)</a> status codes are suggested, with the latter being specific to constraints on Content-Type values.
    10591056      </p>
    10601057      <p id="rfc.section.2.3.5.p.5">For example, if the target resource is configured to always have a Content-Type of "text/html" and the representation being
     
    19201917      </p>
    19211918      <p id="rfc.section.4.6.3.p.2">If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it <em class="bcp14">SHOULD</em> describe the reason for the refusal in the representation. If the server does not wish to make this information available
    1922          to the client, the status code 404 (Not Found) <em class="bcp14">MAY</em> be used instead.
     1919         to the client, the status code <a href="#status.404" class="smpl">404
     1920            (Not Found)</a>  <em class="bcp14">MAY</em> be used instead.
    19231921      </p>
    19241922      <div id="rfc.iref.39"></div>
     
    19261924      <h3 id="rfc.section.4.6.4"><a href="#rfc.section.4.6.4">4.6.4</a>&nbsp;<a id="status.404" href="#status.404">404 Not Found</a></h3>
    19271925      <p id="rfc.section.4.6.4.p.1">The server has not found anything matching the effective request URI. No indication is given of whether the condition is temporary
    1928          or permanent. The 410 (Gone) status code <em class="bcp14">SHOULD</em> be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable
     1926         or permanent. The <a href="#status.410" class="smpl">410 (Gone)</a> status code <em class="bcp14">SHOULD</em> be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable
    19291927         and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request
    19301928         has been refused, or when no other response is applicable.
     
    19761974      <p id="rfc.section.4.6.9.p.1">The target resource is no longer available at the server and no forwarding address is known. This condition is expected to
    19771975         be considered permanent. Clients with link editing capabilities <em class="bcp14">SHOULD</em> delete references to the effective request URI after user approval. If the server does not know, or has no facility to determine,
    1978          whether or not the condition is permanent, the status code 404 (Not Found) <em class="bcp14">SHOULD</em> be used instead.
     1976         whether or not the condition is permanent, the status code <a href="#status.404" class="smpl">404 (Not Found)</a> <em class="bcp14">SHOULD</em> be used instead.
    19791977      </p>
    19801978      <p id="rfc.section.4.6.9.p.2">The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource
     
    25362534      <p id="rfc.section.8.1.p.4">Server-driven negotiation allows the user agent to specify its preferences, but it cannot expect responses to always honor
    25372535         them. For example, the origin server might not implement server-driven negotiation, or it might decide that sending a response
    2538          that doesn't conform to them is better than sending a 406 (Not Acceptable) response.
     2536         that doesn't conform to them is better than sending a <a href="#status.406" class="smpl">406
     2537            (Not Acceptable)</a> response.
    25392538      </p>
    25402539      <p id="rfc.section.8.1.p.5">Many of the mechanisms for expressing preferences use quality values to declare relative preference. See <a href="p1-messaging.html#quality.values" title="Quality Values">Section 4.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.47"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for more information.
     
    25662565         and used within HTTP/1.1.
    25672566      </p>
    2568       <p id="rfc.section.8.2.p.4">This specification defines the 300 (Multiple Choices) and 406 (Not Acceptable) status codes for enabling agent-driven negotiation
    2569          when the server is unwilling or unable to provide a varying response using server-driven negotiation.
     2567      <p id="rfc.section.8.2.p.4">This specification defines the 300 (Multiple Choices) and <a href="#status.406" class="smpl">406 (Not Acceptable)</a> status codes for enabling agent-driven negotiation when the server is unwilling or unable to provide a varying response using
     2568         server-driven negotiation.
    25702569      </p>
    25712570      <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1>
     
    26092608      <p id="rfc.section.9.1.p.9">A request without any Accept header field implies that the user agent will accept any media type in response. If an Accept
    26102609         header field is present in a request and none of the available representations for the response have a media type that is
    2611          listed as acceptable, the origin server <em class="bcp14">MAY</em> either honor the Accept header field by sending a 406 (Not Acceptable) response or disregard the Accept header field by treating
    2612          the response as if it is not subject to content negotiation.
     2610         listed as acceptable, the origin server <em class="bcp14">MAY</em> either honor the Accept header field by sending a <a href="#status.406" class="smpl">406 (Not Acceptable)</a> response or disregard the Accept header field by treating the response as if it is not subject to content negotiation.
    26132611      </p>
    26142612      <p id="rfc.section.9.1.p.10">A more elaborate example is</p>
     
    26932691      <p id="rfc.section.9.2.p.6">A request without any Accept-Charset header field implies that the user agent will accept any character encoding in response.
    26942692         If an Accept-Charset header field is present in a request and none of the available representations for the response have
    2695          a character encoding that is listed as acceptable, the origin server <em class="bcp14">MAY</em> either honor the Accept-Charset header field by sending a 406 (Not Acceptable) response or disregard the Accept-Charset header
    2696          field by treating the response as if it is not subject to content negotiation.
     2693         a character encoding that is listed as acceptable, the origin server <em class="bcp14">MAY</em> either honor the Accept-Charset header field by sending a <a href="#status.406" class="smpl">406 (Not Acceptable)</a> response or disregard the Accept-Charset header field by treating the response as if it is not subject to content negotiation.
    26972694      </p>
    26982695      <div id="rfc.iref.a.3"></div>
     
    29382935  <a href="#header.expect" class="smpl">expect-value</a> = <a href="#core.rules" class="smpl">token</a> / <a href="#core.rules" class="smpl">quoted-string</a>
    29392936</pre><p id="rfc.section.9.11.p.3">If all received Expect header field(s) are syntactically valid but contain an expectation that the recipient does not understand
    2940          or cannot comply with, the recipient <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed) status code. A recipient of a syntactically invalid Expectation header field <em class="bcp14">MUST</em> respond with a 4xx status code other than 417.
     2937         or cannot comply with, the recipient <em class="bcp14">MUST</em> respond with a <a href="#status.417" class="smpl">417 (Expectation Failed)</a> status code. A recipient of a syntactically invalid Expectation header field <em class="bcp14">MUST</em> respond with a 4xx status code other than 417.
    29412938      </p>
    29422939      <p id="rfc.section.9.11.p.4">The only expectation defined by this specification is:</p>
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r1712 r1713  
    391391   always notifies the client whether a method is currently allowed on a
    392392   resource, since the set of allowed methods can change dynamically. An
    393    origin server &SHOULD; respond with the status code 405 (Method Not Allowed)
     393   origin server &SHOULD; respond with the status code <x:ref>405 (Method Not Allowed)</x:ref>
    394394   if the method is known by the origin server but not allowed for the
    395395   resource, and <x:ref>501 (Not Implemented)</x:ref> if the method is
     
    731731   representation or changing the resource configuration, or respond
    732732   with an appropriate error message containing sufficient information
    733    to explain why the representation is unsuitable.  The 409 (Conflict)
    734    or 415 (Unsupported Media Type) status codes are suggested, with the
     733   to explain why the representation is unsuitable.  The <x:ref>409 (Conflict)</x:ref>
     734   or <x:ref>415 (Unsupported Media Type)</x:ref> status codes are suggested, with the
    735735   latter being specific to constraints on Content-Type values.
    736736</t>
     
    17641764  <iref primary="true" item="400 Bad Request (status code)" x:for-anchor=""/>
    17651765  <iref primary="true" item="Status Codes" subitem="400 Bad Request" x:for-anchor=""/>
     1766  <x:anchor-alias value="400 (Bad Request)"/>
    17661767<t>
    17671768   The server cannot or will not process the request, due to a client error (e.g.,
     
    17811782  <iref primary="true" item="403 Forbidden (status code)" x:for-anchor=""/>
    17821783  <iref primary="true" item="Status Codes" subitem="403 Forbidden" x:for-anchor=""/>
     1784  <x:anchor-alias value="403 (Forbidden)"/>
    17831785<t>
    17841786   The server understood the request, but refuses to authorize it. Providing
     
    17911793   public why the request has not been fulfilled, it &SHOULD; describe the
    17921794   reason for the refusal in the representation.  If the server does not wish to
    1793    make this information available to the client, the status code 404
    1794    (Not Found) &MAY; be used instead.
     1795   make this information available to the client, the status code <x:ref>404
     1796   (Not Found)</x:ref> &MAY; be used instead.
    17951797</t>
    17961798</section>
     
    17991801  <iref primary="true" item="404 Not Found (status code)" x:for-anchor=""/>
    18001802  <iref primary="true" item="Status Codes" subitem="404 Not Found" x:for-anchor=""/>
     1803  <x:anchor-alias value="404 (Not Found)"/>
    18011804<t>
    18021805   The server has not found anything matching the effective request URI. No
    18031806   indication is given of whether the condition is temporary or
    1804    permanent. The 410 (Gone) status code &SHOULD; be used if the server
     1807   permanent. The <x:ref>410 (Gone)</x:ref> status code &SHOULD; be used if the server
    18051808   knows, through some internally configurable mechanism, that an old
    18061809   resource is permanently unavailable and has no forwarding address.
     
    18141817  <iref primary="true" item="405 Method Not Allowed (status code)" x:for-anchor=""/>
    18151818  <iref primary="true" item="Status Codes" subitem="405 Method Not Allowed" x:for-anchor=""/>
     1819  <x:anchor-alias value="405 (Method Not Allowed)"/>
    18161820<t>
    18171821   The method specified in the request-line is not allowed for the target
     
    18241828  <iref primary="true" item="406 Not Acceptable (status code)" x:for-anchor=""/>
    18251829  <iref primary="true" item="Status Codes" subitem="406 Not Acceptable" x:for-anchor=""/>
     1830  <x:anchor-alias value="406 (Not Acceptable)"/>
    18261831<t>
    18271832   The resource identified by the request is only capable of generating
     
    18671872  <iref primary="true" item="409 Conflict (status code)" x:for-anchor=""/>
    18681873  <iref primary="true" item="Status Codes" subitem="409 Conflict" x:for-anchor=""/>
     1874  <x:anchor-alias value="409 (Conflict)"/>
    18691875<t>
    18701876   The request could not be completed due to a conflict with the current
     
    18911897  <iref primary="true" item="410 Gone (status code)" x:for-anchor=""/>
    18921898  <iref primary="true" item="Status Codes" subitem="410 Gone" x:for-anchor=""/>
     1899  <x:anchor-alias value="410 (Gone)"/>
    18931900<t>
    18941901   The target resource is no longer available at the server and no
     
    18971904   delete references to the effective request URI after user approval. If the
    18981905   server does not know, or has no facility to determine, whether or not
    1899    the condition is permanent, the status code 404 (Not Found) &SHOULD; be
    1900    used instead.
     1906   the condition is permanent, the status code <x:ref>404 (Not Found)</x:ref>
     1907   &SHOULD; be used instead.
    19011908</t>
    19021909<t>
     
    19201927  <iref primary="true" item="411 Length Required (status code)" x:for-anchor=""/>
    19211928  <iref primary="true" item="Status Codes" subitem="411 Length Required" x:for-anchor=""/>
     1929  <x:anchor-alias value="411 (Length Required)"/>
    19221930<t>
    19231931   The server refuses to accept the request without a defined Content-Length.
     
    19471955  <iref primary="true" item="414 URI Too Long (status code)" x:for-anchor=""/>
    19481956  <iref primary="true" item="Status Codes" subitem="414 URI Too Long" x:for-anchor=""/>
     1957  <x:anchor-alias value="414 (URI Too Long)"/>
    19491958<t>
    19501959   The server is refusing to service the request because the effective request URI
     
    19631972  <iref primary="true" item="415 Unsupported Media Type (status code)" x:for-anchor=""/>
    19641973  <iref primary="true" item="Status Codes" subitem="415 Unsupported Media Type" x:for-anchor=""/>
     1974  <x:anchor-alias value="415 (Unsupported Media Type)"/>
    19651975<t>
    19661976   The server is refusing to service the request because the request
     
    19731983  <iref primary="true" item="417 Expectation Failed (status code)" x:for-anchor=""/>
    19741984  <iref primary="true" item="Status Codes" subitem="417 Expectation Failed" x:for-anchor=""/>
     1985  <x:anchor-alias value="417 (Expectation Failed)"/>
    19751986<t>
    19761987   The expectation given in an Expect header field (see <xref target="header.expect"/>)
     
    19841995  <iref primary="true" item="426 Upgrade Required (status code)" x:for-anchor=""/>
    19851996  <iref primary="true" item="Status Codes" subitem="426 Upgrade Required" x:for-anchor=""/>
     1997  <x:anchor-alias value="426 (Upgrade Required)"/>
    19861998<t>
    19871999   The request can not be completed without a prior protocol upgrade. This
     
    28532865   but it cannot expect responses to always honor them. For example, the origin
    28542866   server might not implement server-driven negotiation, or it might decide that
    2855    sending a response that doesn't conform to them is better than sending a 406
    2856    (Not Acceptable) response.
     2867   sending a response that doesn't conform to them is better than sending a <x:ref>406
     2868   (Not Acceptable)</x:ref> response.
    28572869</t>
    28582870<t>
     
    29132925</t>
    29142926<t>
    2915    This specification defines the 300 (Multiple Choices) and 406 (Not Acceptable)
     2927   This specification defines the 300 (Multiple Choices) and <x:ref>406 (Not Acceptable)</x:ref>
    29162928   status codes for enabling agent-driven negotiation when the server is
    29172929   unwilling or unable to provide a varying response using server-driven
     
    29933005   If an Accept header field is present in a request and none of the
    29943006   available representations for the response have a media type that is
    2995    listed as acceptable, the origin server &MAY; either
    2996    honor the Accept header field by sending a 406 (Not Acceptable) response
     3007   listed as acceptable, the origin server &MAY; either honor the Accept
     3008   header field by sending a <x:ref>406 (Not Acceptable)</x:ref> response
    29973009   or disregard the Accept header field by treating the response as if
    29983010   it is not subject to content negotiation.
     
    30943106   available representations for the response have a character encoding that
    30953107   is listed as acceptable, the origin server &MAY; either honor the
    3096    Accept-Charset header field by sending a 406 (Not Acceptable) response or
     3108   Accept-Charset header field by sending a <x:ref>406 (Not Acceptable)</x:ref> response or
    30973109   disregard the Accept-Charset header field by treating the response as if
    30983110   it is not subject to content negotiation.
     
    35783590   If all received Expect header field(s) are syntactically valid but contain
    35793591   an expectation that the recipient does not understand or cannot comply with,
    3580    the recipient &MUST; respond with a 417 (Expectation Failed) status code. A
     3592   the recipient &MUST; respond with a <x:ref>417 (Expectation Failed)</x:ref> status code. A
    35813593   recipient of a syntactically invalid Expectation header field &MUST; respond
    35823594   with a 4xx status code other than 417.
  • draft-ietf-httpbis/latest/p6-cache.html

    r1710 r1713  
    833833      <p id="rfc.section.2.p.2">Each <dfn>cache entry</dfn> consists of a cache key and one or more HTTP responses corresponding to prior requests that used the same key. The most common
    834834         form of cache entry is a successful result of a retrieval request: i.e., a 200 (OK) response containing a representation of
    835          the resource identified by the request target. However, it is also possible to cache negative results (e.g., 404 not found),
    836          incomplete results (e.g., 206 partial content), and responses to safe methods other than GET if the method's definition allows
    837          such caching and defines something suitable for use as a cache key.
     835         the resource identified by the request target. However, it is also possible to cache negative results (e.g., <a href="p2-semantics.html#status.404" class="smpl">404 (Not Found)</a>, incomplete results (e.g., <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a>), and responses to safe methods other than GET if the method's definition allows such caching and defines something suitable
     836         for use as a cache key.
    838837      </p>
    839838      <p id="rfc.section.2.p.3">The default <dfn>cache key</dfn> consists of the request method and target URI. However, since HTTP caches in common use today are typically limited to caching
  • draft-ietf-httpbis/latest/p6-cache.xml

    r1710 r1713  
    434434   request: i.e., a 200 (OK) response containing a representation of the
    435435   resource identified by the request target.  However, it is also possible
    436    to cache negative results (e.g., 404 not found), incomplete results
    437    (e.g., 206 partial content), and responses to safe methods other than
     436   to cache negative results (e.g., <x:ref>404 (Not Found)</x:ref>, incomplete results
     437   (e.g., <x:ref>206 (Partial Content)</x:ref>), and responses to safe methods other than
    438438   GET if the method's definition allows such caching and defines something
    439439   suitable for use as a cache key.
     
    22882288    <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-&ID-VERSION;" />
    22892289    <x:source basename="p2-semantics" href="p2-semantics.xml">
     2290      <x:defines>404 (Not Found)</x:defines>
    22902291      <x:defines>504 (Gateway Timeout)</x:defines>
    22912292    </x:source>
  • draft-ietf-httpbis/latest/p7-auth.html

    r1708 r1713  
    449449  }
    450450  @bottom-center {
    451        content: "Expires January 4, 2013";
     451       content: "Expires January 5, 2013";
    452452  }
    453453  @bottom-right {
     
    489489      <meta name="dct.creator" content="Reschke, J. F.">
    490490      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest">
    491       <meta name="dct.issued" scheme="ISO8601" content="2012-07-03">
     491      <meta name="dct.issued" scheme="ISO8601" content="2012-07-04">
    492492      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    493493      <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 7 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 7 defines the HTTP Authentication framework.">
     
    520520            </tr>
    521521            <tr>
    522                <td class="left">Expires: January 4, 2013</td>
     522               <td class="left">Expires: January 5, 2013</td>
    523523               <td class="right">greenbytes</td>
    524524            </tr>
    525525            <tr>
    526526               <td class="left"></td>
    527                <td class="right">July 3, 2012</td>
     527               <td class="right">July 4, 2012</td>
    528528            </tr>
    529529         </tbody>
     
    553553         in progress”.
    554554      </p>
    555       <p>This Internet-Draft will expire on January 4, 2013.</p>
     555      <p>This Internet-Draft will expire on January 5, 2013.</p>
    556556      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    557557      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    715715         a proxy <em class="bcp14">SHOULD</em> return a <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> response. Such responses <em class="bcp14">MUST</em> include a Proxy-Authenticate header field containing a (possibly new) challenge applicable to the proxy.
    716716      </p>
    717       <p id="rfc.section.2.1.p.16">A server receiving credentials that are valid, but not adequate to gain access, ought to respond with the 403 (Forbidden)
    718          status code (<a href="p2-semantics.html#status.403" title="403 Forbidden">Section 4.6.3</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
     717      <p id="rfc.section.2.1.p.16">A server receiving credentials that are valid, but not adequate to gain access, ought to respond with the <a href="p2-semantics.html#status.403" class="smpl">403 (Forbidden)</a> status code (<a href="p2-semantics.html#status.403" title="403 Forbidden">Section 4.6.3</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
    719718      </p>
    720719      <p id="rfc.section.2.1.p.17">The HTTP protocol does not restrict applications to this simple challenge-response mechanism for access authentication. Additional
  • draft-ietf-httpbis/latest/p7-auth.xml

    r1708 r1713  
    329329<t>
    330330   A server receiving credentials that are valid, but not adequate to gain
    331    access, ought to respond with the 403 (Forbidden) status code (&status.403;).
     331   access, ought to respond with the <x:ref>403 (Forbidden)</x:ref> status code (&status.403;).
    332332</t>
    333333<t>
     
    892892  </front>
    893893  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-&ID-VERSION;" />
    894   <x:source basename="p2-semantics" href="p2-semantics.xml" />
     894  <x:source basename="p2-semantics" href="p2-semantics.xml">
     895    <x:defines>403 (Forbidden)</x:defines>
     896  </x:source>
    895897</reference>
    896898
Note: See TracChangeset for help on using the changeset viewer.