Ignore:
Timestamp:
24/07/10 14:06:46 (12 years ago)
Author:
julian.reschke@…
Message:

regen HTML

Location:
draft-ietf-httpbis/latest
Files:
4 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>

  • draft-ietf-httpbis/latest/p4-conditional.html

    r923 r928  
    873873      <p id="rfc.section.5.p.7">An HTTP/1.1 origin server, upon receiving a conditional request that includes both a Last-Modified date (e.g., in an If-Modified-Since
    874874         or If-Unmodified-Since header field) and one or more entity-tags (e.g., in an If-Match, If-None-Match, or If-Range header
    875          field) as cache validators, <em class="bcp14">MUST NOT</em> return a response status of 304 (Not Modified) unless doing so is consistent with all of the conditional header fields in
    876          the request.
     875         field) as cache validators, <em class="bcp14">MUST NOT</em> return a response status code of 304 (Not Modified) unless doing so is consistent with all of the conditional header fields
     876         in the request.
    877877      </p>
    878878      <p id="rfc.section.5.p.8">An HTTP/1.1 caching proxy, upon receiving a conditional request that includes both a Last-Modified date and one or more entity-tags
    … …  
    938938         such as PUT, from modifying a resource that has changed since the client last retrieved it.
    939939      </p>
    940       <p id="rfc.section.6.2.p.6">If the request would, without the If-Match header field, result in anything other than a 2xx or 412 status, then the If-Match
    941          header <em class="bcp14">MUST</em> be ignored.
     940      <p id="rfc.section.6.2.p.6">If the request would, without the If-Match header field, result in anything other than a 2xx or 412 status code, then the
     941         If-Match header <em class="bcp14">MUST</em> be ignored.
    942942      </p>
    943943      <p id="rfc.section.6.2.p.7">The meaning of "If-Match: *" is that the method <em class="bcp14">SHOULD</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <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>) exists, and <em class="bcp14">MUST NOT</em> be performed if the representation does not exist.
    … …  
    970970      </p>
    971971      <ol>
    972          <li>If the request would normally result in anything other than a 200 (OK) status, or if the passed If-Modified-Since date is
    973             invalid, the response is exactly the same as for a normal GET. A date which is later than the server's current time is invalid.
     972         <li>If the request would normally result in anything other than a 200 (OK) status code, or if the passed If-Modified-Since date
     973            is invalid, the response is exactly the same as for a normal GET. A date which is later than the server's current time is
     974            invalid.
    974975         </li>
    975976         <li>If the representation has been modified since the If-Modified-Since date, the response is exactly the same as for a normal
    … …  
    10201021         for that resource, then the server <em class="bcp14">MUST NOT</em> perform the requested method, unless required to do so because the resource's modification date fails to match that supplied
    10211022         in an If-Modified-Since header field in the request. Instead, if the request method was GET or HEAD, the server <em class="bcp14">SHOULD</em> respond with a 304 (Not Modified) response, including the cache-related header fields (particularly ETag) of one of the representations
    1022          that matched. For all other request methods, the server <em class="bcp14">MUST</em> respond with a status of 412 (Precondition Failed).
     1023         that matched. For all other request methods, the server <em class="bcp14">MUST</em> respond with a 412 (Precondition Failed) status code.
    10231024      </p>
    10241025      <p id="rfc.section.6.4.p.6">If none of the entity-tags match, then the server <em class="bcp14">MAY</em> perform the requested method as if the If-None-Match header field did not exist, but <em class="bcp14">MUST</em> also ignore any If-Modified-Since header field(s) in the request. That is, if no entity-tags match, then the server <em class="bcp14">MUST NOT</em> return a 304 (Not Modified) response.
    10251026      </p>
    1026       <p id="rfc.section.6.4.p.7">If the request would, without the If-None-Match header field, result in anything other than a 2xx or 304 status, then the
    1027          If-None-Match header <em class="bcp14">MUST</em> be ignored. (See <a href="#rules.for.when.to.use.entity.tags.and.last-modified.dates" title="Rules for When to Use Entity-tags and Last-Modified Dates">Section&nbsp;5</a> for a discussion of server behavior when both If-Modified-Since and If-None-Match appear in the same request.)
     1027      <p id="rfc.section.6.4.p.7">If the request would, without the If-None-Match header field, result in anything other than a 2xx or 304 status code, then
     1028         the If-None-Match header <em class="bcp14">MUST</em> be ignored. (See <a href="#rules.for.when.to.use.entity.tags.and.last-modified.dates" title="Rules for When to Use Entity-tags and Last-Modified Dates">Section&nbsp;5</a> for a discussion of server behavior when both If-Modified-Since and If-None-Match appear in the same request.)
    10281029      </p>
    10291030      <p id="rfc.section.6.4.p.8">The meaning of "If-None-Match: *" is that the method <em class="bcp14">MUST NOT</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">SHOULD</em> be performed if the representation does not exist. This feature is intended to be useful in preventing races between PUT operations.
    … …  
    10521053</pre><p id="rfc.section.6.5.p.4">An example of the field is:</p>
    10531054      <div id="rfc.figure.u.16"></div><pre class="text">  If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
    1054 </pre><p id="rfc.section.6.5.p.6">If the request normally (i.e., without the If-Unmodified-Since header) would result in anything other than a 2xx or 412 status,
    1055          the If-Unmodified-Since header <em class="bcp14">SHOULD</em> be ignored.
     1055</pre><p id="rfc.section.6.5.p.6">If the request normally (i.e., without the If-Unmodified-Since header) would result in anything other than a 2xx or 412 status
     1056         code, the If-Unmodified-Since header <em class="bcp14">SHOULD</em> be ignored.
    10561057      </p>
    10571058      <p id="rfc.section.6.5.p.7">If the specified date is invalid, the header is ignored.</p>

  • draft-ietf-httpbis/latest/p5-range.html

    r923 r928  
    848848      <p id="rfc.section.5.4.1.p.11">If a syntactically valid byte-range-set includes at least one byte-range-spec whose first-byte-pos is less than the current
    849849         length of the representation, or at least one suffix-byte-range-spec with a non-zero suffix-length, then the byte-range-set
    850          is satisfiable. Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set is unsatisfiable, the server <em class="bcp14">SHOULD</em> return a response with a status of 416 (Requested range not satisfiable). Otherwise, the server <em class="bcp14">SHOULD</em> return a response with a status of 206 (Partial Content) containing the satisfiable ranges of the representation.
     850         is satisfiable. Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set is unsatisfiable, the server <em class="bcp14">SHOULD</em> return a response with a 416 (Requested range not satisfiable) status code. Otherwise, the server <em class="bcp14">SHOULD</em> return a response with a 206 (Partial Content) status code containing the satisfiable ranges of the representation.
    851851      </p>
    852852      <p id="rfc.section.5.4.1.p.12">Examples of byte-ranges-specifier values (assuming a representation of length 10000): </p>

  • draft-ietf-httpbis/latest/p6-cache.html

    r923 r928  
    11221122         <li>The only-if-cached request directive indicates that the client only wishes to return a stored response. If it receives this
    11231123            directive, a cache <em class="bcp14">SHOULD</em> either respond using a stored response that is consistent with the other constraints of the request, or respond with a 504
    1124             (Gateway Timeout) status. If a group of caches is being operated as a unified system with good internal connectivity, such
    1125             a request <em class="bcp14">MAY</em> be forwarded within that group of caches.
     1124            (Gateway Timeout) status code. If a group of caches is being operated as a unified system with good internal connectivity,
     1125            such a request <em class="bcp14">MAY</em> be forwarded within that group of caches.
    11261126         </li>
    11271127      </ul>
Note: See TracChangeset for help on using the changeset viewer.