Changeset 2400


Ignore:
Timestamp:
15/09/13 00:57:24 (7 years ago)
Author:
fielding@…
Message:

uniform terminology for status code and request method (except where it is obvious by context)

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

Legend:

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

    r2398 r2400  
    10171017      </p>
    10181018      <p id="rfc.section.2.6.p.10">A client <em class="bcp14">MAY</em> send a lower request version if it is known that the server incorrectly implements the HTTP specification, but only after
    1019          the client has attempted at least one normal request and determined from the response status or header fields (e.g., <a href="p2-semantics.html#header.server" class="smpl">Server</a>) that the server improperly handles higher request versions.
     1019         the client has attempted at least one normal request and determined from the response status code or header fields (e.g., <a href="p2-semantics.html#header.server" class="smpl">Server</a>) that the server improperly handles higher request versions.
    10201020      </p>
    10211021      <p id="rfc.section.2.6.p.11">A server <em class="bcp14">SHOULD</em> send a response version equal to the highest version to which the server is conformant and whose major version is less than
     
    11941194      </div>
    11951195      <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.31"></span>  <a href="#method" class="smpl">method</a>         = <a href="#rule.token.separators" class="smpl">token</a>
    1196 </pre><p id="rfc.section.3.1.1.p.5">The methods defined by this specification can be found in <a href="p2-semantics.html#methods" title="Request Methods">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, along with information regarding the HTTP method registry and considerations for defining new methods.
     1196</pre><p id="rfc.section.3.1.1.p.5">The request methods defined by this specification can be found in <a href="p2-semantics.html#methods" title="Request Methods">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, along with information regarding the HTTP method registry and considerations for defining new methods.
    11971197      </p>
    11981198      <div id="rfc.iref.r.6"></div>
     
    30153015      </p>
    30163016      <p id="rfc.section.A.2.p.15">The segment + query components of RFC 3986 have been used to define the request-target, instead of abs_path from RFC 1808.
    3017          The asterisk-form of the request-target is only allowed in the OPTIONS method. (<a href="#request-target" title="Request Target">Section&nbsp;5.3</a>)
     3017         The asterisk-form of the request-target is only allowed with the OPTIONS method. (<a href="#request-target" title="Request Target">Section&nbsp;5.3</a>)
    30183018      </p>
    30193019      <p id="rfc.section.A.2.p.16">The term "Effective Request URI" has been introduced. (<a href="#effective.request.uri" title="Effective Request URI">Section&nbsp;5.5</a>)
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r2398 r2400  
    758758   the server incorrectly implements the HTTP specification, but only
    759759   after the client has attempted at least one normal request and determined
    760    from the response status or header fields (e.g., <x:ref>Server</x:ref>) that
     760   from the response status code or header fields (e.g., <x:ref>Server</x:ref>) that
    761761   the server improperly handles higher request versions.
    762762</t>
     
    11241124</artwork></figure>
    11251125<t>
    1126    The methods defined by this specification can be found in
     1126   The request methods defined by this specification can be found in
    11271127   &methods;, along with information regarding the HTTP method registry
    11281128   and considerations for defining new methods.
     
    51215121  The segment + query components of RFC 3986 have been used to define the
    51225122  request-target, instead of abs_path from RFC 1808.
    5123   The asterisk-form of the request-target is only allowed in the OPTIONS
     5123  The asterisk-form of the request-target is only allowed with the OPTIONS
    51245124  method.
    51255125  (<xref target="request-target"/>)
  • draft-ietf-httpbis/latest/p2-semantics.html

    r2398 r2400  
    17401740      <div id="rfc.iref.m.1"></div>
    17411741      <h3 id="rfc.section.5.1.2"><a href="#rfc.section.5.1.2">5.1.2</a>&nbsp;<a id="header.max-forwards" href="#header.max-forwards">Max-Forwards</a></h3>
    1742       <p id="rfc.section.5.1.2.p.1">The "Max-Forwards" header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section&nbsp;4.3.8</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section&nbsp;4.3.7</a>) methods to limit the number of times that the request is forwarded by proxies. This can be useful when the client is attempting
    1743          to trace a request that appears to be failing or looping mid-chain.
     1742      <p id="rfc.section.5.1.2.p.1">The "Max-Forwards" header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section&nbsp;4.3.8</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section&nbsp;4.3.7</a>) request methods to limit the number of times that the request is forwarded by proxies. This can be useful when the client
     1743         is attempting to trace a request that appears to be failing or looping mid-chain.
    17441744      </p>
    17451745      <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.18"></span>  <a href="#header.max-forwards" class="smpl">Max-Forwards</a> = 1*<a href="#imported.abnf" class="smpl">DIGIT</a>
     
    24202420         servers <em class="bcp14">MUST NOT</em> send a 1xx response to an HTTP/1.0 client except under experimental conditions.
    24212421      </p>
    2422       <p id="rfc.section.6.2.p.2">A client <em class="bcp14">MUST</em> be able to parse one or more 1xx status responses received prior to a final response, even if the client does not expect one.
    2423          A user agent <em class="bcp14">MAY</em> ignore unexpected 1xx status responses.
     2422      <p id="rfc.section.6.2.p.2">A client <em class="bcp14">MUST</em> be able to parse one or more 1xx responses received prior to a final response, even if the client does not expect one. A user
     2423         agent <em class="bcp14">MAY</em> ignore unexpected 1xx responses.
    24242424      </p>
    24252425      <p id="rfc.section.6.2.p.3">A proxy <em class="bcp14">MUST</em> forward 1xx responses unless the proxy itself requested the generation of the 1xx response. For example, if a proxy adds an
     
    26882688      <div id="rfc.iref.71"></div>
    26892689      <h3 id="rfc.section.6.5.4"><a href="#rfc.section.6.5.4">6.5.4</a>&nbsp;<a id="status.404" href="#status.404">404 Not Found</a></h3>
    2690       <p id="rfc.section.6.5.4.p.1">The <dfn>404 (Not Found)</dfn> status code indicates that the origin server did not find a current representation for the <a href="#resources" class="smpl">target resource</a> or is not willing to disclose that one exists. A 404 status does not indicate whether this lack of representation is temporary
    2691          or permanent; the <a href="#status.410" class="smpl">410 (Gone)</a> status code is preferred over 404 if the origin server knows, presumably through some configurable means, that the condition
     2690      <p id="rfc.section.6.5.4.p.1">The <dfn>404 (Not Found)</dfn> status code indicates that the origin server did not find a current representation for the <a href="#resources" class="smpl">target resource</a> or is not willing to disclose that one exists. A 404 status code does not indicate whether this lack of representation is
     2691         temporary or permanent; the <a href="#status.410" class="smpl">410 (Gone)</a> status code is preferred over 404 if the origin server knows, presumably through some configurable means, that the condition
    26922692         is likely to be permanent.
    26932693      </p>
     
    26962696      <div id="rfc.iref.71"></div>
    26972697      <h3 id="rfc.section.6.5.5"><a href="#rfc.section.6.5.5">6.5.5</a>&nbsp;<a id="status.405" href="#status.405">405 Method Not Allowed</a></h3>
    2698       <p id="rfc.section.6.5.5.p.1">The <dfn>405 (Method Not Allowed)</dfn> status code indicates that the method specified in the request-line is known by the origin server but not supported by the <a href="#resources" class="smpl">target resource</a>. The origin server <em class="bcp14">MUST</em> generate an <a href="#header.allow" class="smpl">Allow</a> header field in a 405 response containing a list of the target resource's currently supported methods.
     2698      <p id="rfc.section.6.5.5.p.1">The <dfn>405 (Method Not Allowed)</dfn> status code indicates that the method received in the request-line is known by the origin server but not supported by the <a href="#resources" class="smpl">target resource</a>. The origin server <em class="bcp14">MUST</em> generate an <a href="#header.allow" class="smpl">Allow</a> header field in a 405 response containing a list of the target resource's currently supported methods.
    26992699      </p>
    27002700      <p id="rfc.section.6.5.5.p.2">A 405 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#Part6" id="rfc.xref.Part6.18"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
     
    27612761      <h3 id="rfc.section.6.5.13"><a href="#rfc.section.6.5.13">6.5.13</a>&nbsp;<a id="status.415" href="#status.415">415 Unsupported Media Type</a></h3>
    27622762      <p id="rfc.section.6.5.13.p.1">The <dfn>415 (Unsupported Media Type)</dfn> status code indicates that the origin server is refusing to service the request because the payload is in a format not supported
    2763          by the <a href="#resources" class="smpl">target resource</a> for this method. The format problem might be due to the request's indicated <a href="#header.content-type" class="smpl">Content-Type</a> or <a href="#header.content-encoding" class="smpl">Content-Encoding</a>, or as a result of inspecting the data directly.
     2763         by this method on the <a href="#resources" class="smpl">target resource</a>. The format problem might be due to the request's indicated <a href="#header.content-type" class="smpl">Content-Type</a> or <a href="#header.content-encoding" class="smpl">Content-Encoding</a>, or as a result of inspecting the data directly.
    27642764      </p>
    27652765      <div id="rfc.iref.71"></div>
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r2398 r2400  
    19681968   The "Max-Forwards" header field provides a mechanism with the
    19691969   TRACE (<xref target="TRACE"/>) and OPTIONS (<xref target="OPTIONS"/>)
    1970    methods to limit the number of times that the request is forwarded by
     1970   request methods to limit the number of times that the request is forwarded by
    19711971   proxies. This can be useful when the client is attempting to
    19721972   trace a request that appears to be failing or looping mid-chain.
     
    27292729</t>
    27302730<t>
    2731    A client &MUST; be able to parse one or more 1xx status responses received
     2731   A client &MUST; be able to parse one or more 1xx responses received
    27322732   prior to a final response, even if the client does not expect one.
    2733    A user agent &MAY; ignore unexpected 1xx status responses.
     2733   A user agent &MAY; ignore unexpected 1xx responses.
    27342734</t>
    27352735<t>
     
    33223322   server did not find a current representation for the
    33233323   <x:ref>target resource</x:ref> or is not willing to disclose that one
    3324    exists. A 404 status does not indicate whether this lack of representation
     3324   exists. A 404 status code does not indicate whether this lack of representation
    33253325   is temporary or permanent; the <x:ref>410 (Gone)</x:ref> status code is
    33263326   preferred over 404 if the origin server knows, presumably through some
     
    33383338<t>
    33393339   The <x:dfn>405 (Method Not Allowed)</x:dfn> status code indicates that the
    3340    method specified in the request-line is known by the origin server but
     3340   method received in the request-line is known by the origin server but
    33413341   not supported by the <x:ref>target resource</x:ref>.
    33423342   The origin server &MUST; generate an <x:ref>Allow</x:ref> header field in
     
    34943494   The <x:dfn>415 (Unsupported Media Type)</x:dfn> status code indicates that
    34953495   the origin server is refusing to service the request because the payload is
    3496    in a format not supported by the <x:ref>target resource</x:ref> for this
    3497    method. The format problem might be due to the request's indicated
     3496   in a format not supported by this method on the <x:ref>target resource</x:ref>.
     3497   The format problem might be due to the request's indicated
    34983498   <x:ref>Content-Type</x:ref> or <x:ref>Content-Encoding</x:ref>, or as a
    34993499   result of inspecting the data directly.
  • draft-ietf-httpbis/latest/p6-cache.html

    r2397 r2400  
    779779      </p>
    780780      <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="incomplete.responses" href="#incomplete.responses">Storing Incomplete Responses</a></h2>
    781       <p id="rfc.section.3.1.p.1">A response message is considered complete when all of the octets indicated by the message framing (<a href="#Part1" id="rfc.xref.Part1.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) are received prior to the connection being closed. If the request is GET, the response status is <a href="p2-semantics.html#status.200" class="smpl">200
    782             (OK)</a>, and the entire response header block has been received, a cache <em class="bcp14">MAY</em> store an incomplete response message body if the cache entry is recorded as incomplete. Likewise, a <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a> response <em class="bcp14">MAY</em> be stored as if it were an incomplete <a href="p2-semantics.html#status.200" class="smpl">200
     781      <p id="rfc.section.3.1.p.1">A response message is considered complete when all of the octets indicated by the message framing (<a href="#Part1" id="rfc.xref.Part1.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) are received prior to the connection being closed. If the request method is GET, the response status code is <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a>, and the entire response header block has been received, a cache <em class="bcp14">MAY</em> store an incomplete response message body if the cache entry is recorded as incomplete. Likewise, a <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a> response <em class="bcp14">MAY</em> be stored as if it were an incomplete <a href="p2-semantics.html#status.200" class="smpl">200
    783782            (OK)</a> cache entry. However, a cache <em class="bcp14">MUST NOT</em> store incomplete or partial content responses if it does not support the <a href="p5-range.html#header.range" class="smpl">Range</a> and <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> header fields or if it does not understand the range units used in those fields.
    784783      </p>
     
    11551154         to keep their contents up-to-date.
    11561155      </p>
    1157       <p id="rfc.section.4.4.p.2">A cache <em class="bcp14">MUST</em> invalidate the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) as well as the URI(s) in the <a href="p2-semantics.html#header.location" class="smpl">Location</a> and <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> response header fields (if present) when a non-error response to a request with an unsafe method is received.
     1156      <p id="rfc.section.4.4.p.2">A cache <em class="bcp14">MUST</em> invalidate the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) as well as the URI(s) in the <a href="p2-semantics.html#header.location" class="smpl">Location</a> and <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> response header fields (if present) when a non-error status code is received in response to an unsafe request method.
    11581157      </p>
    11591158      <p id="rfc.section.4.4.p.3">However, a cache <em class="bcp14">MUST NOT</em> invalidate a URI from a <a href="p2-semantics.html#header.location" class="smpl">Location</a> or <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> response header field if the host part of that URI differs from the host part in the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). This helps prevent denial of service attacks.
  • draft-ietf-httpbis/latest/p6-cache.xml

    r2397 r2400  
    322322   A response message is considered complete when all of the octets indicated
    323323   by the message framing (&messaging;) are received prior to the connection
    324    being closed. If the request is GET, the response status is <x:ref>200
    325    (OK)</x:ref>, and the entire response header block has been received, a
     324   being closed. If the request method is GET, the response status code is
     325   <x:ref>200 (OK)</x:ref>, and the entire response header block has been received, a
    326326   cache &MAY; store an incomplete response message body if the cache entry is
    327327   recorded as incomplete. Likewise, a <x:ref>206 (Partial Content)</x:ref>
     
    11131113   (&effective-request-uri;) as well as the URI(s) in the
    11141114   <x:ref>Location</x:ref> and <x:ref>Content-Location</x:ref> response header
    1115    fields (if present) when a non-error response to a request with an unsafe
    1116    method is received.
     1115   fields (if present) when a non-error status code is received in response to
     1116   an unsafe request method.
    11171117</t>
    11181118<t>
Note: See TracChangeset for help on using the changeset viewer.