* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Changeset 2066


Ignore:
Timestamp:
2012-12-29 02:14:11 (22 months ago)
Author:
fielding@gbiv.com
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.