Changeset 2066 for draft-ietf-httpbis
- Timestamp:
- 29/12/12 10:14:11 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 10 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r2053 r2066 449 449 } 450 450 @bottom-center { 451 content: "Expires Ju ne 19, 2013";451 content: "Expires July 2, 2013"; 452 452 } 453 453 @bottom-right { … … 491 491 <meta name="dct.creator" content="Reschke, J. F."> 492 492 <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"> 494 494 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 495 495 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 520 520 <tr> 521 521 <td class="left">Intended status: Standards Track</td> 522 <td class="right">December 16, 2012</td>522 <td class="right">December 29, 2012</td> 523 523 </tr> 524 524 <tr> 525 <td class="left">Expires: Ju ne 19, 2013</td>525 <td class="left">Expires: July 2, 2013</td> 526 526 <td class="right"></td> 527 527 </tr> … … 551 551 in progress”. 552 552 </p> 553 <p>This Internet-Draft will expire on Ju ne 19, 2013.</p>553 <p>This Internet-Draft will expire on July 2, 2013.</p> 554 554 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 555 555 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1478 1478 entire request before processing. 1479 1479 </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> includea 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 of1480 <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 1481 1481 specific user configuration or by remembering the version of a prior received response. 1482 1482 </p> … … 1503 1503 <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 1504 1504 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> includethe 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. 1506 1506 </p> 1507 1507 <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 1751 1751 </t> 1752 1752 <t> 1753 A client that sends a request containing a message body &MUST; includea1753 A user agent that sends a request containing a message body &MUST; send a 1754 1754 valid <x:ref>Content-Length</x:ref> header field if it does not know the 1755 1755 server will handle HTTP/1.1 (or later) requests; such knowledge can be in … … 1810 1810 preface or follow a request with an extra CRLF. If terminating 1811 1811 the request message body with a line-ending is desired, then the 1812 user agent &MUST; includethe terminating CRLF octets as part of the1812 user agent &MUST; count the terminating CRLF octets as part of the 1813 1813 message body length. 1814 1814 </t> -
draft-ietf-httpbis/latest/p4-conditional.html
r2052 r2066 449 449 } 450 450 @bottom-center { 451 content: "Expires Ju ne 18, 2013";451 content: "Expires July 2, 2013"; 452 452 } 453 453 @bottom-right { … … 491 491 <meta name="dct.creator" content="Reschke, J. F."> 492 492 <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"> 494 494 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 495 495 <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."> … … 517 517 </tr> 518 518 <tr> 519 <td class="left">Expires: Ju ne 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> 521 521 </tr> 522 522 </tbody> … … 545 545 in progress”. 546 546 </p> 547 <p>This Internet-Draft will expire on Ju ne 18, 2013.</p>547 <p>This Internet-Draft will expire on July 2, 2013.</p> 548 548 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 549 549 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1056 1056 <div id="rfc.iref.21"></div> 1057 1057 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="status.304" href="#status.304">304 Not Modified</a></h2> 1058 <p id="rfc.section.4.1.p.1">The 304status 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 server1058 <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 1059 1059 to transfer a representation of the target resource because the request indicates that the client which made the request conditional 1060 1060 already has a valid representation; the server is therefore redirecting that client to make use of that stored representation 1061 1061 as if it were the payload of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response. 1062 1062 </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. 1067 1065 </p> 1068 1066 <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 guiding1067 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 1070 1068 cache updates (e.g., future HTTP extensions). 1071 1069 </p> … … 1078 1076 <div id="rfc.iref.21"></div> 1079 1077 <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <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 tested1081 onthe server. This response code allows the client to place preconditions on the current resource state (its current representations1078 <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 1082 1080 and metadata) and thus prevent the request method from being applied if the target resource is in an unexpected state. 1083 1081 </p> … … 1317 1315 <a href="#imported.abnf" class="smpl">obs-text</a> = <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>> 1318 1316 </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> = <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>>1317 <div id="rfc.figure.u.17"></div><pre class="inline"> <a href="#imported.abnf" class="smpl">HTTP-date</a> = <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>> 1320 1318 </pre><h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 1321 1319 <div id="rfc.figure.u.18"></div> <pre class="inline"><a href="#header.etag" class="smpl">ETag</a> = entity-tag … … 1441 1439 </ul> 1442 1440 </li> 1443 <li><em>Part2</em> <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> <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> 1444 1442 <li><em>Section 3.4</em> <a href="#rfc.xref.Part2.2">2.3.3</a></li> 1445 1443 <li><em>Section 5.3.4</em> <a href="#rfc.xref.Part2.3">2.3.3</a></li> 1446 <li><em>Section 7.1.1.1</em> <a href="#rfc.xref.Part2.5">B</a></li> 1447 <li><em>Section 7.1.1.2</em> <a href="#rfc.xref.Part2.4">4.1</a></li> 1444 <li><em>Section 7.1.1.1</em> <a href="#rfc.xref.Part2.4">B</a></li> 1448 1445 </ul> 1449 1446 </li> -
draft-ietf-httpbis/latest/p4-conditional.xml
r2052 r2066 928 928 <x:anchor-alias value="304 (Not Modified)"/> 929 929 <t> 930 The 304status code indicates that a conditional GET request has been930 The <x:dfn>304 (Not Modified)</x:dfn> status code indicates that a conditional GET request has been 931 931 received and would have resulted in a <x:ref>200 (OK)</x:ref> response 932 932 if it were not for the fact that the condition has evaluated to false. … … 939 939 </t> 940 940 <t> 941 The 304 response &MUST-NOT; contain a message-body, and thusis always941 A 304 response cannot contain a message-body; it is always 942 942 terminated by the first empty line after the header fields. 943 943 </t> 944 944 <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. 952 953 </t> 953 954 <t> 954 955 Since the goal of a 304 response is to minimize information transfer 955 956 when the recipient already has one or more cached representations, 956 the response &SHOULD-NOT; include representation metadata other957 a sender &SHOULD-NOT; generate representation metadata other 957 958 than the above listed fields unless said metadata exists for the 958 959 purpose of guiding cache updates (e.g., future HTTP extensions). … … 978 979 <x:anchor-alias value="412 (Precondition Failed)"/> 979 980 <t> 980 The 412status code indicates that one or more preconditions given in981 The <x:dfn>412 (Precondition Failed)</x:dfn> status code indicates that one or more preconditions given in 981 982 the request header fields evaluated to false when tested on the server. 982 983 This response code allows the client to place preconditions on the -
draft-ietf-httpbis/latest/p5-range.html
r2053 r2066 449 449 } 450 450 @bottom-center { 451 content: "Expires Ju ne 19, 2013";451 content: "Expires July 2, 2013"; 452 452 } 453 453 @bottom-right { … … 493 493 <meta name="dct.creator" content="Reschke, J. F."> 494 494 <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"> 496 496 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 497 497 <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."> … … 519 519 </tr> 520 520 <tr> 521 <td class="left">Expires: Ju ne 19, 2013</td>521 <td class="left">Expires: July 2, 2013</td> 522 522 <td class="right">J. Reschke, Editor</td> 523 523 </tr> … … 528 528 <tr> 529 529 <td class="left"></td> 530 <td class="right">December 16, 2012</td>530 <td class="right">December 29, 2012</td> 531 531 </tr> 532 532 </tbody> … … 553 553 in progress”. 554 554 </p> 555 <p>This Internet-Draft will expire on Ju ne 19, 2013.</p>555 <p>This Internet-Draft will expire on July 2, 2013.</p> 556 556 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 557 557 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 682 682 <div id="rfc.iref.3"></div> 683 683 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <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 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 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 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 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: 687 687 </p> 688 688 <ul> … … 693 693 </li> 694 694 </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 witha <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. 696 696 </p> 697 697 <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. … … 699 699 <div id="rfc.iref.3"></div> 700 700 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <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 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 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 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 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 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 5.2</a>). 706 705 </p> 707 706 <div id="rfc.figure.u.2"></div> … … 744 743 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>. 745 744 </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. 749 747 </p> 750 748 <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 … … 756 754 </p> 757 755 <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. 760 757 </p> 761 758 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1> -
draft-ietf-httpbis/latest/p5-range.xml
r2053 r2066 240 240 <x:anchor-alias value="206 (Partial Content)"/> 241 241 <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. 243 244 The request &MUST; have included a <x:ref>Range</x:ref> header field 244 245 (<xref target="header.range"/>) indicating the desired range, and &MAY; have … … 247 248 </t> 248 249 <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: 250 252 <list style="symbols"> 251 253 <t> … … 270 272 </t> 271 273 <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 276 279 to the same request. 277 280 </t> … … 286 289 <x:anchor-alias value="416 (Requested Range Not Satisfiable)"/> 287 290 <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 292 296 <x:ref>If-Range</x:ref> header field (<xref target="header.if-range"/>). 293 297 (For byte-ranges, this means that the first-byte-pos of all of the 294 298 byte-range-spec values were greater than the current length of the selected 295 re source.)299 representation.) 296 300 </t> 297 301 <t> 298 302 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 field300 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"/>). 302 306 </t> 303 307 <figure> … … 377 381 </t> 378 382 <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 method381 and effective request URI, all of the stored responses with the same382 strong validator &MAY; be combined with the partial content in this new383 response. If none of the stored responses contain the same strong384 validator, then this new response corresponds to a new representation385 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 header389 fields of that new response are used for any combined response and replace390 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 one394 of the matching stored responses is a <x:ref>200 (OK)</x:ref>, then the combined response395 header fields consist of the most recent 200 response's header fields.396 If all of the matching stored responses are 206 responses, then the397 stored response with the most recent header fields is used as the source of398 header fields for the combined response, except that the client &MUST;399 use other header fields provided in the new response, aside from400 <x:ref>Content-Range</x:ref>, to replace all instances of the corresponding401 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. 402 406 </t> 403 407 <t> … … 405 409 content ranges in the new response and each of the selected responses. 406 410 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. 415 423 </t> 416 424 </section> -
draft-ietf-httpbis/latest/p6-cache.html
r2053 r2066 452 452 } 453 453 @bottom-center { 454 content: "Expires Ju ne 19, 2013";454 content: "Expires July 2, 2013"; 455 455 } 456 456 @bottom-right { … … 498 498 <meta name="dct.creator" content="Reschke, J. F."> 499 499 <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"> 501 501 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 502 502 <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."> … … 524 524 </tr> 525 525 <tr> 526 <td class="left">Expires: Ju ne 19, 2013</td>526 <td class="left">Expires: July 2, 2013</td> 527 527 <td class="right">J. Reschke, Editor</td> 528 528 </tr> … … 533 533 <tr> 534 534 <td class="left"></td> 535 <td class="right">December 16, 2012</td>535 <td class="right">December 29, 2012</td> 536 536 </tr> 537 537 </tbody> … … 559 559 in progress”. 560 560 </p> 561 <p>This Internet-Draft will expire on Ju ne 19, 2013.</p>561 <p>This Internet-Draft will expire on July 2, 2013.</p> 562 562 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 563 563 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 884 884 <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 7.2.3</a>. 885 885 </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> includea single <a href="#header.age" class="smpl">Age</a> header field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section 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 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 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 4.1.3</a>. 887 887 </p> 888 888 <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 505 505 <t> 506 506 When a stored response is used to satisfy a request without validation, 507 a cache &MUST; includea single <x:ref>Age</x:ref> header field507 a cache &MUST; send a single <x:ref>Age</x:ref> header field 508 508 (<xref target="header.age"/>) in the response with a value equal to the 509 509 stored response's current_age; see <xref target="age.calculations" />. -
draft-ietf-httpbis/latest/p7-auth.html
r2052 r2066 449 449 } 450 450 @bottom-center { 451 content: "Expires Ju ne 18, 2013";451 content: "Expires July 2, 2013"; 452 452 } 453 453 @bottom-right { … … 489 489 <meta name="dct.creator" content="Reschke, J. F."> 490 490 <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"> 492 492 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 493 493 <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."> … … 517 517 <tr> 518 518 <td class="left">Intended status: Standards Track</td> 519 <td class="right">December 15, 2012</td>519 <td class="right">December 29, 2012</td> 520 520 </tr> 521 521 <tr> 522 <td class="left">Expires: Ju ne 18, 2013</td>522 <td class="left">Expires: July 2, 2013</td> 523 523 <td class="right"></td> 524 524 </tr> … … 546 546 in progress”. 547 547 </p> 548 <p>This Internet-Draft will expire on Ju ne 18, 2013.</p>548 <p>This Internet-Draft will expire on July 2, 2013.</p> 549 549 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 550 550 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 679 679 <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> ) ] 680 680 </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 containingat 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. 682 682 </p> 683 683 <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 containinga (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. 685 685 </p> 686 686 <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>). … … 778 778 <div id="rfc.iref.8"></div> 779 779 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <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 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 4.1</a>). If the request already included Authorization credentials, then the 401 response indicates that authorization has been781 re fused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has782 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 diagnostic783 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 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 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. 784 784 </p> 785 785 <div id="rfc.iref.8"></div> 786 786 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="status.407" href="#status.407">407 Proxy Authentication Required</a></h2> 787 <p id="rfc.section.3.2.p.1">Th is 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 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 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 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 4.3</a>). 788 788 </p> 789 789 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1> -
draft-ietf-httpbis/latest/p7-auth.xml
r2052 r2066 242 242 invalid credentials (e.g., a bad password) or partial credentials (e.g., 243 243 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. 248 247 </t> 249 248 <t> 250 249 Likewise, upon a request that requires authentication by proxies that omit 251 250 credentials or contain invalid or partial credentials, a proxy &SHOULD; 252 send a <x:ref>407 (Proxy Authentication Required)</x:ref> response . Such responses253 &MUST; include a <x:ref>Proxy-Authenticate</x:ref> header field containinga (possibly251 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 254 253 new) challenge applicable to the proxy. 255 254 </t> … … 427 426 <x:anchor-alias value="401 (Unauthorized)"/> 428 427 <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 430 431 <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 field433 (<xref target="header.authorization"/>). If the request already included434 Authorization credentials, then the 401 response indicates that authorization435 has been refused for those credentials. If the 401 response contains the436 same challenge as the prior response, and the user agent has already attempted437 authentication at least once, then the user &SHOULD; be presentedthe438 representation that was given in the response, since that representation might439 i ncluderelevant 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. 440 441 </t> 441 442 </section> … … 444 445 <x:anchor-alias value="407 (Proxy Authentication Required)"/> 445 446 <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> 451 454 header field (<xref target="header.proxy-authorization"/>). 452 455 </t>
Note: See TracChangeset
for help on using the changeset viewer.