Ignore:
Timestamp:
Jul 24, 2010, 7:06:46 AM (9 years ago)
Author:
julian.reschke@…
Message:

regen HTML

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p2-semantics.html

    r923 r928  
    875875      </p>
    876876      <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="status.code.registry" href="#status.code.registry">Status Code Registry</a></h2>
    877       <p id="rfc.section.4.1.p.1">The HTTP Status Code Registry defines the name space for the Status-Code token in the Status line of an HTTP response.</p>
     877      <p id="rfc.section.4.1.p.1">The HTTP Status Code Registry defines the name space for the Status-Code token in the Status-Line of an HTTP response.</p>
    878878      <p id="rfc.section.4.1.p.2">Values to be added to this name space are subject to IETF review (<a href="#RFC5226" id="rfc.xref.RFC5226.2"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>, <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a>).
    879879      </p>
     
    917917            at the Effective Request URI.
    918918         </li>
    919          <li>If the response status is 204, 206, or 304 and the request method was GET or HEAD, the response is a partial representation
     919         <li>If the response status code is 204, 206, or 304 and the request method was GET or HEAD, the response is a partial representation
    920920            of the resource at the Effective Request URI (see <a href="p6-cache.html#combining.headers" title="Combining Responses">Section 2.8</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
    921921         </li>
     
    10331033      </p>
    10341034      <p id="rfc.section.7.5.p.3">The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either
    1035          200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes a representation
    1036          that describes the result.
     1035         200 (OK) or 204 (No Content) is the appropriate response status code, depending on whether or not the response includes a
     1036         representation that describes the result.
    10371037      </p>
    10381038      <p id="rfc.section.7.5.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be 201 (Created) and contain a representation which describes the status of the request and refers to the new resource, and
     
    10571057      <p id="rfc.section.7.6.p.3">If the resource identified by the Effective Request URI could not be created or modified, an appropriate error response <em class="bcp14">SHOULD</em> be given that reflects the nature of the problem. The recipient of the representation <em class="bcp14">MUST NOT</em> ignore any Content-* headers (headers starting with the prefix "Content-") that it does not understand or implement and <em class="bcp14">MUST</em> return a 501 (Not Implemented) response in such cases.
    10581058      </p>
    1059       <p id="rfc.section.7.6.p.4">If the request passes through a cache that has one or more stored responses for the Effective Request URI, those stored responses <em class="bcp14">SHOULD</em> be marked as stale if the response to the PUT request is a success status. Responses to the PUT method are not cacheable.
     1059      <p id="rfc.section.7.6.p.4">If the request passes through a cache that has one or more stored responses for the Effective Request URI, those stored responses <em class="bcp14">SHOULD</em> be marked as stale if the response to the PUT request has a success status code. Responses to the PUT method are not cacheable.
    10601060      </p>
    10611061      <p id="rfc.section.7.6.p.5">The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Effective Request
     
    11971197      <p id="rfc.section.8.2.5.p.1">The server has successfully fulfilled the request, but there is no additional content to return in the response payload body.
    11981198         The resource metadata and representation metadata in the response message's header fields refer to the requested resource
    1199          and its current representation, respectively, after the requested action. For example, if a 204 status is received in response
    1200          to a PUT and the response contains an ETag header field, then the value of that field is the current entity-tag for the representation
    1201          that was successfully PUT to the requested resource.
     1199         and its current representation, respectively, after the requested action. For example, if a 204 status code is received in
     1200         response to a PUT and the response contains an ETag header field, then the value of that field is the current entity-tag for
     1201         the representation that was successfully PUT to the requested resource.
    12021202      </p>
    12031203      <p id="rfc.section.8.2.5.p.2">If the client is a user agent, it <em class="bcp14">SHOULD NOT</em> change its document view from that which caused the request to be sent. This response is primarily intended to allow input
     
    12881288         resource.
    12891289      </p>
    1290       <p id="rfc.section.8.3.4.p.2">The 303 status is generally applicable to any HTTP method. It is primarily used to allow the output of a POST action to redirect
    1291          the user agent to a selected resource, since doing so provides the information corresponding to the POST response in a form
    1292          that can be separately identified, bookmarked, and cached independent of the original request.
     1290      <p id="rfc.section.8.3.4.p.2">The 303 status code is generally applicable to any HTTP method. It is primarily used to allow the output of a POST action
     1291         to redirect the user agent to a selected resource, since doing so provides the information corresponding to the POST response
     1292         in a form that can be separately identified, bookmarked, and cached independent of the original request.
    12931293      </p>
    12941294      <p id="rfc.section.8.3.4.p.3">A 303 response to a GET request indicates that the requested resource does not have a representation of its own that can be
     
    13091309      <div id="rfc.iref.s.16"></div>
    13101310      <h3 id="rfc.section.8.3.6"><a href="#rfc.section.8.3.6">8.3.6</a>&nbsp;<a id="status.305" href="#status.305">305 Use Proxy</a></h3>
    1311       <p id="rfc.section.8.3.6.p.1">The 305 status was defined in a previous version of this specification (see <a href="#changes.from.rfc.2616" title="Changes from RFC 2616">Appendix&nbsp;A</a>), and is now deprecated.
     1311      <p id="rfc.section.8.3.6.p.1">The 305 status code was defined in a previous version of this specification (see <a href="#changes.from.rfc.2616" title="Changes from RFC 2616">Appendix&nbsp;A</a>), and is now deprecated.
    13121312      </p>
    13131313      <div id="rfc.iref.40"></div>
     
    13211321      </p>
    13221322      <p id="rfc.section.8.3.8.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the representation of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s) , since many pre-HTTP/1.1 user agents do not understand
    1323          the 307 status. Therefore, the note <em class="bcp14">SHOULD</em> contain the information necessary for a user to repeat the original request on the new URI.
     1323         the 307 status code. Therefore, the note <em class="bcp14">SHOULD</em> contain the information necessary for a user to repeat the original request on the new URI.
    13241324      </p>
    13251325      <p id="rfc.section.8.3.8.p.3">If the 307 status code is received in response to a request method that is known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section&nbsp;7.1.1</a>, then the request <em class="bcp14">MAY</em> be automatically redirected by the user agent without confirmation. Otherwise, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which
     
    15511551                           *<a href="#header.expect" class="smpl">expect-params</a> ]
    15521552  <a href="#header.expect" class="smpl">expect-params</a> = ";" <a href="#core.rules" class="smpl">token</a> [ "=" ( <a href="#core.rules" class="smpl">token</a> / <a href="#core.rules" class="smpl">quoted-string</a> ) ]
    1553 </pre><p id="rfc.section.9.2.p.3">A server that does not understand or is unable to comply with any of the expectation values in the Expect field of a request <em class="bcp14">MUST</em> respond with appropriate error status. The server <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed) status if any of the expectations cannot be met or, if there are other problems with
    1554          the request, some other 4xx status.
     1553</pre><p id="rfc.section.9.2.p.3">A server that does not understand or is unable to comply with any of the expectation values in the Expect field of a request <em class="bcp14">MUST</em> respond with appropriate error status code. The server <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed) status code if any of the expectations cannot be met or, if there are other problems
     1554         with the request, some other 4xx status code.
    15551555      </p>
    15561556      <p id="rfc.section.9.2.p.4">This header field is defined with extensible syntax to allow for future extensions. If a server receives a request containing
    1557          an Expect field that includes an expectation-extension that it does not support, it <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed) status.
     1557         an Expect field that includes an expectation-extension that it does not support, it <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed) status code.
    15581558      </p>
    15591559      <p id="rfc.section.9.2.p.5">Comparison of expectation values is case-insensitive for unquoted tokens (including the 100-continue token), and is case-sensitive
    15601560         for quoted-string expectation-extensions.
    15611561      </p>
    1562       <p id="rfc.section.9.2.p.6">The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy <em class="bcp14">MUST</em> return a 417 (Expectation Failed) status if it receives a request with an expectation that it cannot meet. However, the Expect
    1563          request-header itself is end-to-end; it <em class="bcp14">MUST</em> be forwarded if the request is forwarded.
     1562      <p id="rfc.section.9.2.p.6">The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy <em class="bcp14">MUST</em> return a 417 (Expectation Failed) status code if it receives a request with an expectation that it cannot meet. However, the
     1563         Expect request-header itself is end-to-end; it <em class="bcp14">MUST</em> be forwarded if the request is forwarded.
    15641564      </p>
    15651565      <p id="rfc.section.9.2.p.7">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header.</p>
    1566       <p id="rfc.section.9.2.p.8">See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (Continue) status.
     1566      <p id="rfc.section.9.2.p.8">See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (Continue) status code.
    15671567      </p>
    15681568      <div id="rfc.iref.f.1"></div>
Note: See TracChangeset for help on using the changeset viewer.