Changeset 2066


Ignore:
Timestamp:
Dec 29, 2012, 2:14:11 AM (7 years ago)
Author:
fielding@…
Message:

(editorial) rephrasing to better target the subject of requirements

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

Legend:

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

    r2053 r2066  
    449449  }
    450450  @bottom-center {
    451        content: "Expires June 19, 2013";
     451       content: "Expires July 2, 2013";
    452452  }
    453453  @bottom-right {
     
    491491      <meta name="dct.creator" content="Reschke, J. F.">
    492492      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    493       <meta name="dct.issued" scheme="ISO8601" content="2012-12-16">
     493      <meta name="dct.issued" scheme="ISO8601" content="2012-12-29">
    494494      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    495495      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
     
    520520            <tr>
    521521               <td class="left">Intended status: Standards Track</td>
    522                <td class="right">December 16, 2012</td>
     522               <td class="right">December 29, 2012</td>
    523523            </tr>
    524524            <tr>
    525                <td class="left">Expires: June 19, 2013</td>
     525               <td class="left">Expires: July 2, 2013</td>
    526526               <td class="right"></td>
    527527            </tr>
     
    551551         in progress”.
    552552      </p>
    553       <p>This Internet-Draft will expire on June 19, 2013.</p>
     553      <p>This Internet-Draft will expire on July 2, 2013.</p>
    554554      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    555555      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    14781478         entire request before processing.
    14791479      </p>
    1480       <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 <a href="#header.content-length" class="smpl">Content-Length</a> header field if it does not know the server will handle HTTP/1.1 (or later) requests; such knowledge can be in the form of
     1480      <p id="rfc.section.3.3.3.p.6">A user agent that sends a request containing a message body <em class="bcp14">MUST</em> send a valid <a href="#header.content-length" class="smpl">Content-Length</a> header field if it does not know the server will handle HTTP/1.1 (or later) requests; such knowledge can be in the form of
    14811481         specific user configuration or by remembering the version of a prior received response.
    14821482      </p>
     
    15031503      <p id="rfc.section.3.5.p.1">Older HTTP/1.0 user agent implementations might send an extra CRLF after a POST request as a lame workaround for some early
    15041504         server applications that failed to read message body content that was not terminated by a line-ending. An HTTP/1.1 user agent <em class="bcp14">MUST NOT</em> preface or follow a request with an extra CRLF. If terminating the request message body with a line-ending is desired, then
    1505          the user agent <em class="bcp14">MUST</em> include the terminating CRLF octets as part of the message body length.
     1505         the user agent <em class="bcp14">MUST</em> count the terminating CRLF octets as part of the message body length.
    15061506      </p>
    15071507      <p id="rfc.section.3.5.p.2">In the interest of robustness, servers <em class="bcp14">SHOULD</em> ignore at least one empty line received where a request-line is expected. In other words, if a server is reading the protocol
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r2053 r2066  
    17511751</t>
    17521752<t>
    1753    A client that sends a request containing a message body &MUST; include a
     1753   A user agent that sends a request containing a message body &MUST; send a
    17541754   valid <x:ref>Content-Length</x:ref> header field if it does not know the
    17551755   server will handle HTTP/1.1 (or later) requests; such knowledge can be in
     
    18101810   preface or follow a request with an extra CRLF.  If terminating
    18111811   the request message body with a line-ending is desired, then the
    1812    user agent &MUST; include the terminating CRLF octets as part of the
     1812   user agent &MUST; count the terminating CRLF octets as part of the
    18131813   message body length.
    18141814</t>
  • draft-ietf-httpbis/latest/p4-conditional.html

    r2052 r2066  
    449449  }
    450450  @bottom-center {
    451        content: "Expires June 18, 2013";
     451       content: "Expires July 2, 2013";
    452452  }
    453453  @bottom-right {
     
    491491      <meta name="dct.creator" content="Reschke, J. F.">
    492492      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
    493       <meta name="dct.issued" scheme="ISO8601" content="2012-12-15">
     493      <meta name="dct.issued" scheme="ISO8601" content="2012-12-29">
    494494      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    495495      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.">
     
    517517            </tr>
    518518            <tr>
    519                <td class="left">Expires: June 18, 2013</td>
    520                <td class="right">December 15, 2012</td>
     519               <td class="left">Expires: July 2, 2013</td>
     520               <td class="right">December 29, 2012</td>
    521521            </tr>
    522522         </tbody>
     
    545545         in progress”.
    546546      </p>
    547       <p>This Internet-Draft will expire on June 18, 2013.</p>
     547      <p>This Internet-Draft will expire on July 2, 2013.</p>
    548548      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    549549      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    10561056      <div id="rfc.iref.21"></div>
    10571057      <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="status.304" href="#status.304">304 Not Modified</a></h2>
    1058       <p id="rfc.section.4.1.p.1">The 304 status code indicates that a conditional GET request has been received and would have resulted in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response if it were not for the fact that the condition has evaluated to false. In other words, there is no need for the server
     1058      <p id="rfc.section.4.1.p.1">The <dfn>304 (Not Modified)</dfn> status code indicates that a conditional GET request has been received and would have resulted in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response if it were not for the fact that the condition has evaluated to false. In other words, there is no need for the server
    10591059         to transfer a representation of the target resource because the request indicates that the client which made the request conditional
    10601060         already has a valid representation; the server is therefore redirecting that client to make use of that stored representation
    10611061         as if it were the payload of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response.
    10621062      </p>
    1063       <p id="rfc.section.4.1.p.2">The 304 response <em class="bcp14">MUST NOT</em> contain a message-body, and thus is always terminated by the first empty line after the header fields.
    1064       </p>
    1065       <p id="rfc.section.4.1.p.3">A 304 response <em class="bcp14">MUST</em> include a <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field (<a href="p2-semantics.html#header.date" title="Date">Section 7.1.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) unless the origin server does not have a clock that can provide a reasonable approximation of the current time. If a <a href="p2-semantics.html#status.200" class="smpl">200
    1066             (OK)</a> response to the same request would have included any of the header fields <a href="p6-cache.html#header.cache-control" class="smpl">Cache-Control</a>, <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a>, <a href="#header.etag" class="smpl">ETag</a>, <a href="p6-cache.html#header.expires" class="smpl">Expires</a>, or <a href="p2-semantics.html#header.vary" class="smpl">Vary</a>, then those same header fields <em class="bcp14">MUST</em> be sent in a 304 response.
     1063      <p id="rfc.section.4.1.p.2">A 304 response cannot contain a message-body; it is always terminated by the first empty line after the header fields.</p>
     1064      <p id="rfc.section.4.1.p.3">If a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request would have included any of the header fields <a href="p6-cache.html#header.cache-control" class="smpl">Cache-Control</a>, <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a>, <a href="#header.etag" class="smpl">ETag</a>, <a href="p6-cache.html#header.expires" class="smpl">Expires</a>, or <a href="p2-semantics.html#header.vary" class="smpl">Vary</a>, then the sender <em class="bcp14">MUST</em> generate those same header fields in a 304 response.
    10671065      </p>
    10681066      <p id="rfc.section.4.1.p.4">Since the goal of a 304 response is to minimize information transfer when the recipient already has one or more cached representations,
    1069          the response <em class="bcp14">SHOULD NOT</em> include representation metadata other than the above listed fields unless said metadata exists for the purpose of guiding
     1067         a sender <em class="bcp14">SHOULD NOT</em> generate representation metadata other than the above listed fields unless said metadata exists for the purpose of guiding
    10701068         cache updates (e.g., future HTTP extensions).
    10711069      </p>
     
    10781076      <div id="rfc.iref.21"></div>
    10791077      <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="status.412" href="#status.412">412 Precondition Failed</a></h2>
    1080       <p id="rfc.section.4.2.p.1">The 412 status code indicates that one or more preconditions given in the request header fields evaluated to false when tested
    1081          on the server. This response code allows the client to place preconditions on the current resource state (its current representations
     1078      <p id="rfc.section.4.2.p.1">The <dfn>412 (Precondition Failed)</dfn> status code indicates that one or more preconditions given in the request header fields evaluated to false when tested on
     1079         the server. This response code allows the client to place preconditions on the current resource state (its current representations
    10821080         and metadata) and thus prevent the request method from being applied if the target resource is in an unexpected state.
    10831081      </p>
     
    13171315  <a href="#imported.abnf" class="smpl">obs-text</a>      = &lt;obs-text, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>&gt;
    13181316</pre><p id="rfc.section.B.p.4">The rules below are defined in other parts:</p>
    1319       <div id="rfc.figure.u.17"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">HTTP-date</a>     = &lt;HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 7.1.1.1</a>&gt;
     1317      <div id="rfc.figure.u.17"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">HTTP-date</a>     = &lt;HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 7.1.1.1</a>&gt;
    13201318</pre><h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    13211319      <div id="rfc.figure.u.18"></div> <pre class="inline"><a href="#header.etag" class="smpl">ETag</a> = entity-tag
     
    14411439                     </ul>
    14421440                  </li>
    1443                   <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.3.3</a>, <a href="#rfc.xref.Part2.3">2.3.3</a>, <a href="#rfc.xref.Part2.4">4.1</a>, <a href="#Part2"><b>9.1</b></a>, <a href="#rfc.xref.Part2.5">B</a><ul>
     1441                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.3.3</a>, <a href="#rfc.xref.Part2.3">2.3.3</a>, <a href="#Part2"><b>9.1</b></a>, <a href="#rfc.xref.Part2.4">B</a><ul>
    14441442                        <li><em>Section 3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2.3.3</a></li>
    14451443                        <li><em>Section 5.3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.3.3</a></li>
    1446                         <li><em>Section 7.1.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">B</a></li>
    1447                         <li><em>Section 7.1.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">4.1</a></li>
     1444                        <li><em>Section 7.1.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">B</a></li>
    14481445                     </ul>
    14491446                  </li>
  • draft-ietf-httpbis/latest/p4-conditional.xml

    r2052 r2066  
    928928  <x:anchor-alias value="304 (Not Modified)"/>
    929929<t>
    930    The 304 status code indicates that a conditional GET request has been
     930   The <x:dfn>304 (Not Modified)</x:dfn> status code indicates that a conditional GET request has been
    931931   received and would have resulted in a <x:ref>200 (OK)</x:ref> response
    932932   if it were not for the fact that the condition has evaluated to false.
     
    939939</t>
    940940<t>
    941    The 304 response &MUST-NOT; contain a message-body, and thus is always
     941   A 304 response cannot contain a message-body; it is always
    942942   terminated by the first empty line after the header fields.
    943943</t>
    944944<t>
    945    A 304 response &MUST; include a <x:ref>Date</x:ref> header field
    946    (&header-date;) unless the origin server does not have a clock that can
    947    provide a reasonable approximation of the current time.  If a <x:ref>200
    948    (OK)</x:ref> response to the same request would have included any of the
    949    header fields <x:ref>Cache-Control</x:ref>, <x:ref>Content-Location</x:ref>,
    950    <x:ref>ETag</x:ref>, <x:ref>Expires</x:ref>, or <x:ref>Vary</x:ref>, then
    951    those same header fields &MUST; be sent in a 304 response.
     945   If a <x:ref>200 (OK)</x:ref> response to the same request would have
     946   included any of the header fields
     947   <x:ref>Cache-Control</x:ref>,
     948   <x:ref>Content-Location</x:ref>,
     949   <x:ref>ETag</x:ref>,
     950   <x:ref>Expires</x:ref>, or
     951   <x:ref>Vary</x:ref>, then
     952   the sender &MUST; generate those same header fields in a 304 response.
    952953</t>
    953954<t>
    954955   Since the goal of a 304 response is to minimize information transfer
    955956   when the recipient already has one or more cached representations,
    956    the response &SHOULD-NOT; include representation metadata other
     957   a sender &SHOULD-NOT; generate representation metadata other
    957958   than the above listed fields unless said metadata exists for the
    958959   purpose of guiding cache updates (e.g., future HTTP extensions).
     
    978979  <x:anchor-alias value="412 (Precondition Failed)"/>
    979980<t>
    980    The 412 status code indicates that one or more preconditions given in
     981   The <x:dfn>412 (Precondition Failed)</x:dfn> status code indicates that one or more preconditions given in
    981982   the request header fields evaluated to false when tested on the server.
    982983   This response code allows the client to place preconditions on the
  • draft-ietf-httpbis/latest/p5-range.html

    r2053 r2066  
    449449  }
    450450  @bottom-center {
    451        content: "Expires June 19, 2013";
     451       content: "Expires July 2, 2013";
    452452  }
    453453  @bottom-right {
     
    493493      <meta name="dct.creator" content="Reschke, J. F.">
    494494      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest">
    495       <meta name="dct.issued" scheme="ISO8601" content="2012-12-16">
     495      <meta name="dct.issued" scheme="ISO8601" content="2012-12-29">
    496496      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    497497      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests.">
     
    519519            </tr>
    520520            <tr>
    521                <td class="left">Expires: June 19, 2013</td>
     521               <td class="left">Expires: July 2, 2013</td>
    522522               <td class="right">J. Reschke, Editor</td>
    523523            </tr>
     
    528528            <tr>
    529529               <td class="left"></td>
    530                <td class="right">December 16, 2012</td>
     530               <td class="right">December 29, 2012</td>
    531531            </tr>
    532532         </tbody>
     
    553553         in progress”.
    554554      </p>
    555       <p>This Internet-Draft will expire on June 19, 2013.</p>
     555      <p>This Internet-Draft will expire on July 2, 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>
     
    682682      <div id="rfc.iref.3"></div>
    683683      <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="status.206" href="#status.206">206 Partial Content</a></h2>
    684       <p id="rfc.section.3.1.p.1">The server has fulfilled the partial GET request for the resource. The request <em class="bcp14">MUST</em> have included a <a href="#range.retrieval.requests" class="smpl">Range</a> header field (<a href="#header.range" id="rfc.xref.header.range.3" title="Range">Section&nbsp;5.4</a>) indicating the desired range, and <em class="bcp14">MAY</em> have included an <a href="#header.if-range" class="smpl">If-Range</a> header field (<a href="#header.if-range" id="rfc.xref.header.if-range.1" title="If-Range">Section&nbsp;5.3</a>) to make the request conditional.
    685       </p>
    686       <p id="rfc.section.3.1.p.2">The response <em class="bcp14">MUST</em> include the following header fields:
     684      <p id="rfc.section.3.1.p.1">The <dfn>206 (Partial Content)</dfn> status code indicates that the server has fulfilled the partial GET request for the resource. The request <em class="bcp14">MUST</em> have included a <a href="#range.retrieval.requests" class="smpl">Range</a> header field (<a href="#header.range" id="rfc.xref.header.range.3" title="Range">Section&nbsp;5.4</a>) indicating the desired range, and <em class="bcp14">MAY</em> have included an <a href="#header.if-range" class="smpl">If-Range</a> header field (<a href="#header.if-range" id="rfc.xref.header.if-range.1" title="If-Range">Section&nbsp;5.3</a>) to make the request conditional.
     685      </p>
     686      <p id="rfc.section.3.1.p.2">When a 206 response is generated, the sender <em class="bcp14">MUST</em> generate the following header fields:
    687687      </p>
    688688      <ul>
     
    693693         </li>
    694694      </ul>
    695       <p id="rfc.section.3.1.p.3">If a 206 is sent in response to a request with an <a href="#header.if-range" class="smpl">If-Range</a> header field, it <em class="bcp14">SHOULD NOT</em> include other representation header fields. Otherwise, the response <em class="bcp14">MUST</em> include all of the representation header fields that would have been sent with a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request.
     695      <p id="rfc.section.3.1.p.3">If a 206 is generated in response to a request with an <a href="#header.if-range" class="smpl">If-Range</a> header field, the sender <em class="bcp14">SHOULD NOT</em> generate other representation header fields beyond those described above. Otherwise, the sender <em class="bcp14">MUST</em> generate all of the same representation header fields that would have been sent in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request.
    696696      </p>
    697697      <p id="rfc.section.3.1.p.4">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) to determine freshness for 206 responses.
     
    699699      <div id="rfc.iref.3"></div>
    700700      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="status.416" href="#status.416">416 Requested Range Not Satisfiable</a></h2>
    701       <p id="rfc.section.3.2.p.1">A server <em class="bcp14">SHOULD</em> send a response with this status code if a request included a <a href="#range.retrieval.requests" class="smpl">Range</a> header field (<a href="#header.range" id="rfc.xref.header.range.4" title="Range">Section&nbsp;5.4</a>), and none of the ranges-specifier values in this field overlap the current extent of the selected resource, and the request
    702          did not include an <a href="#header.if-range" class="smpl">If-Range</a> header field (<a href="#header.if-range" id="rfc.xref.header.if-range.2" title="If-Range">Section&nbsp;5.3</a>). (For byte-ranges, this means that the first-byte-pos of all of the byte-range-spec values were greater than the current
    703          length of the selected resource.)
    704       </p>
    705       <p id="rfc.section.3.2.p.2">When this status code is sent in response to a byte-range request, the response <em class="bcp14">SHOULD</em> include a <a href="#header.content-range" class="smpl">Content-Range</a> header field specifying the current length of the representation (see <a href="#header.content-range" id="rfc.xref.header.content-range.3" title="Content-Range">Section&nbsp;5.2</a>). This response <em class="bcp14">MUST NOT</em> use the multipart/byteranges media type.
     701      <p id="rfc.section.3.2.p.1">The <dfn>416 (Requested Range Not Satisfiable)</dfn> status code indicates that none of the ranges-specifier values in the request's <a href="#range.retrieval.requests" class="smpl">Range</a> header field (<a href="#header.range" id="rfc.xref.header.range.4" title="Range">Section&nbsp;5.4</a>) overlap the current extent of the selected resource and the request did not include an <a href="#header.if-range" class="smpl">If-Range</a> header field (<a href="#header.if-range" id="rfc.xref.header.if-range.2" title="If-Range">Section&nbsp;5.3</a>). (For byte-ranges, this means that the first-byte-pos of all of the byte-range-spec values were greater than the current
     702         length of the selected representation.)
     703      </p>
     704      <p id="rfc.section.3.2.p.2">When this status code is sent in response to a byte-range request, the sender <em class="bcp14">SHOULD</em> generate a <a href="#header.content-range" class="smpl">Content-Range</a> header field specifying the current length of the selected representation (see <a href="#header.content-range" id="rfc.xref.header.content-range.3" title="Content-Range">Section&nbsp;5.2</a>).
    706705      </p>
    707706      <div id="rfc.figure.u.2"></div>
     
    744743         defined to be either an entity-tag that is not marked as weak (<a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>) or, if no entity-tag is provided, a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> value that is strong in the sense defined by <a href="p4-conditional.html#lastmod.comparison" title="Comparison">Section 2.2.2</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>.
    745744      </p>
    746       <p id="rfc.section.4.2.p.2">When a client receives an incomplete <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> or <a href="#status.206" class="smpl">206 (Partial Content)</a> response and already has one or more stored responses for the same method and effective request URI, all of the stored responses
    747          with the same strong validator <em class="bcp14">MAY</em> be combined with the partial content in this new response. If none of the stored responses contain the same strong validator,
    748          then this new response corresponds to a new representation and <em class="bcp14">MUST NOT</em> be combined with the existing stored responses.
     745      <p id="rfc.section.4.2.p.2">When a client receives an incomplete <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response or a <a href="#status.206" class="smpl">206 (Partial Content)</a> response, and already has one or more partial responses for the same method and effective request URI that have the same strong
     746         validator as present in the new response, the recipient <em class="bcp14">MAY</em> combine some or all of those responses into a set of continuous ranges. A client <em class="bcp14">MUST NOT</em> combine responses that differ in the strong validator or that do not have a strong validator.
    749747      </p>
    750748      <p id="rfc.section.4.2.p.3">If the new response is an incomplete <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response, then the header fields of that new response are used for any combined response and replace those of the matching
     
    756754      </p>
    757755      <p id="rfc.section.4.2.p.5">The combined response message body consists of the union of partial content ranges in the new response and each of the selected
    758          responses. If the union consists of the entire range of the representation, then the combined response <em class="bcp14">MUST</em> be recorded as a complete <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response with a <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> header field that reflects the complete length. Otherwise, the combined response(s) <em class="bcp14">MUST</em> include a <a href="#header.content-range" class="smpl">Content-Range</a> header field describing the included range(s) and be recorded as incomplete. If the union consists of a discontinuous range
    759          of the representation, then the client <em class="bcp14">MAY</em> store it as either a multipart range response or as multiple <a href="#status.206" class="smpl">206</a> responses with one continuous range each.
     756         responses. If the union consists of the entire range of the representation, then the client <em class="bcp14">MUST</em> record the combined response as if it were a complete <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response, including a <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> header field that reflects the complete length. Otherwise, the client <em class="bcp14">MUST</em> record the set of continuous ranges as one of the following: an incomplete <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response if the combined response is a prefix of the representation, a single <a href="#status.206" class="smpl">206 (Partial Content)</a> response containing a multipart/byteranges body, or multiple <a href="#status.206" class="smpl">206 (Partial Content)</a> responses, each with one continuous range that is indicated by a <a href="#header.content-range" class="smpl">Content-Range</a> header field.
    760757      </p>
    761758      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1>
  • draft-ietf-httpbis/latest/p5-range.xml

    r2053 r2066  
    240240  <x:anchor-alias value="206 (Partial Content)"/>
    241241<t>
    242    The server has fulfilled the partial GET request for the resource.
     242   The <x:dfn>206 (Partial Content)</x:dfn> status code indicates that the
     243   server has fulfilled the partial GET request for the resource.
    243244   The request &MUST; have included a <x:ref>Range</x:ref> header field
    244245   (<xref target="header.range"/>) indicating the desired range, and &MAY; have
     
    247248</t>
    248249<t>
    249    The response &MUST; include the following header fields:
     250   When a 206 response is generated, the sender &MUST; generate the following
     251   header fields:
    250252  <list style="symbols">
    251253    <t>
     
    270272</t>
    271273<t>
    272    If a 206 is sent in response to a request with an <x:ref>If-Range</x:ref>
    273    header field, it &SHOULD-NOT; include other representation header fields.
    274    Otherwise, the response &MUST; include all of the representation header
    275    fields that would have been sent with a <x:ref>200 (OK)</x:ref> response
     274   If a 206 is generated in response to a request with an <x:ref>If-Range</x:ref>
     275   header field, the sender &SHOULD-NOT; generate other representation header
     276   fields beyond those described above.
     277   Otherwise, the sender &MUST; generate all of the same representation header
     278   fields that would have been sent in a <x:ref>200 (OK)</x:ref> response
    276279   to the same request.
    277280</t>
     
    286289  <x:anchor-alias value="416 (Requested Range Not Satisfiable)"/>
    287290<t>
    288    A server &SHOULD; send a response with this status code if a request
    289    included a <x:ref>Range</x:ref> header field (<xref target="header.range"/>),
    290    and none of the ranges-specifier values in this field overlap the current
    291    extent of the selected resource, and the request did not include an
     291   The <x:dfn>416 (Requested Range Not Satisfiable)</x:dfn> status code
     292   indicates that none of the ranges-specifier values in the request's
     293   <x:ref>Range</x:ref> header field (<xref target="header.range"/>)
     294   overlap the current
     295   extent of the selected resource and the request did not include an
    292296   <x:ref>If-Range</x:ref> header field (<xref target="header.if-range"/>).
    293297   (For byte-ranges, this means that the first-byte-pos of all of the
    294298   byte-range-spec values were greater than the current length of the selected
    295    resource.)
     299   representation.)
    296300</t>
    297301<t>
    298302   When this status code is sent in response to a byte-range request, the
    299    response &SHOULD; include a <x:ref>Content-Range</x:ref> header field
    300    specifying the current length of the representation (see <xref target="header.content-range"/>).
    301    This response &MUST-NOT; use the multipart/byteranges media type.
     303   sender &SHOULD; generate a <x:ref>Content-Range</x:ref> header field
     304   specifying the current length of the selected representation
     305   (see <xref target="header.content-range"/>).
    302306</t>
    303307<figure>
     
    377381</t>
    378382<t>
    379    When a client receives an incomplete <x:ref>200 (OK)</x:ref> or <x:ref>206 (Partial Content)</x:ref>
    380    response and already has one or more stored responses for the same method
    381    and effective request URI, all of the stored responses with the same
    382    strong validator &MAY; be combined with the partial content in this new
    383    response.  If none of the stored responses contain the same strong
    384    validator, then this new response corresponds to a new representation
    385    and &MUST-NOT; be combined with the existing stored responses.
    386 </t>
    387 <t>
    388    If the new response is an incomplete <x:ref>200 (OK)</x:ref> response, then the header
    389    fields of that new response are used for any combined response and replace
    390    those of the matching stored responses.
    391 </t>
    392 <t>
    393    If the new response is a <x:ref>206 (Partial Content)</x:ref> response and at least one
    394    of the matching stored responses is a <x:ref>200 (OK)</x:ref>, then the combined response
    395    header fields consist of the most recent 200 response's header fields.
    396    If all of the matching stored responses are 206 responses, then the
    397    stored response with the most recent header fields is used as the source of
    398    header fields for the combined response, except that the client &MUST;
    399    use other header fields provided in the new response, aside from
    400    <x:ref>Content-Range</x:ref>, to replace all instances of the corresponding
    401    header fields in the stored response.
     383   When a client receives an incomplete <x:ref>200 (OK)</x:ref> response or a
     384   <x:ref>206 (Partial Content)</x:ref> response, and already has one or more
     385   partial responses for the same method and effective request URI that have
     386   the same strong validator as present in the new response,
     387   the recipient &MAY; combine some or all of those responses into a set of
     388   continuous ranges. A client &MUST-NOT; combine responses that differ in the
     389   strong validator or that do not have a strong validator.
     390</t>
     391<t>
     392   If the new response is an incomplete <x:ref>200 (OK)</x:ref> response, then
     393   the header fields of that new response are used for any combined response
     394   and replace those of the matching stored responses.
     395</t>
     396<t>
     397   If the new response is a <x:ref>206 (Partial Content)</x:ref> response and
     398   at least one of the matching stored responses is a <x:ref>200 (OK)</x:ref>,
     399   then the combined response header fields consist of the most recent 200
     400   response's header fields. If all of the matching stored responses are 206
     401   responses, then the stored response with the most recent header fields is
     402   used as the source of header fields for the combined response, except that
     403   the client &MUST; use other header fields provided in the new response,
     404   aside from <x:ref>Content-Range</x:ref>, to replace all instances of the
     405   corresponding header fields in the stored response.
    402406</t>
    403407<t>
     
    405409   content ranges in the new response and each of the selected responses.
    406410   If the union consists of the entire range of the representation, then the
    407    combined response &MUST; be recorded as a complete <x:ref>200 (OK)</x:ref>
    408    response with a <x:ref>Content-Length</x:ref> header field that reflects the
    409    complete length. Otherwise, the combined response(s) &MUST; include a
    410    <x:ref>Content-Range</x:ref> header field describing the included range(s)
    411    and be recorded as incomplete.  If the union consists of a discontinuous
    412    range of the representation, then the client &MAY; store it as either a
    413    multipart range response or as multiple <x:ref>206</x:ref> responses with
    414    one continuous range each.
     411   client &MUST; record the combined response as if it were a complete
     412   <x:ref>200 (OK)</x:ref> response, including a <x:ref>Content-Length</x:ref>
     413   header field that reflects the complete length.
     414   Otherwise, the client &MUST; record the set of continuous ranges as one of
     415   the following:
     416   an incomplete <x:ref>200 (OK)</x:ref> response if the combined response is
     417   a prefix of the representation,
     418   a single <x:ref>206 (Partial Content)</x:ref> response containing a
     419   multipart/byteranges body, or
     420   multiple <x:ref>206 (Partial Content)</x:ref> responses, each with one
     421   continuous range that is indicated by a <x:ref>Content-Range</x:ref> header
     422   field.
    415423</t>
    416424</section>
  • draft-ietf-httpbis/latest/p6-cache.html

    r2053 r2066  
    452452  }
    453453  @bottom-center {
    454        content: "Expires June 19, 2013";
     454       content: "Expires July 2, 2013";
    455455  }
    456456  @bottom-right {
     
    498498      <meta name="dct.creator" content="Reschke, J. F.">
    499499      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
    500       <meta name="dct.issued" scheme="ISO8601" content="2012-12-16">
     500      <meta name="dct.issued" scheme="ISO8601" content="2012-12-29">
    501501      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    502502      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.">
     
    524524            </tr>
    525525            <tr>
    526                <td class="left">Expires: June 19, 2013</td>
     526               <td class="left">Expires: July 2, 2013</td>
    527527               <td class="right">J. Reschke, Editor</td>
    528528            </tr>
     
    533533            <tr>
    534534               <td class="left"></td>
    535                <td class="right">December 16, 2012</td>
     535               <td class="right">December 29, 2012</td>
    536536            </tr>
    537537         </tbody>
     
    559559         in progress”.
    560560      </p>
    561       <p>This Internet-Draft will expire on June 19, 2013.</p>
     561      <p>This Internet-Draft will expire on July 2, 2013.</p>
    562562      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    563563      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    884884      <p id="rfc.section.4.p.2">Note that any of the requirements listed above can be overridden by a cache-control extension; see <a href="#cache.control.extensions" title="Cache Control Extensions">Section&nbsp;7.2.3</a>.
    885885      </p>
    886       <p id="rfc.section.4.p.3">When a stored response is used to satisfy a request without validation, a cache <em class="bcp14">MUST</em> include a single <a href="#header.age" class="smpl">Age</a> header field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section&nbsp;7.1</a>) in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section&nbsp;4.1.3</a>.
     886      <p id="rfc.section.4.p.3">When a stored response is used to satisfy a request without validation, a cache <em class="bcp14">MUST</em> send a single <a href="#header.age" class="smpl">Age</a> header field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section&nbsp;7.1</a>) in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section&nbsp;4.1.3</a>.
    887887      </p>
    888888      <p id="rfc.section.4.p.4">A cache <em class="bcp14">MUST</em> write through requests with methods that are unsafe (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 4.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) to the origin server; i.e., a cache is not allowed to generate a reply to such a request before having forwarded the request
  • draft-ietf-httpbis/latest/p6-cache.xml

    r2053 r2066  
    505505<t>
    506506   When a stored response is used to satisfy a request without validation,
    507    a cache &MUST; include a single <x:ref>Age</x:ref> header field
     507   a cache &MUST; send a single <x:ref>Age</x:ref> header field
    508508   (<xref target="header.age"/>) in the response with a value equal to the
    509509   stored response's current_age; see <xref target="age.calculations" />.
  • draft-ietf-httpbis/latest/p7-auth.html

    r2052 r2066  
    449449  }
    450450  @bottom-center {
    451        content: "Expires June 18, 2013";
     451       content: "Expires July 2, 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-12-15">
     491      <meta name="dct.issued" scheme="ISO8601" content="2012-12-29">
    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. This document defines the HTTP Authentication framework.">
     
    517517            <tr>
    518518               <td class="left">Intended status: Standards Track</td>
    519                <td class="right">December 15, 2012</td>
     519               <td class="right">December 29, 2012</td>
    520520            </tr>
    521521            <tr>
    522                <td class="left">Expires: June 18, 2013</td>
     522               <td class="left">Expires: July 2, 2013</td>
    523523               <td class="right"></td>
    524524            </tr>
     
    546546         in progress”.
    547547      </p>
    548       <p>This Internet-Draft will expire on June 18, 2013.</p>
     548      <p>This Internet-Draft will expire on July 2, 2013.</p>
    549549      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    550550      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    679679      <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.5"></span>  <a href="#challenge.and.response" class="smpl">credentials</a> = <a href="#challenge.and.response" class="smpl">auth-scheme</a> [ 1*<a href="#imported.abnf" class="smpl">SP</a> ( <a href="#challenge.and.response" class="smpl">token68</a> / #<a href="#challenge.and.response" class="smpl">auth-param</a> ) ]
    680680</pre><p id="rfc.section.2.1.p.14">Upon a request for a protected resource that omits credentials, contains invalid credentials (e.g., a bad password) or partial
    681          credentials (e.g., when the authentication scheme requires more than one round trip), an origin server <em class="bcp14">SHOULD</em> send a <a href="#status.401" class="smpl">401 (Unauthorized)</a> response. Such responses <em class="bcp14">MUST</em> include a <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> header field containing at least one (possibly new) challenge applicable to the requested resource.
     681         credentials (e.g., when the authentication scheme requires more than one round trip), an origin server <em class="bcp14">SHOULD</em> send a <a href="#status.401" class="smpl">401 (Unauthorized)</a> response that contains a <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> header field with at least one (possibly new) challenge applicable to the requested resource.
    682682      </p>
    683683      <p id="rfc.section.2.1.p.15">Likewise, upon a request that requires authentication by proxies that omit credentials or contain invalid or partial credentials,
    684          a proxy <em class="bcp14">SHOULD</em> send a <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> response. Such responses <em class="bcp14">MUST</em> include a <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field containing a (possibly new) challenge applicable to the proxy.
     684         a proxy <em class="bcp14">SHOULD</em> send a <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> response that contains a <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field with a (possibly new) challenge applicable to the proxy.
    685685      </p>
    686686      <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 6.5.3</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
     
    778778      <div id="rfc.iref.8"></div>
    779779      <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="status.401" href="#status.401">401 Unauthorized</a></h2>
    780       <p id="rfc.section.3.1.p.1">The request requires user authentication. The response <em class="bcp14">MUST</em> include a <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> header field (<a href="#header.www-authenticate" id="rfc.xref.header.www-authenticate.1" title="WWW-Authenticate">Section&nbsp;4.4</a>) containing a challenge applicable to the target resource. The client <em class="bcp14">MAY</em> repeat the request with a suitable <a href="#header.authorization" class="smpl">Authorization</a> header field (<a href="#header.authorization" id="rfc.xref.header.authorization.2" title="Authorization">Section&nbsp;4.1</a>). If the request already included Authorization credentials, then the 401 response indicates that authorization has been
    781          refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has
    782          already attempted authentication at least once, then the user <em class="bcp14">SHOULD</em> be presented the representation that was given in the response, since that representation might include relevant diagnostic
    783          information.
     780      <p id="rfc.section.3.1.p.1">The <dfn>401 (Unauthorized)</dfn> status code indicates that the request has not been applied because it lacks valid authentication credentials for the target
     781         resource. The origin server <em class="bcp14">MUST</em> send a <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> header field (<a href="#header.www-authenticate" id="rfc.xref.header.www-authenticate.1" title="WWW-Authenticate">Section&nbsp;4.4</a>) containing at least one challenge applicable to the target resource. If the request included authentication credentials,
     782         then the 401 response indicates that authorization has been refused for those credentials. The client <em class="bcp14">MAY</em> repeat the request with a new or replaced <a href="#header.authorization" class="smpl">Authorization</a> header field (<a href="#header.authorization" id="rfc.xref.header.authorization.2" title="Authorization">Section&nbsp;4.1</a>). If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication
     783         at least once, then the user agent <em class="bcp14">SHOULD</em> present the enclosed representation to the user, since it usually contains relevant diagnostic information.
    784784      </p>
    785785      <div id="rfc.iref.8"></div>
    786786      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="status.407" href="#status.407">407 Proxy Authentication Required</a></h2>
    787       <p id="rfc.section.3.2.p.1">This code is similar to <a href="#status.401" class="smpl">401 (Unauthorized)</a>, but indicates that the client ought to first authenticate itself with the proxy. The proxy <em class="bcp14">MUST</em> send a <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field (<a href="#header.proxy-authenticate" id="rfc.xref.header.proxy-authenticate.1" title="Proxy-Authenticate">Section&nbsp;4.2</a>) containing a challenge applicable to the proxy for the target resource. The client <em class="bcp14">MAY</em> repeat the request with a suitable <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a> header field (<a href="#header.proxy-authorization" id="rfc.xref.header.proxy-authorization.1" title="Proxy-Authorization">Section&nbsp;4.3</a>).
     787      <p id="rfc.section.3.2.p.1">The <dfn>407 (Proxy Authentication Required)</dfn> status code is similar to <a href="#status.401" class="smpl">401 (Unauthorized)</a>, but indicates that the client needs to authenticate itself in order to use a proxy. The proxy <em class="bcp14">MUST</em> send a <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field (<a href="#header.proxy-authenticate" id="rfc.xref.header.proxy-authenticate.1" title="Proxy-Authenticate">Section&nbsp;4.2</a>) containing a challenge applicable to that proxy for the target resource. The client <em class="bcp14">MAY</em> repeat the request with a new or replaced <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a> header field (<a href="#header.proxy-authorization" id="rfc.xref.header.proxy-authorization.1" title="Proxy-Authorization">Section&nbsp;4.3</a>).
    788788      </p>
    789789      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1>
  • draft-ietf-httpbis/latest/p7-auth.xml

    r2052 r2066  
    242242   invalid credentials (e.g., a bad password) or partial credentials (e.g.,
    243243   when the authentication scheme requires more than one round trip), an origin
    244    server &SHOULD; send a <x:ref>401 (Unauthorized)</x:ref> response. Such
    245    responses &MUST; include a <x:ref>WWW-Authenticate</x:ref> header field
    246    containing at least one (possibly new) challenge applicable to the
    247    requested resource.
     244   server &SHOULD; send a <x:ref>401 (Unauthorized)</x:ref> response that
     245   contains a <x:ref>WWW-Authenticate</x:ref> header field with at least one
     246   (possibly new) challenge applicable to the requested resource.
    248247</t>
    249248<t>
    250249   Likewise, upon a request that requires authentication by proxies that omit
    251250   credentials or contain invalid or partial credentials, a proxy &SHOULD;
    252    send a <x:ref>407 (Proxy Authentication Required)</x:ref> response. Such responses
    253    &MUST; include a <x:ref>Proxy-Authenticate</x:ref> header field containing a (possibly
     251   send a <x:ref>407 (Proxy Authentication Required)</x:ref> response that
     252   contains a <x:ref>Proxy-Authenticate</x:ref> header field with a (possibly
    254253   new) challenge applicable to the proxy.
    255254</t>
     
    427426  <x:anchor-alias value="401 (Unauthorized)"/>
    428427<t>
    429    The request requires user authentication. The response &MUST; include a
     428   The <x:dfn>401 (Unauthorized)</x:dfn> status code indicates that the
     429   request has not been applied because it lacks valid authentication
     430   credentials for the target resource. The origin server &MUST; send a
    430431   <x:ref>WWW-Authenticate</x:ref> header field (<xref target="header.www-authenticate"/>)
    431    containing a challenge applicable to the target resource. The client &MAY;
    432    repeat the request with a suitable <x:ref>Authorization</x:ref> header field
    433    (<xref target="header.authorization"/>). If the request already included
    434    Authorization credentials, then the 401 response indicates that authorization
    435    has been refused for those credentials. If the 401 response contains the
    436    same challenge as the prior response, and the user agent has already attempted
    437    authentication at least once, then the user &SHOULD; be presented the
    438    representation that was given in the response, since that representation might
    439    include relevant diagnostic information.
     432   containing at least one challenge applicable to the target resource.
     433   If the request included authentication credentials, then the 401 response
     434   indicates that authorization has been refused for those credentials.
     435   The client &MAY; repeat the request with a new or replaced
     436   <x:ref>Authorization</x:ref> header field (<xref target="header.authorization"/>).
     437   If the 401 response contains the same challenge as the prior response, and
     438   the user agent has already attempted authentication at least once, then the
     439   user agent &SHOULD; present the enclosed representation to the user, since
     440   it usually contains relevant diagnostic information.
    440441</t>
    441442</section>
     
    444445  <x:anchor-alias value="407 (Proxy Authentication Required)"/>
    445446<t>
    446    This code is similar to <x:ref>401 (Unauthorized)</x:ref>, but indicates that the
    447    client ought to first authenticate itself with the proxy. The proxy &MUST;
    448    send a <x:ref>Proxy-Authenticate</x:ref> header field (<xref target="header.proxy-authenticate"/>) containing a
    449    challenge applicable to the proxy for the target resource. The
    450    client &MAY; repeat the request with a suitable <x:ref>Proxy-Authorization</x:ref>
     447   The <x:dfn>407 (Proxy Authentication Required)</x:dfn> status code is
     448   similar to <x:ref>401 (Unauthorized)</x:ref>, but indicates that the client
     449   needs to authenticate itself in order to use a proxy.
     450   The proxy &MUST; send a <x:ref>Proxy-Authenticate</x:ref> header field
     451   (<xref target="header.proxy-authenticate"/>) containing a challenge
     452   applicable to that proxy for the target resource. The client &MAY; repeat
     453   the request with a new or replaced <x:ref>Proxy-Authorization</x:ref>
    451454   header field (<xref target="header.proxy-authorization"/>).
    452455</t>
Note: See TracChangeset for help on using the changeset viewer.