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)

File:
1 edited

Legend:

Unmodified
Added
Removed
  • 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>
Note: See TracChangeset for help on using the changeset viewer.