Changeset 1452 for draft-ietf-httpbis
- Timestamp:
- 23/10/11 20:20:31 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 14 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1451 r1452 359 359 } 360 360 @bottom-center { 361 content: "Expires April 2 2, 2012";361 content: "Expires April 25, 2012"; 362 362 } 363 363 @bottom-right { … … 408 408 <meta name="dct.creator" content="Reschke, J. F."> 409 409 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 410 <meta name="dct.issued" scheme="ISO8601" content="2011-10-2 0">410 <meta name="dct.issued" scheme="ISO8601" content="2011-10-23"> 411 411 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 412 412 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 440 440 </tr> 441 441 <tr> 442 <td class="left">Expires: April 2 2, 2012</td>442 <td class="left">Expires: April 25, 2012</td> 443 443 <td class="right">HP</td> 444 444 </tr> … … 493 493 <tr> 494 494 <td class="left"></td> 495 <td class="right">October 2 0, 2011</td>495 <td class="right">October 23, 2011</td> 496 496 </tr> 497 497 </tbody> … … 526 526 in progress”. 527 527 </p> 528 <p>This Internet-Draft will expire on April 2 2, 2012.</p>528 <p>This Internet-Draft will expire on April 25, 2012.</p> 529 529 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 530 530 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 545 545 <ul class="toc"> 546 546 <li>1. <a href="#introduction">Introduction</a><ul> 547 <li>1.1 <a href="#intro. requirements">Requirements</a></li>547 <li>1.1 <a href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></li> 548 548 <li>1.2 <a href="#notation">Syntax Notation</a><ul> 549 549 <li>1.2.1 <a href="#notation.abnf">ABNF Extension: #rule</a></li> … … 751 751 thereby defining the complete set of requirements for message parsers and message-forwarding intermediaries. 752 752 </p> 753 <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="intro. requirements" href="#intro.requirements">Requirements</a></h2>753 <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="intro.conformance.and.error.handling" href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></h2> 754 754 <p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 755 755 in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>. 756 756 </p> 757 <p id="rfc.section.1.1.p.2">An implementation is not compliant if it fails to satisfy one or more of the "MUST" or "REQUIRED" level requirements for the 758 protocols it implements. An implementation that satisfies all the "MUST" or "REQUIRED" level and all the "SHOULD" level requirements 759 for its protocols is said to be "unconditionally compliant"; one that satisfies all the "MUST" level requirements but not 760 all the "SHOULD" level requirements for its protocols is said to be "conditionally compliant". 757 <p id="rfc.section.1.1.p.2">This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients, 758 Servers, User-Agents, Origin Servers, Intermediaries, Proxies and Gateways. See <a href="#architecture" title="Architecture">Section 2</a> for definitions of these terms. 759 </p> 760 <p id="rfc.section.1.1.p.3">An implementation is considered conformant if it complies with all of the requirements associated with its role(s). Note that 761 SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable. 762 </p> 763 <p id="rfc.section.1.1.p.4">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section 1.2</a>). In addition to the prose requirements placed upon them, Senders <em class="bcp14">MUST NOT</em> generate protocol elements that are invalid. 764 </p> 765 <p id="rfc.section.1.1.p.5">Unless noted otherwise, Recipients <em class="bcp14">MAY</em> take steps to recover a usable protocol element from an invalid construct. However, HTTP does not define specific error handling 766 mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require 767 different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the 768 Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of 769 error recovery could lead to dangerous consequences. 761 770 </p> 762 771 <div id="rfc.iref.g.1"></div> … … 3475 3484 <p id="rfc.section.C.18.p.1">Closed issues: </p> 3476 3485 <ul> 3486 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/186">http://tools.ietf.org/wg/httpbis/trac/ticket/186</a>>: "Document HTTP's error-handling philosophy" 3487 </li> 3477 3488 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/215">http://tools.ietf.org/wg/httpbis/trac/ticket/215</a>>: "Explain header registration" 3478 3489 </li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r1450 r1452 300 300 </t> 301 301 302 <section title=" Requirements" anchor="intro.requirements">302 <section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling"> 303 303 <t> 304 304 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", … … 307 307 </t> 308 308 <t> 309 An implementation is not compliant if it fails to satisfy one or more 310 of the "MUST" or "REQUIRED" level requirements for the protocols it 311 implements. An implementation that satisfies all the "MUST" or "REQUIRED" 312 level and all the "SHOULD" level requirements for its protocols is said 313 to be "unconditionally compliant"; one that satisfies all the "MUST" 314 level requirements but not all the "SHOULD" level requirements for its 315 protocols is said to be "conditionally compliant". 309 This document defines conformance criteria for several roles in HTTP 310 communication, including Senders, Recipients, Clients, Servers, User-Agents, 311 Origin Servers, Intermediaries, Proxies and Gateways. See <xref target="architecture"/> 312 for definitions of these terms. 313 </t> 314 <t> 315 An implementation is considered conformant if it complies with all of the 316 requirements associated with its role(s). Note that SHOULD-level requirements 317 are relevant here, unless one of the documented exceptions is applicable. 318 </t> 319 <t> 320 This document also uses ABNF to define valid protocol elements 321 (<xref target="notation"/>). In addition to the prose requirements placed 322 upon them, Senders &MUST-NOT; generate protocol elements that are invalid. 323 </t> 324 <t> 325 Unless noted otherwise, Recipients &MAY; take steps to recover a usable 326 protocol element from an invalid construct. However, HTTP does not define 327 specific error handling mechanisms, except in cases where it has direct 328 impact on security. This is because different uses of the protocol require 329 different error handling strategies; for example, a Web browser may wish to 330 transparently recover from a response where the Location header field 331 doesn't parse according to the ABNF, whereby in a systems control protocol 332 using HTTP, this type of error recovery could lead to dangerous consequences. 316 333 </t> 317 334 </section> … … 5861 5878 <list style="symbols"> 5862 5879 <t> 5880 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/186"/>: 5881 "Document HTTP's error-handling philosophy" 5882 </t> 5883 <t> 5863 5884 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/215"/>: 5864 5885 "Explain header registration" -
draft-ietf-httpbis/latest/p2-semantics.html
r1451 r1452 359 359 } 360 360 @bottom-center { 361 content: "Expires April 2 2, 2012";361 content: "Expires April 25, 2012"; 362 362 } 363 363 @bottom-right { … … 409 409 <meta name="dct.creator" content="Reschke, J. F."> 410 410 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 411 <meta name="dct.issued" scheme="ISO8601" content="2011-10-2 0">411 <meta name="dct.issued" scheme="ISO8601" content="2011-10-23"> 412 412 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 413 413 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields."> … … 440 440 </tr> 441 441 <tr> 442 <td class="left">Expires: April 2 2, 2012</td>442 <td class="left">Expires: April 25, 2012</td> 443 443 <td class="right">HP</td> 444 444 </tr> … … 493 493 <tr> 494 494 <td class="left"></td> 495 <td class="right">October 2 0, 2011</td>495 <td class="right">October 23, 2011</td> 496 496 </tr> 497 497 </tbody> … … 523 523 in progress”. 524 524 </p> 525 <p>This Internet-Draft will expire on April 2 2, 2012.</p>525 <p>This Internet-Draft will expire on April 25, 2012.</p> 526 526 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 527 527 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 542 542 <ul class="toc"> 543 543 <li>1. <a href="#introduction">Introduction</a><ul> 544 <li>1.1 <a href="#intro. requirements">Requirements</a></li>544 <li>1.1 <a href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></li> 545 545 <li>1.2 <a href="#notation">Syntax Notation</a><ul> 546 546 <li>1.2.1 <a href="#core.rules">Core Rules</a></li> … … 726 726 reflects how widely dispersed these topics and associated requirements had become in <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. 727 727 </p> 728 <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="intro. requirements" href="#intro.requirements">Requirements</a></h2>728 <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="intro.conformance.and.error.handling" href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></h2> 729 729 <p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 730 730 in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>. 731 731 </p> 732 <p id="rfc.section.1.1.p.2">An implementation is not compliant if it fails to satisfy one or more of the "MUST" or "REQUIRED" level requirements for the 733 protocols it implements. An implementation that satisfies all the "MUST" or "REQUIRED" level and all the "SHOULD" level requirements 734 for its protocols is said to be "unconditionally compliant"; one that satisfies all the "MUST" level requirements but not 735 all the "SHOULD" level requirements for its protocols is said to be "conditionally compliant". 732 <p id="rfc.section.1.1.p.2">This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients, 733 Servers, User-Agents, Origin Servers, Intermediaries, Proxies and Gateways. See <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for definitions of these terms. 734 </p> 735 <p id="rfc.section.1.1.p.3">An implementation is considered conformant if it complies with all of the requirements associated with its role(s). Note that 736 SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable. 737 </p> 738 <p id="rfc.section.1.1.p.4">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section 1.2</a>). In addition to the prose requirements placed upon them, Senders <em class="bcp14">MUST NOT</em> generate protocol elements that are invalid. 739 </p> 740 <p id="rfc.section.1.1.p.5">Unless noted otherwise, Recipients <em class="bcp14">MAY</em> take steps to recover a usable protocol element from an invalid construct. However, HTTP does not define specific error handling 741 mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require 742 different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the 743 Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of 744 error recovery could lead to dangerous consequences. 736 745 </p> 737 746 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="notation" href="#notation">Syntax Notation</a></h2> 738 <p id="rfc.section.1.2.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1. 2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> (which extends the syntax defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list rule). <a href="#collected.abnf" title="Collected ABNF">Appendix B</a> shows the collected ABNF, with the list rule expanded.747 <p id="rfc.section.1.2.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> (which extends the syntax defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list rule). <a href="#collected.abnf" title="Collected ABNF">Appendix B</a> shows the collected ABNF, with the list rule expanded. 739 748 </p> 740 749 <p id="rfc.section.1.2.p.2">The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG … … 743 752 </p> 744 753 <h3 id="rfc.section.1.2.1"><a href="#rfc.section.1.2.1">1.2.1</a> <a id="core.rules" href="#core.rules">Core Rules</a></h3> 745 <p id="rfc.section.1.2.1.p.1">The core rules below are defined in <a href="#Part1" id="rfc.xref.Part1. 3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>:746 </p> 747 <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#core.rules" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1. 4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>>748 <a href="#core.rules" class="smpl">RWS</a> = <RWS, defined in <a href="#Part1" id="rfc.xref.Part1. 5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>>749 <a href="#core.rules" class="smpl">obs-text</a> = <obs-text, defined in <a href="#Part1" id="rfc.xref.Part1. 6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>>750 <a href="#core.rules" class="smpl">quoted-string</a> = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1. 7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>>751 <a href="#core.rules" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1. 8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>>754 <p id="rfc.section.1.2.1.p.1">The core rules below are defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>: 755 </p> 756 <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#core.rules" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>> 757 <a href="#core.rules" class="smpl">RWS</a> = <RWS, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>> 758 <a href="#core.rules" class="smpl">obs-text</a> = <obs-text, defined in <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>> 759 <a href="#core.rules" class="smpl">quoted-string</a> = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>> 760 <a href="#core.rules" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>> 752 761 </pre><h3 id="rfc.section.1.2.2"><a href="#rfc.section.1.2.2">1.2.2</a> <a id="abnf.dependencies" href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></h3> 753 762 <p id="rfc.section.1.2.2.p.1">The ABNF rules below are defined in other parts:</p> 754 <div id="rfc.figure.u.2"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">absolute-URI</a> = <absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1. 9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>>755 <a href="#abnf.dependencies" class="smpl">comment</a> = <comment, defined in <a href="#Part1" id="rfc.xref.Part1.1 0"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a>>756 <a href="#abnf.dependencies" class="smpl">partial-URI</a> = <partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.1 1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>>757 <a href="#abnf.dependencies" class="smpl">product</a> = <product, defined in <a href="#Part1" id="rfc.xref.Part1.1 2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 5.2</a>>758 <a href="#abnf.dependencies" class="smpl">URI-reference</a> = <URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.1 3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>>763 <div id="rfc.figure.u.2"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">absolute-URI</a> = <absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 764 <a href="#abnf.dependencies" class="smpl">comment</a> = <comment, defined in <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a>> 765 <a href="#abnf.dependencies" class="smpl">partial-URI</a> = <partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 766 <a href="#abnf.dependencies" class="smpl">product</a> = <product, defined in <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 5.2</a>> 767 <a href="#abnf.dependencies" class="smpl">URI-reference</a> = <URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 759 768 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="method" href="#method">Method</a></h1> 760 <p id="rfc.section.2.p.1">The Method token indicates the request method to be performed on the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.1 4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive.769 <p id="rfc.section.2.p.1">The Method token indicates the request method to be performed on the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive. 761 770 </p> 762 771 <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.1"></span> <a href="#method" class="smpl">Method</a> = <a href="#core.rules" class="smpl">token</a> … … 837 846 to a single application, so that this is clear. 838 847 </p> 839 <p id="rfc.section.2.2.1.p.3">Due to the parsing rules defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.1 5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, definitions of HTTP methods cannot prohibit the presence of a message-body on either the request or the response message848 <p id="rfc.section.2.2.1.p.3">Due to the parsing rules defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, definitions of HTTP methods cannot prohibit the presence of a message-body on either the request or the response message 840 849 (with responses to HEAD requests being the single exception). Definitions of new methods cannot change this rule, but they 841 850 can specify that only zero-length bodies (as opposed to absent bodies) are allowed. … … 846 855 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="header.fields" href="#header.fields">Header Fields</a></h1> 847 856 <p id="rfc.section.3.p.1">Header fields are key value pairs that can be used to communicate data about the message, its payload, the target resource, 848 or about the connection itself (i.e., control data). See <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.1 6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for a general definition of their syntax.857 or about the connection itself (i.e., control data). See <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for a general definition of their syntax. 849 858 </p> 850 859 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="considerations.for.creating.header.fields" href="#considerations.for.creating.header.fields">Considerations for Creating Header Fields</a></h2> … … 854 863 with "X-" if they are to be registered (either immediately or in the future). 855 864 </p> 856 <p id="rfc.section.3.1.p.3">New header field values typically have their syntax defined using ABNF (<a href="#RFC5234" id="rfc.xref.RFC5234.3"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>), using the extensions defined in <a href="p1-messaging.html#notation.abnf" title="ABNF Extension: #rule">Section 1.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.1 7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters865 <p id="rfc.section.3.1.p.3">New header field values typically have their syntax defined using ABNF (<a href="#RFC5234" id="rfc.xref.RFC5234.3"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>), using the extensions defined in <a href="p1-messaging.html#notation.abnf" title="ABNF Extension: #rule">Section 1.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> as necessary, and are usually constrained to the range of ASCII characters. Header fields needing a greater range of characters 857 866 can use an encoding such as the one defined in <a href="#RFC5987" id="rfc.xref.RFC5987.1"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a>. 858 867 </p> 859 868 <p id="rfc.section.3.1.p.4">Because commas (",") are used as a generic delimiter between field-values, they need to be treated with care if they are allowed 860 869 in the field-value's payload. Typically, components that might contain a comma are protected with double-quotes using the 861 quoted-string ABNF production (<a href="p1-messaging.html#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.1 8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).870 quoted-string ABNF production (<a href="p1-messaging.html#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 862 871 </p> 863 872 <p id="rfc.section.3.1.p.5">For example, a textual date and a URI (either of which might contain a comma) could be safely carried in field-values like … … 874 883 <ul> 875 884 <li> 876 <p>Whether the field is a single value, or whether it can be a list (delimited by commas; see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1. 19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).885 <p>Whether the field is a single value, or whether it can be a list (delimited by commas; see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 877 886 </p> 878 887 <p>If it does not use the list syntax, how to treat messages where the header field occurs multiple times (a sensible default … … 886 895 </li> 887 896 <li> 888 <p>Whether it is appropriate to list the field-name in the Connection header (i.e., if the header is to be hop-by-hop, see <a href="p1-messaging.html#header.connection" title="Connection">Section 8.1</a> of <a href="#Part1" id="rfc.xref.Part1.2 0"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).897 <p>Whether it is appropriate to list the field-name in the Connection header (i.e., if the header is to be hop-by-hop, see <a href="p1-messaging.html#header.connection" title="Connection">Section 8.1</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 889 898 </p> 890 899 </li> … … 897 906 </li> 898 907 <li> 899 <p>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 5.1.1</a> of <a href="#Part1" id="rfc.xref.Part1.2 1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).908 <p>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 5.1.1</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 900 909 </p> 901 910 </li> … … 948 957 <tr> 949 958 <td class="left">Host</td> 950 <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 8.3</a> of <a href="#Part1" id="rfc.xref.Part1.2 2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>959 <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 8.3</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td> 951 960 </tr> 952 961 <tr> … … 988 997 <tr> 989 998 <td class="left">TE</td> 990 <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 8.4</a> of <a href="#Part1" id="rfc.xref.Part1.2 3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>999 <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 8.4</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td> 991 1000 </tr> 992 1001 <tr> … … 999 1008 <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> <a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h2> 1000 1009 <p id="rfc.section.3.3.p.1">The response header fields allow the server to pass additional information about the response which cannot be placed in the 1001 Status-Line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.2 4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).1010 Status-Line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 1002 1011 </p> 1003 1012 <div id="rfc.table.u.3"> … … 1321 1330 in an HTTP message, it is referred to as the payload of the message. HTTP representations are defined in <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. 1322 1331 </p> 1323 <p id="rfc.section.5.p.2">A representation body is only present in a message when a message-body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.2 5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The representation body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied1332 <p id="rfc.section.5.p.2">A representation body is only present in a message when a message-body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The representation body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied 1324 1333 to ensure safe and proper transfer of the message. 1325 1334 </p> … … 1327 1336 <p id="rfc.section.5.1.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p> 1328 1337 <p id="rfc.section.5.1.p.2">An HTTP request representation, when present, is always associated with an anonymous (i.e., unidentified) resource.</p> 1329 <p id="rfc.section.5.1.p.3">In the common case, an HTTP response is a representation of the target resource (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.2 6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following1338 <p id="rfc.section.5.1.p.3">In the common case, an HTTP response is a representation of the target resource (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following 1330 1339 rules are used (with the first applicable one being selected): 1331 1340 </p> … … 1550 1559 </p> 1551 1560 <p id="rfc.section.6.8.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing 1552 or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 8.8</a> of <a href="#Part1" id="rfc.xref.Part1.2 7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the1561 or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 8.8</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the 1553 1562 client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an 1554 1563 infinite loop. 1555 1564 </p> 1556 <p id="rfc.section.6.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 9.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.2 8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and contain a message-body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable.1565 <p id="rfc.section.6.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> have a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 9.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and contain a message-body that encloses a copy of the entire request message. Responses to the TRACE method are not cacheable. 1557 1566 </p> 1558 1567 <div id="rfc.iref.c.1"></div> … … 1562 1571 forwarding of packets until the connection is closed. 1563 1572 </p> 1564 <p id="rfc.section.6.9.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> use the authority form (<a href="p1-messaging.html#request-target" title="request-target">Section 3.1.1.2</a> of <a href="#Part1" id="rfc.xref.Part1. 29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon.1573 <p id="rfc.section.6.9.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> use the authority form (<a href="p1-messaging.html#request-target" title="request-target">Section 3.1.1.2</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon. 1565 1574 For example, 1566 1575 </p> … … 1626 1635 <p id="rfc.section.7.1.1.p.1">The client <em class="bcp14">SHOULD</em> continue with its request. This interim response is used to inform the client that the initial part of the request has been 1627 1636 received and has not yet been rejected by the server. The client <em class="bcp14">SHOULD</em> continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The 1628 server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.3 0"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for detailed discussion of the use and handling of this status code.1637 server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for detailed discussion of the use and handling of this status code. 1629 1638 </p> 1630 1639 <div id="rfc.iref.23"></div> 1631 1640 <div id="rfc.iref.s.3"></div> 1632 1641 <h3 id="rfc.section.7.1.2"><a href="#rfc.section.7.1.2">7.1.2</a> <a id="status.101" href="#status.101">101 Switching Protocols</a></h3> 1633 <p id="rfc.section.7.1.2.p.1">The server understands and is willing to comply with the client's request, via the Upgrade message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 8.7</a> of <a href="#Part1" id="rfc.xref.Part1.3 1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined1642 <p id="rfc.section.7.1.2.p.1">The server understands and is willing to comply with the client's request, via the Upgrade message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 8.7</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined 1634 1643 by the response's Upgrade header field immediately after the empty line which terminates the 101 response. 1635 1644 </p> … … 1683 1692 <div id="rfc.iref.s.7"></div> 1684 1693 <h3 id="rfc.section.7.2.4"><a href="#rfc.section.7.2.4">7.2.4</a> <a id="status.203" href="#status.203">203 Non-Authoritative Information</a></h3> 1685 <p id="rfc.section.7.2.4.p.1">The representation in the response has been transformed or otherwise modified by a transforming proxy (<a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.4</a> of <a href="#Part1" id="rfc.xref.Part1.3 2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Note that the behaviour of transforming intermediaries is controlled by the no-transform Cache-Control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).1694 <p id="rfc.section.7.2.4.p.1">The representation in the response has been transformed or otherwise modified by a transforming proxy (<a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.4</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Note that the behaviour of transforming intermediaries is controlled by the no-transform Cache-Control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 1686 1695 </p> 1687 1696 <p id="rfc.section.7.2.4.p.2">This status code is only appropriate when the response status code would have been 200 (OK) otherwise. When the status code … … 1718 1727 another input action. 1719 1728 </p> 1720 <p id="rfc.section.7.2.6.p.2">The message-body included with the response <em class="bcp14">MUST</em> be empty. Note that receivers still need to parse the response according to the algorithm defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.3 3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.1729 <p id="rfc.section.7.2.6.p.2">The message-body included with the response <em class="bcp14">MUST</em> be empty. Note that receivers still need to parse the response according to the algorithm defined in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 1721 1730 </p> 1722 1731 <div id="rfc.iref.30"></div> … … 2014 2023 <div id="rfc.iref.s.37"></div> 2015 2024 <h3 id="rfc.section.7.4.19"><a href="#rfc.section.7.4.19">7.4.19</a> <a id="status.426" href="#status.426">426 Upgrade Required</a></h3> 2016 <p id="rfc.section.7.4.19.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an Upgrade header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 8.7</a> of <a href="#Part1" id="rfc.xref.Part1.3 4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) specifying the required protocols.2025 <p id="rfc.section.7.4.19.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an Upgrade header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 8.7</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) specifying the required protocols. 2017 2026 </p> 2018 2027 <div id="rfc.figure.u.8"></div> … … 2074 2083 <p id="rfc.section.7.5.6.p.1">The server does not support, or refuses to support, the protocol version that was used in the request message. The server 2075 2084 is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described 2076 in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#Part1" id="rfc.xref.Part1.3 5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain a representation describing why that version is not supported and what other protocols are supported by that server.2085 in <a href="p1-messaging.html#http.version" title="Protocol Versioning">Section 2.6</a> of <a href="#Part1" id="rfc.xref.Part1.36"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain a representation describing why that version is not supported and what other protocols are supported by that server. 2077 2086 </p> 2078 2087 <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="http.date" href="#http.date">Date/Time Formats</a></h1> … … 2230 2239 </p> 2231 2240 <p id="rfc.section.9.3.p.7">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header field.</p> 2232 <p id="rfc.section.9.3.p.8">See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.3 6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (Continue) status code.2241 <p id="rfc.section.9.3.p.8">See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 6.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.37"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (Continue) status code. 2233 2242 </p> 2234 2243 <div id="rfc.iref.f.1"></div> … … 2334 2343 <h2 id="rfc.section.9.9"><a href="#rfc.section.9.9">9.9</a> <a id="header.server" href="#header.server">Server</a></h2> 2335 2344 <p id="rfc.section.9.9.p.1">The "Server" header field contains information about the software used by the origin server to handle the request.</p> 2336 <p id="rfc.section.9.9.p.2">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 5.2</a> of <a href="#Part1" id="rfc.xref.Part1.3 7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.38"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for2345 <p id="rfc.section.9.9.p.2">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 5.2</a> of <a href="#Part1" id="rfc.xref.Part1.38"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.39"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for 2337 2346 identifying the application. 2338 2347 </p> … … 2340 2349 </pre><p id="rfc.section.9.9.p.4">Example:</p> 2341 2350 <div id="rfc.figure.u.33"></div><pre class="text"> Server: CERN/3.0 libwww/2.17 2342 </pre><p id="rfc.section.9.9.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 8.8</a> of <a href="#Part1" id="rfc.xref.Part1. 39"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).2351 </pre><p id="rfc.section.9.9.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 8.8</a> of <a href="#Part1" id="rfc.xref.Part1.40"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 2343 2352 </p> 2344 2353 <div class="note" id="rfc.section.9.9.p.7"> … … 2356 2365 user agent limitations. 2357 2366 </p> 2358 <p id="rfc.section.9.10.p.3">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 5.2</a> of <a href="#Part1" id="rfc.xref.Part1.4 0"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.41"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance2367 <p id="rfc.section.9.10.p.3">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 5.2</a> of <a href="#Part1" id="rfc.xref.Part1.41"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.42"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the agent and its significant subproducts. By convention, the product tokens are listed in order of their significance 2359 2368 for identifying the application. 2360 2369 </p> … … 2828 2837 </p> 2829 2838 <h1 id="rfc.section.12"><a href="#rfc.section.12">12.</a> <a id="acks" href="#acks">Acknowledgments</a></h1> 2830 <p id="rfc.section.12.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 11</a> of <a href="#Part1" id="rfc.xref.Part1.4 2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.2839 <p id="rfc.section.12.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 11</a> of <a href="#Part1" id="rfc.xref.Part1.43"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 2831 2840 </p> 2832 2841 <h1 id="rfc.references"><a id="rfc.section.13" href="#rfc.section.13">13.</a> References … … 2988 2997 </p> 2989 2998 <p id="rfc.section.A.p.14">In the description of the Server header field, the Via field was described as a SHOULD. The requirement was and is stated 2990 correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 8.8</a> of <a href="#Part1" id="rfc.xref.Part1.4 3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 9.9</a>)2999 correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 8.8</a> of <a href="#Part1" id="rfc.xref.Part1.44"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 9.9</a>) 2991 3000 </p> 2992 3001 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> … … 3369 3378 <ul> 3370 3379 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/160">http://tools.ietf.org/wg/httpbis/trac/ticket/160</a>>: "Redirects and non-GET methods" 3380 </li> 3381 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/186">http://tools.ietf.org/wg/httpbis/trac/ticket/186</a>>: "Document HTTP's error-handling philosophy" 3371 3382 </li> 3372 3383 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/310">http://tools.ietf.org/wg/httpbis/trac/ticket/310</a>>: "clarify 303 redirect on HEAD" … … 3550 3561 </li> 3551 3562 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3552 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">1.2.1</a>, <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">1.2.1</a>, <a href="#rfc.xref.Part1.8">1.2.1</a>, <a href="#rfc.xref.Part1.9">1.2.2</a>, <a href="#rfc.xref.Part1.10">1.2.2</a>, <a href="#rfc.xref.Part1.11">1.2.2</a>, <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.14">2</a>, <a href="#rfc.xref.Part1.15">2.2.1</a>, <a href="#rfc.xref.Part1.16">3</a>, <a href="#rfc.xref.Part1.17">3.1</a>, <a href="#rfc.xref.Part1.18">3.1</a>, <a href="#rfc.xref.Part1.19">3.1</a>, <a href="#rfc.xref.Part1.20">3.1</a>, <a href="#rfc.xref.Part1.21">3.1</a>, <a href="#rfc.xref.Part1.22">3.2</a>, <a href="#rfc.xref.Part1.23">3.2</a>, <a href="#rfc.xref.Part1.24">3.3</a>, <a href="#rfc.xref.Part1.25">5</a>, <a href="#rfc.xref.Part1.26">5.1</a>, <a href="#rfc.xref.Part1.27">6.8</a>, <a href="#rfc.xref.Part1.28">6.8</a>, <a href="#rfc.xref.Part1.29">6.9</a>, <a href="#rfc.xref.Part1.30">7.1.1</a>, <a href="#rfc.xref.Part1.31">7.1.2</a>, <a href="#rfc.xref.Part1.32">7.2.4</a>, <a href="#rfc.xref.Part1.33">7.2.6</a>, <a href="#rfc.xref.Part1.34">7.4.19</a>, <a href="#rfc.xref.Part1.35">7.5.6</a>, <a href="#rfc.xref.Part1.36">9.3</a>, <a href="#rfc.xref.Part1.37">9.9</a>, <a href="#rfc.xref.Part1.38">9.9</a>, <a href="#rfc.xref.Part1.39">9.9</a>, <a href="#rfc.xref.Part1.40">9.10</a>, <a href="#rfc.xref.Part1.41">9.10</a>, <a href="#rfc.xref.Part1.42">12</a>, <a href="#Part1"><b>13.1</b></a>, <a href="#rfc.xref.Part1.43">A</a><ul> 3553 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.2">1.2</a></li> 3554 <li><em>Section 1.2.1</em> <a href="#rfc.xref.Part1.17">3.1</a></li> 3555 <li><em>Section 1.2.2</em> <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a></li> 3556 <li><em>Section 2.4</em> <a href="#rfc.xref.Part1.32">7.2.4</a></li> 3557 <li><em>Section 2.6</em> <a href="#rfc.xref.Part1.35">7.5.6</a></li> 3558 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.9">1.2.2</a>, <a href="#rfc.xref.Part1.11">1.2.2</a>, <a href="#rfc.xref.Part1.13">1.2.2</a></li> 3559 <li><em>Section 3.1.1.2</em> <a href="#rfc.xref.Part1.29">6.9</a></li> 3560 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.10">1.2.2</a>, <a href="#rfc.xref.Part1.16">3</a>, <a href="#rfc.xref.Part1.19">3.1</a>, <a href="#rfc.xref.Part1.38">9.9</a>, <a href="#rfc.xref.Part1.41">9.10</a></li> 3561 <li><em>Section 3.2.3</em> <a href="#rfc.xref.Part1.7">1.2.1</a>, <a href="#rfc.xref.Part1.8">1.2.1</a>, <a href="#rfc.xref.Part1.18">3.1</a></li> 3562 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.15">2.2.1</a>, <a href="#rfc.xref.Part1.25">5</a>, <a href="#rfc.xref.Part1.33">7.2.6</a></li> 3563 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.14">2</a>, <a href="#rfc.xref.Part1.24">3.3</a>, <a href="#rfc.xref.Part1.26">5.1</a></li> 3564 <li><em>Section 5.1.1</em> <a href="#rfc.xref.Part1.21">3.1</a></li> 3565 <li><em>Section 5.2</em> <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.37">9.9</a>, <a href="#rfc.xref.Part1.40">9.10</a></li> 3566 <li><em>Section 6.2.3</em> <a href="#rfc.xref.Part1.30">7.1.1</a>, <a href="#rfc.xref.Part1.36">9.3</a></li> 3567 <li><em>Section 8.1</em> <a href="#rfc.xref.Part1.20">3.1</a></li> 3568 <li><em>Section 8.3</em> <a href="#rfc.xref.Part1.22">3.2</a></li> 3569 <li><em>Section 8.4</em> <a href="#rfc.xref.Part1.23">3.2</a></li> 3570 <li><em>Section 8.7</em> <a href="#rfc.xref.Part1.31">7.1.2</a>, <a href="#rfc.xref.Part1.34">7.4.19</a></li> 3571 <li><em>Section 8.8</em> <a href="#rfc.xref.Part1.27">6.8</a>, <a href="#rfc.xref.Part1.39">9.9</a>, <a href="#rfc.xref.Part1.43">A</a></li> 3572 <li><em>Section 9.3.1</em> <a href="#rfc.xref.Part1.28">6.8</a></li> 3573 <li><em>Section 11</em> <a href="#rfc.xref.Part1.42">12</a></li> 3563 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">1.2.1</a>, <a href="#rfc.xref.Part1.8">1.2.1</a>, <a href="#rfc.xref.Part1.9">1.2.1</a>, <a href="#rfc.xref.Part1.10">1.2.2</a>, <a href="#rfc.xref.Part1.11">1.2.2</a>, <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.14">1.2.2</a>, <a href="#rfc.xref.Part1.15">2</a>, <a href="#rfc.xref.Part1.16">2.2.1</a>, <a href="#rfc.xref.Part1.17">3</a>, <a href="#rfc.xref.Part1.18">3.1</a>, <a href="#rfc.xref.Part1.19">3.1</a>, <a href="#rfc.xref.Part1.20">3.1</a>, <a href="#rfc.xref.Part1.21">3.1</a>, <a href="#rfc.xref.Part1.22">3.1</a>, <a href="#rfc.xref.Part1.23">3.2</a>, <a href="#rfc.xref.Part1.24">3.2</a>, <a href="#rfc.xref.Part1.25">3.3</a>, <a href="#rfc.xref.Part1.26">5</a>, <a href="#rfc.xref.Part1.27">5.1</a>, <a href="#rfc.xref.Part1.28">6.8</a>, <a href="#rfc.xref.Part1.29">6.8</a>, <a href="#rfc.xref.Part1.30">6.9</a>, <a href="#rfc.xref.Part1.31">7.1.1</a>, <a href="#rfc.xref.Part1.32">7.1.2</a>, <a href="#rfc.xref.Part1.33">7.2.4</a>, <a href="#rfc.xref.Part1.34">7.2.6</a>, <a href="#rfc.xref.Part1.35">7.4.19</a>, <a href="#rfc.xref.Part1.36">7.5.6</a>, <a href="#rfc.xref.Part1.37">9.3</a>, <a href="#rfc.xref.Part1.38">9.9</a>, <a href="#rfc.xref.Part1.39">9.9</a>, <a href="#rfc.xref.Part1.40">9.9</a>, <a href="#rfc.xref.Part1.41">9.10</a>, <a href="#rfc.xref.Part1.42">9.10</a>, <a href="#rfc.xref.Part1.43">12</a>, <a href="#Part1"><b>13.1</b></a>, <a href="#rfc.xref.Part1.44">A</a><ul> 3564 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.3">1.2</a></li> 3565 <li><em>Section 1.2.1</em> <a href="#rfc.xref.Part1.18">3.1</a></li> 3566 <li><em>Section 1.2.2</em> <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">1.2.1</a></li> 3567 <li><em>Section 2</em> <a href="#rfc.xref.Part1.2">1.1</a></li> 3568 <li><em>Section 2.4</em> <a href="#rfc.xref.Part1.33">7.2.4</a></li> 3569 <li><em>Section 2.6</em> <a href="#rfc.xref.Part1.36">7.5.6</a></li> 3570 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.10">1.2.2</a>, <a href="#rfc.xref.Part1.12">1.2.2</a>, <a href="#rfc.xref.Part1.14">1.2.2</a></li> 3571 <li><em>Section 3.1.1.2</em> <a href="#rfc.xref.Part1.30">6.9</a></li> 3572 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.11">1.2.2</a>, <a href="#rfc.xref.Part1.17">3</a>, <a href="#rfc.xref.Part1.20">3.1</a>, <a href="#rfc.xref.Part1.39">9.9</a>, <a href="#rfc.xref.Part1.42">9.10</a></li> 3573 <li><em>Section 3.2.3</em> <a href="#rfc.xref.Part1.8">1.2.1</a>, <a href="#rfc.xref.Part1.9">1.2.1</a>, <a href="#rfc.xref.Part1.19">3.1</a></li> 3574 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.16">2.2.1</a>, <a href="#rfc.xref.Part1.26">5</a>, <a href="#rfc.xref.Part1.34">7.2.6</a></li> 3575 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.15">2</a>, <a href="#rfc.xref.Part1.25">3.3</a>, <a href="#rfc.xref.Part1.27">5.1</a></li> 3576 <li><em>Section 5.1.1</em> <a href="#rfc.xref.Part1.22">3.1</a></li> 3577 <li><em>Section 5.2</em> <a href="#rfc.xref.Part1.13">1.2.2</a>, <a href="#rfc.xref.Part1.38">9.9</a>, <a href="#rfc.xref.Part1.41">9.10</a></li> 3578 <li><em>Section 6.2.3</em> <a href="#rfc.xref.Part1.31">7.1.1</a>, <a href="#rfc.xref.Part1.37">9.3</a></li> 3579 <li><em>Section 8.1</em> <a href="#rfc.xref.Part1.21">3.1</a></li> 3580 <li><em>Section 8.3</em> <a href="#rfc.xref.Part1.23">3.2</a></li> 3581 <li><em>Section 8.4</em> <a href="#rfc.xref.Part1.24">3.2</a></li> 3582 <li><em>Section 8.7</em> <a href="#rfc.xref.Part1.32">7.1.2</a>, <a href="#rfc.xref.Part1.35">7.4.19</a></li> 3583 <li><em>Section 8.8</em> <a href="#rfc.xref.Part1.28">6.8</a>, <a href="#rfc.xref.Part1.40">9.9</a>, <a href="#rfc.xref.Part1.44">A</a></li> 3584 <li><em>Section 9.3.1</em> <a href="#rfc.xref.Part1.29">6.8</a></li> 3585 <li><em>Section 11</em> <a href="#rfc.xref.Part1.43">12</a></li> 3574 3586 </ul> 3575 3587 </li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1451 r1452 16 16 <!ENTITY ID-YEAR "2011"> 17 17 <!ENTITY mdash "—"> 18 <!ENTITY architecture "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 18 19 <!ENTITY notation "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 19 20 <!ENTITY acks "<xref target='Part1' x:rel='#acks' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 25 26 <!ENTITY auth "<xref target='Part7' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 26 27 <!ENTITY content-negotiation "<xref target='Part3' x:rel='#content.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 27 <!ENTITY agent-driven-negotiation 28 <!ENTITY agent-driven-negotiation "<xref target='Part3' x:rel='#agent-driven.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 28 29 <!ENTITY notation-abnf "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 29 30 <!ENTITY basic-rules "<xref target='Part1' x:rel='#basic.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 301 302 </t> 302 303 303 <section title=" Requirements" anchor="intro.requirements">304 <section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling"> 304 305 <t> 305 306 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", … … 308 309 </t> 309 310 <t> 310 An implementation is not compliant if it fails to satisfy one or more 311 of the "MUST" or "REQUIRED" level requirements for the protocols it 312 implements. An implementation that satisfies all the "MUST" or "REQUIRED" 313 level and all the "SHOULD" level requirements for its protocols is said 314 to be "unconditionally compliant"; one that satisfies all the "MUST" 315 level requirements but not all the "SHOULD" level requirements for its 316 protocols is said to be "conditionally compliant". 311 This document defines conformance criteria for several roles in HTTP 312 communication, including Senders, Recipients, Clients, Servers, User-Agents, 313 Origin Servers, Intermediaries, Proxies and Gateways. See &architecture; 314 for definitions of these terms. 315 </t> 316 <t> 317 An implementation is considered conformant if it complies with all of the 318 requirements associated with its role(s). Note that SHOULD-level requirements 319 are relevant here, unless one of the documented exceptions is applicable. 320 </t> 321 <t> 322 This document also uses ABNF to define valid protocol elements 323 (<xref target="notation"/>). In addition to the prose requirements placed 324 upon them, Senders &MUST-NOT; generate protocol elements that are invalid. 325 </t> 326 <t> 327 Unless noted otherwise, Recipients &MAY; take steps to recover a usable 328 protocol element from an invalid construct. However, HTTP does not define 329 specific error handling mechanisms, except in cases where it has direct 330 impact on security. This is because different uses of the protocol require 331 different error handling strategies; for example, a Web browser may wish to 332 transparently recover from a response where the Location header field 333 doesn't parse according to the ABNF, whereby in a systems control protocol 334 using HTTP, this type of error recovery could lead to dangerous consequences. 317 335 </t> 318 336 </section> … … 4641 4659 </t> 4642 4660 <t> 4661 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/186"/>: 4662 "Document HTTP's error-handling philosophy" 4663 </t> 4664 <t> 4643 4665 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/310"/>: 4644 4666 "clarify 303 redirect on HEAD" -
draft-ietf-httpbis/latest/p3-payload.html
r1443 r1452 359 359 } 360 360 @bottom-center { 361 content: "Expires April 4, 2012";361 content: "Expires April 25, 2012"; 362 362 } 363 363 @bottom-right { … … 408 408 <meta name="dct.creator" content="Reschke, J. F."> 409 409 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest"> 410 <meta name="dct.issued" scheme="ISO8601" content="2011-10- 02">410 <meta name="dct.issued" scheme="ISO8601" content="2011-10-23"> 411 411 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 412 412 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 3 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation."> … … 434 434 </tr> 435 435 <tr> 436 <td class="left">Expires: April 4, 2012</td>436 <td class="left">Expires: April 25, 2012</td> 437 437 <td class="right">J. Mogul</td> 438 438 </tr> … … 491 491 <tr> 492 492 <td class="left"></td> 493 <td class="right">October 2 , 2011</td>493 <td class="right">October 23, 2011</td> 494 494 </tr> 495 495 </tbody> … … 519 519 in progress”. 520 520 </p> 521 <p>This Internet-Draft will expire on April 4, 2012.</p>521 <p>This Internet-Draft will expire on April 25, 2012.</p> 522 522 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 523 523 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 539 539 <li>1. <a href="#introduction">Introduction</a><ul> 540 540 <li>1.1 <a href="#terminology">Terminology</a></li> 541 <li>1.2 <a href="#intro. requirements">Requirements</a></li>541 <li>1.2 <a href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></li> 542 542 <li>1.3 <a href="#notation">Syntax Notation</a><ul> 543 543 <li>1.3.1 <a href="#core.rules">Core Rules</a></li> … … 659 659 </li> 660 660 </ul> 661 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="intro. requirements" href="#intro.requirements">Requirements</a></h2>661 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="intro.conformance.and.error.handling" href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></h2> 662 662 <p id="rfc.section.1.2.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 663 663 in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>. 664 664 </p> 665 <p id="rfc.section.1.2.p.2">An implementation is not compliant if it fails to satisfy one or more of the "MUST" or "REQUIRED" level requirements for the 666 protocols it implements. An implementation that satisfies all the "MUST" or "REQUIRED" level and all the "SHOULD" level requirements 667 for its protocols is said to be "unconditionally compliant"; one that satisfies all the "MUST" level requirements but not 668 all the "SHOULD" level requirements for its protocols is said to be "conditionally compliant". 665 <p id="rfc.section.1.2.p.2">This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients, 666 Servers, User-Agents, Origin Servers, Intermediaries, Proxies and Gateways. See <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for definitions of these terms. 667 </p> 668 <p id="rfc.section.1.2.p.3">An implementation is considered conformant if it complies with all of the requirements associated with its role(s). Note that 669 SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable. 670 </p> 671 <p id="rfc.section.1.2.p.4">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section 1.3</a>). In addition to the prose requirements placed upon them, Senders <em class="bcp14">MUST NOT</em> generate protocol elements that are invalid. 672 </p> 673 <p id="rfc.section.1.2.p.5">Unless noted otherwise, Recipients <em class="bcp14">MAY</em> take steps to recover a usable protocol element from an invalid construct. However, HTTP does not define specific error handling 674 mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require 675 different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the 676 Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of 677 error recovery could lead to dangerous consequences. 669 678 </p> 670 679 <h2 id="rfc.section.1.3"><a href="#rfc.section.1.3">1.3</a> <a id="notation" href="#notation">Syntax Notation</a></h2> 671 <p id="rfc.section.1.3.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1. 1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> (which extends the syntax defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list rule). <a href="#collected.abnf" title="Collected ABNF">Appendix D</a> shows the collected ABNF, with the list rule expanded.680 <p id="rfc.section.1.3.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> (which extends the syntax defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list rule). <a href="#collected.abnf" title="Collected ABNF">Appendix D</a> shows the collected ABNF, with the list rule expanded. 672 681 </p> 673 682 <p id="rfc.section.1.3.p.2">The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG … … 676 685 </p> 677 686 <h3 id="rfc.section.1.3.1"><a href="#rfc.section.1.3.1">1.3.1</a> <a id="core.rules" href="#core.rules">Core Rules</a></h3> 678 <p id="rfc.section.1.3.1.p.1">The core rules below are defined in <a href="#Part1" id="rfc.xref.Part1. 2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>:679 </p> 680 <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#core.rules" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1. 3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>>681 <a href="#core.rules" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1. 4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>>682 <a href="#core.rules" class="smpl">word</a> = <word, defined in <a href="#Part1" id="rfc.xref.Part1. 5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>>687 <p id="rfc.section.1.3.1.p.1">The core rules below are defined in <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>: 688 </p> 689 <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#core.rules" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>> 690 <a href="#core.rules" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>> 691 <a href="#core.rules" class="smpl">word</a> = <word, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>> 683 692 </pre><h3 id="rfc.section.1.3.2"><a href="#rfc.section.1.3.2">1.3.2</a> <a id="abnf.dependencies" href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></h3> 684 693 <p id="rfc.section.1.3.2.p.1">The ABNF rules below are defined in other parts:</p> 685 <div id="rfc.figure.u.2"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">absolute-URI</a> = <absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1. 6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>>686 <a href="#abnf.dependencies" class="smpl">partial-URI</a> = <partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1. 7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>>687 <a href="#abnf.dependencies" class="smpl">qvalue</a> = <qvalue, defined in <a href="#Part1" id="rfc.xref.Part1. 8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#quality.values" title="Quality Values">Section 5.3</a>>694 <div id="rfc.figure.u.2"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">absolute-URI</a> = <absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 695 <a href="#abnf.dependencies" class="smpl">partial-URI</a> = <partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 696 <a href="#abnf.dependencies" class="smpl">qvalue</a> = <qvalue, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#quality.values" title="Quality Values">Section 5.3</a>> 688 697 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1> 689 698 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> <a id="character.sets" href="#character.sets">Character Encodings (charset)</a></h2> … … 717 726 </p> 718 727 <ul class="empty"> 719 <li>See <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 5.1.2.1</a> of <a href="#Part1" id="rfc.xref.Part1. 9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.728 <li>See <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 5.1.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 720 729 </li> 721 730 </ul> … … 723 732 </p> 724 733 <ul class="empty"> 725 <li>See <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 5.1.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.1 0"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.734 <li>See <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 5.1.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 726 735 </li> 727 736 </ul> … … 729 738 </p> 730 739 <ul class="empty"> 731 <li>See <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 5.1.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.1 1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.740 <li>See <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 5.1.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 732 741 </li> 733 742 </ul> … … 741 750 <li>Pointer to specification text</li> 742 751 </ul> 743 <p id="rfc.section.2.2.1.p.3">Names of content codings <em class="bcp14">MUST NOT</em> overlap with names of transfer codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 5.1</a> of <a href="#Part1" id="rfc.xref.Part1.1 2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), unless the encoding transformation is identical (as it is the case for the compression codings defined in <a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 5.1.2</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).752 <p id="rfc.section.2.2.1.p.3">Names of content codings <em class="bcp14">MUST NOT</em> overlap with names of transfer codings (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 5.1</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), unless the encoding transformation is identical (as it is the case for the compression codings defined in <a href="p1-messaging.html#compression.codings" title="Compression Codings">Section 5.1.2</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 744 753 </p> 745 754 <p id="rfc.section.2.2.1.p.4">Values to be added to this name space require a specification (see "Specification Required" in <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of content coding defined in this section. … … 841 850 <tr> 842 851 <td class="left">Content-Length</td> 843 <td class="left"><a href="p1-messaging.html#header.content-length" title="Content-Length">Section 8.2</a> of <a href="#Part1" id="rfc.xref.Part1.1 4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>852 <td class="left"><a href="p1-messaging.html#header.content-length" title="Content-Length">Section 8.2</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td> 844 853 </tr> 845 854 <tr> … … 851 860 </div> 852 861 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="payload.body" href="#payload.body">Payload Body</a></h2> 853 <p id="rfc.section.3.2.p.1">A payload body is only present in a message when a message-body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.1 5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The payload body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied to ensure862 <p id="rfc.section.3.2.p.1">A payload body is only present in a message when a message-body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The payload body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied to ensure 854 863 safe and proper transfer of the message. 855 864 </p> … … 987 996 that doesn't conform to them is better than sending a 406 (Not Acceptable) response. 988 997 </p> 989 <p id="rfc.section.5.1.p.5">Many of the mechanisms for expressing preferences use quality values to declare relative preference. See <a href="p1-messaging.html#quality.values" title="Quality Values">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.1 6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for more information.998 <p id="rfc.section.5.1.p.5">Many of the mechanisms for expressing preferences use quality values to declare relative preference. See <a href="p1-messaging.html#quality.values" title="Quality Values">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for more information. 990 999 </p> 991 1000 <p id="rfc.section.5.1.p.6">HTTP/1.1 includes the following header fields for enabling server-driven negotiation through description of user agent capabilities … … 1040 1049 <p id="rfc.section.6.1.p.4">Each media-range <em class="bcp14">MAY</em> be followed by one or more accept-params, beginning with the "q" parameter for indicating a relative quality factor. The first 1041 1050 "q" parameter (if any) separates the media-range parameter(s) from the accept-params. Quality factors allow the user or user 1042 agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (<a href="p1-messaging.html#quality.values" title="Quality Values">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.1 7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The default value is q=1.1051 agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (<a href="p1-messaging.html#quality.values" title="Quality Values">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The default value is q=1. 1043 1052 </p> 1044 1053 <div class="note" id="rfc.section.6.1.p.5"> … … 1170 1179 </li> 1171 1180 <li>If the representation's content-coding is one of the content-codings listed in the Accept-Encoding field, then it is acceptable 1172 unless it is accompanied by a qvalue of 0. (As defined in <a href="p1-messaging.html#quality.values" title="Quality Values">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.1 8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, a qvalue of 0 means "not acceptable".)1181 unless it is accompanied by a qvalue of 0. (As defined in <a href="p1-messaging.html#quality.values" title="Quality Values">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, a qvalue of 0 means "not acceptable".) 1173 1182 </li> 1174 1183 <li>If multiple content-codings are acceptable, then the acceptable content-coding with the highest non-zero qvalue is preferred.</li> … … 1284 1293 </p> 1285 1294 <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.22"></span> <a href="#header.content-location" class="smpl">Content-Location</a> = <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a> 1286 </pre><p id="rfc.section.6.7.p.3">The Content-Location value is not a replacement for the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1. 19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME1295 </pre><p id="rfc.section.6.7.p.3">The Content-Location value is not a replacement for the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME 1287 1296 body parts in <a href="http://tools.ietf.org/html/rfc2557#section-4">Section 4</a> of <a href="#RFC2557" id="rfc.xref.RFC2557.1"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a>. However, its appearance in an HTTP message has some special implications for HTTP recipients. 1288 1297 </p> … … 1432 1441 <td class="left">compress</td> 1433 1442 <td class="left">UNIX "compress" program method</td> 1434 <td class="left"> <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 5.1.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.2 0"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>1443 <td class="left"> <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 5.1.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> 1435 1444 </td> 1436 1445 </tr> … … 1439 1448 <td class="left">"deflate" compression mechanism (<a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>) used inside the "zlib" data format (<a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a>) 1440 1449 </td> 1441 <td class="left"> <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 5.1.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.2 1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>1450 <td class="left"> <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 5.1.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> 1442 1451 </td> 1443 1452 </tr> … … 1445 1454 <td class="left">gzip</td> 1446 1455 <td class="left">Same as GNU zip <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a></td> 1447 <td class="left"> <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 5.1.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.2 2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>1456 <td class="left"> <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 5.1.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> 1448 1457 </td> 1449 1458 </tr> … … 1482 1491 </p> 1483 1492 <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a id="acks" href="#acks">Acknowledgments</a></h1> 1484 <p id="rfc.section.9.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 11</a> of <a href="#Part1" id="rfc.xref.Part1.2 3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.1493 <p id="rfc.section.9.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 11</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 1485 1494 </p> 1486 1495 <h1 id="rfc.references"><a id="rfc.section.10" href="#rfc.section.10">10.</a> References … … 1720 1729 </p> 1721 1730 <h2 id="rfc.section.A.6"><a href="#rfc.section.A.6">A.6</a> <a id="introduction.of.transfer-encoding" href="#introduction.of.transfer-encoding">Introduction of Transfer-Encoding</a></h2> 1722 <p id="rfc.section.A.6.p.1">HTTP/1.1 introduces the Transfer-Encoding header field (<a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 8.6</a> of <a href="#Part1" id="rfc.xref.Part1.2 4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Proxies/gateways <em class="bcp14">MUST</em> remove any transfer-coding prior to forwarding a message via a MIME-compliant protocol.1731 <p id="rfc.section.A.6.p.1">HTTP/1.1 introduces the Transfer-Encoding header field (<a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 8.6</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Proxies/gateways <em class="bcp14">MUST</em> remove any transfer-coding prior to forwarding a message via a MIME-compliant protocol. 1723 1732 </p> 1724 1733 <h2 id="rfc.section.A.7"><a href="#rfc.section.A.7">A.7</a> <a id="mhtml.line.length" href="#mhtml.line.length">MHTML and Line Length Limitations</a></h2> … … 2032 2041 </ul> 2033 2042 <h2 id="rfc.section.E.18"><a href="#rfc.section.E.18">E.18</a> <a id="changes.since.16" href="#changes.since.16">Since draft-ietf-httpbis-p3-payload-16</a></h2> 2034 <p id="rfc.section.E.18.p.1">None yet.</p> 2043 <p id="rfc.section.E.18.p.1">Closed issues: </p> 2044 <ul> 2045 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/186">http://tools.ietf.org/wg/httpbis/trac/ticket/186</a>>: "Document HTTP's error-handling philosophy" 2046 </li> 2047 </ul> 2035 2048 <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> 2036 2049 <p class="noprint"><a href="#rfc.index.A">A</a> <a href="#rfc.index.B">B</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.D">D</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> … … 2121 2134 </li> 2122 2135 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 2123 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1.3</a>, <a href="#rfc.xref.Part1.2">1.3.1</a>, <a href="#rfc.xref.Part1.3">1.3.1</a>, <a href="#rfc.xref.Part1.4">1.3.1</a>, <a href="#rfc.xref.Part1.5">1.3.1</a>, <a href="#rfc.xref.Part1.6">1.3.2</a>, <a href="#rfc.xref.Part1.7">1.3.2</a>, <a href="#rfc.xref.Part1.8">1.3.2</a>, <a href="#rfc.xref.Part1.9">2.2</a>, <a href="#rfc.xref.Part1.10">2.2</a>, <a href="#rfc.xref.Part1.11">2.2</a>, <a href="#rfc.xref.Part1.12">2.2.1</a>, <a href="#rfc.xref.Part1.13">2.2.1</a>, <a href="#rfc.xref.Part1.14">3.1</a>, <a href="#rfc.xref.Part1.15">3.2</a>, <a href="#rfc.xref.Part1.16">5.1</a>, <a href="#rfc.xref.Part1.17">6.1</a>, <a href="#rfc.xref.Part1.18">6.3</a>, <a href="#rfc.xref.Part1.19">6.7</a>, <a href="#rfc.xref.Part1.20">7.2</a>, <a href="#rfc.xref.Part1.21">7.2</a>, <a href="#rfc.xref.Part1.22">7.2</a>, <a href="#rfc.xref.Part1.23">9</a>, <a href="#Part1"><b>10.1</b></a>, <a href="#rfc.xref.Part1.24">A.6</a><ul> 2124 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.1">1.3</a></li> 2125 <li><em>Section 1.2.2</em> <a href="#rfc.xref.Part1.3">1.3.1</a></li> 2126 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.6">1.3.2</a>, <a href="#rfc.xref.Part1.7">1.3.2</a></li> 2127 <li><em>Section 3.2.3</em> <a href="#rfc.xref.Part1.4">1.3.1</a>, <a href="#rfc.xref.Part1.5">1.3.1</a></li> 2128 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.15">3.2</a></li> 2129 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.19">6.7</a></li> 2130 <li><em>Section 5.1</em> <a href="#rfc.xref.Part1.12">2.2.1</a></li> 2131 <li><em>Section 5.1.2.1</em> <a href="#rfc.xref.Part1.9">2.2</a>, <a href="#rfc.xref.Part1.20">7.2</a></li> 2132 <li><em>Section 5.1.2</em> <a href="#rfc.xref.Part1.13">2.2.1</a></li> 2133 <li><em>Section 5.1.2.2</em> <a href="#rfc.xref.Part1.10">2.2</a>, <a href="#rfc.xref.Part1.21">7.2</a></li> 2134 <li><em>Section 5.1.2.3</em> <a href="#rfc.xref.Part1.11">2.2</a>, <a href="#rfc.xref.Part1.22">7.2</a></li> 2135 <li><em>Section 5.3</em> <a href="#rfc.xref.Part1.8">1.3.2</a>, <a href="#rfc.xref.Part1.16">5.1</a>, <a href="#rfc.xref.Part1.17">6.1</a>, <a href="#rfc.xref.Part1.18">6.3</a></li> 2136 <li><em>Section 8.2</em> <a href="#rfc.xref.Part1.14">3.1</a></li> 2137 <li><em>Section 8.6</em> <a href="#rfc.xref.Part1.24">A.6</a></li> 2138 <li><em>Section 11</em> <a href="#rfc.xref.Part1.23">9</a></li> 2136 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1.2</a>, <a href="#rfc.xref.Part1.2">1.3</a>, <a href="#rfc.xref.Part1.3">1.3.1</a>, <a href="#rfc.xref.Part1.4">1.3.1</a>, <a href="#rfc.xref.Part1.5">1.3.1</a>, <a href="#rfc.xref.Part1.6">1.3.1</a>, <a href="#rfc.xref.Part1.7">1.3.2</a>, <a href="#rfc.xref.Part1.8">1.3.2</a>, <a href="#rfc.xref.Part1.9">1.3.2</a>, <a href="#rfc.xref.Part1.10">2.2</a>, <a href="#rfc.xref.Part1.11">2.2</a>, <a href="#rfc.xref.Part1.12">2.2</a>, <a href="#rfc.xref.Part1.13">2.2.1</a>, <a href="#rfc.xref.Part1.14">2.2.1</a>, <a href="#rfc.xref.Part1.15">3.1</a>, <a href="#rfc.xref.Part1.16">3.2</a>, <a href="#rfc.xref.Part1.17">5.1</a>, <a href="#rfc.xref.Part1.18">6.1</a>, <a href="#rfc.xref.Part1.19">6.3</a>, <a href="#rfc.xref.Part1.20">6.7</a>, <a href="#rfc.xref.Part1.21">7.2</a>, <a href="#rfc.xref.Part1.22">7.2</a>, <a href="#rfc.xref.Part1.23">7.2</a>, <a href="#rfc.xref.Part1.24">9</a>, <a href="#Part1"><b>10.1</b></a>, <a href="#rfc.xref.Part1.25">A.6</a><ul> 2137 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.2">1.3</a></li> 2138 <li><em>Section 1.2.2</em> <a href="#rfc.xref.Part1.4">1.3.1</a></li> 2139 <li><em>Section 2</em> <a href="#rfc.xref.Part1.1">1.2</a></li> 2140 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.7">1.3.2</a>, <a href="#rfc.xref.Part1.8">1.3.2</a></li> 2141 <li><em>Section 3.2.3</em> <a href="#rfc.xref.Part1.5">1.3.1</a>, <a href="#rfc.xref.Part1.6">1.3.1</a></li> 2142 <li><em>Section 3.3</em> <a href="#rfc.xref.Part1.16">3.2</a></li> 2143 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.20">6.7</a></li> 2144 <li><em>Section 5.1</em> <a href="#rfc.xref.Part1.13">2.2.1</a></li> 2145 <li><em>Section 5.1.2.1</em> <a href="#rfc.xref.Part1.10">2.2</a>, <a href="#rfc.xref.Part1.21">7.2</a></li> 2146 <li><em>Section 5.1.2</em> <a href="#rfc.xref.Part1.14">2.2.1</a></li> 2147 <li><em>Section 5.1.2.2</em> <a href="#rfc.xref.Part1.11">2.2</a>, <a href="#rfc.xref.Part1.22">7.2</a></li> 2148 <li><em>Section 5.1.2.3</em> <a href="#rfc.xref.Part1.12">2.2</a>, <a href="#rfc.xref.Part1.23">7.2</a></li> 2149 <li><em>Section 5.3</em> <a href="#rfc.xref.Part1.9">1.3.2</a>, <a href="#rfc.xref.Part1.17">5.1</a>, <a href="#rfc.xref.Part1.18">6.1</a>, <a href="#rfc.xref.Part1.19">6.3</a></li> 2150 <li><em>Section 8.2</em> <a href="#rfc.xref.Part1.15">3.1</a></li> 2151 <li><em>Section 8.6</em> <a href="#rfc.xref.Part1.25">A.6</a></li> 2152 <li><em>Section 11</em> <a href="#rfc.xref.Part1.24">9</a></li> 2139 2153 </ul> 2140 2154 </li> -
draft-ietf-httpbis/latest/p3-payload.xml
r1443 r1452 16 16 <!ENTITY ID-YEAR "2011"> 17 17 <!ENTITY mdash "—"> 18 <!ENTITY architecture "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 18 19 <!ENTITY notation "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 19 20 <!ENTITY notation-abnf "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 267 268 </section> 268 269 269 <section title=" Requirements" anchor="intro.requirements">270 <section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling"> 270 271 <t> 271 272 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", … … 274 275 </t> 275 276 <t> 276 An implementation is not compliant if it fails to satisfy one or more 277 of the "MUST" or "REQUIRED" level requirements for the protocols it 278 implements. An implementation that satisfies all the "MUST" or "REQUIRED" 279 level and all the "SHOULD" level requirements for its protocols is said 280 to be "unconditionally compliant"; one that satisfies all the "MUST" 281 level requirements but not all the "SHOULD" level requirements for its 282 protocols is said to be "conditionally compliant". 277 This document defines conformance criteria for several roles in HTTP 278 communication, including Senders, Recipients, Clients, Servers, User-Agents, 279 Origin Servers, Intermediaries, Proxies and Gateways. See &architecture; 280 for definitions of these terms. 281 </t> 282 <t> 283 An implementation is considered conformant if it complies with all of the 284 requirements associated with its role(s). Note that SHOULD-level requirements 285 are relevant here, unless one of the documented exceptions is applicable. 286 </t> 287 <t> 288 This document also uses ABNF to define valid protocol elements 289 (<xref target="notation"/>). In addition to the prose requirements placed 290 upon them, Senders &MUST-NOT; generate protocol elements that are invalid. 291 </t> 292 <t> 293 Unless noted otherwise, Recipients &MAY; take steps to recover a usable 294 protocol element from an invalid construct. However, HTTP does not define 295 specific error handling mechanisms, except in cases where it has direct 296 impact on security. This is because different uses of the protocol require 297 different error handling strategies; for example, a Web browser may wish to 298 transparently recover from a response where the Location header field 299 doesn't parse according to the ABNF, whereby in a systems control protocol 300 using HTTP, this type of error recovery could lead to dangerous consequences. 283 301 </t> 284 302 </section> … … 3035 3053 <section title="Since draft-ietf-httpbis-p3-payload-16" anchor="changes.since.16"> 3036 3054 <t> 3037 None yet. 3055 Closed issues: 3056 <list style="symbols"> 3057 <t> 3058 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/186"/>: 3059 "Document HTTP's error-handling philosophy" 3060 </t> 3061 </list> 3038 3062 </t> 3039 3063 </section> -
draft-ietf-httpbis/latest/p4-conditional.html
r1443 r1452 359 359 } 360 360 @bottom-center { 361 content: "Expires April 4, 2012";361 content: "Expires April 25, 2012"; 362 362 } 363 363 @bottom-right { … … 404 404 <meta name="dct.creator" content="Reschke, J. F."> 405 405 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest"> 406 <meta name="dct.issued" scheme="ISO8601" content="2011-10- 02">406 <meta name="dct.issued" scheme="ISO8601" content="2011-10-23"> 407 407 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 408 408 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests."> … … 430 430 </tr> 431 431 <tr> 432 <td class="left">Expires: April 4, 2012</td>432 <td class="left">Expires: April 25, 2012</td> 433 433 <td class="right">J. Mogul</td> 434 434 </tr> … … 487 487 <tr> 488 488 <td class="left"></td> 489 <td class="right">October 2 , 2011</td>489 <td class="right">October 23, 2011</td> 490 490 </tr> 491 491 </tbody> … … 517 517 in progress”. 518 518 </p> 519 <p>This Internet-Draft will expire on April 4, 2012.</p>519 <p>This Internet-Draft will expire on April 25, 2012.</p> 520 520 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 521 521 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 536 536 <ul class="toc"> 537 537 <li>1. <a href="#introduction">Introduction</a><ul> 538 <li>1.1 <a href="#intro. requirements">Requirements</a></li>538 <li>1.1 <a href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></li> 539 539 <li>1.2 <a href="#notation">Syntax Notation</a></li> 540 540 </ul> … … 625 625 selected representation. 626 626 </p> 627 <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="intro. requirements" href="#intro.requirements">Requirements</a></h2>627 <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="intro.conformance.and.error.handling" href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></h2> 628 628 <p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 629 629 in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>. 630 630 </p> 631 <p id="rfc.section.1.1.p.2">An implementation is not compliant if it fails to satisfy one or more of the "MUST" or "REQUIRED" level requirements for the 632 protocols it implements. An implementation that satisfies all the "MUST" or "REQUIRED" level and all the "SHOULD" level requirements 633 for its protocols is said to be "unconditionally compliant"; one that satisfies all the "MUST" level requirements but not 634 all the "SHOULD" level requirements for its protocols is said to be "conditionally compliant". 631 <p id="rfc.section.1.1.p.2">This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients, 632 Servers, User-Agents, Origin Servers, Intermediaries, Proxies and Gateways. See <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for definitions of these terms. 633 </p> 634 <p id="rfc.section.1.1.p.3">An implementation is considered conformant if it complies with all of the requirements associated with its role(s). Note that 635 SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable. 636 </p> 637 <p id="rfc.section.1.1.p.4">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section 1.2</a>). In addition to the prose requirements placed upon them, Senders <em class="bcp14">MUST NOT</em> generate protocol elements that are invalid. 638 </p> 639 <p id="rfc.section.1.1.p.5">Unless noted otherwise, Recipients <em class="bcp14">MAY</em> take steps to recover a usable protocol element from an invalid construct. However, HTTP does not define specific error handling 640 mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require 641 different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the 642 Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of 643 error recovery could lead to dangerous consequences. 635 644 </p> 636 645 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="notation" href="#notation">Syntax Notation</a></h2> 637 <p id="rfc.section.1.2.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1. 1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> (which extends the syntax defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list rule). <a href="#collected.abnf" title="Collected ABNF">Appendix B</a> shows the collected ABNF, with the list rule expanded.646 <p id="rfc.section.1.2.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> (which extends the syntax defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list rule). <a href="#collected.abnf" title="Collected ABNF">Appendix B</a> shows the collected ABNF, with the list rule expanded. 638 647 </p> 639 648 <p id="rfc.section.1.2.p.2">The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG … … 641 650 character). 642 651 </p> 643 <p id="rfc.section.1.2.p.3">The ABNF rules below are defined in <a href="#Part1" id="rfc.xref.Part1. 2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> and <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>:644 </p> 645 <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#notation" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1. 3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>>646 <a href="#notation" class="smpl">quoted-string</a> = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1. 4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>>652 <p id="rfc.section.1.2.p.3">The ABNF rules below are defined in <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> and <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>: 653 </p> 654 <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#notation" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>> 655 <a href="#notation" class="smpl">quoted-string</a> = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>> 647 656 <a href="#notation" class="smpl">HTTP-date</a> = <HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 8</a>> 648 657 </pre><div id="rfc.iref.m.1"></div> … … 882 891 <p> <b>Note:</b> Content codings are a property of the representation, so therefore an entity-tag of an encoded representation must be distinct 883 892 from an unencoded representation to prevent conflicts during cache updates and range requests. In contrast, transfer codings 884 (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 5.1</a> of <a href="#Part1" id="rfc.xref.Part1. 5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) apply only during message transfer and do not require distinct entity-tags.893 (<a href="p1-messaging.html#transfer.codings" title="Transfer Codings">Section 5.1</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) apply only during message transfer and do not require distinct entity-tags. 885 894 </p> 886 895 </div> … … 1188 1197 <p id="rfc.section.5.2.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p> 1189 1198 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1> 1190 <p id="rfc.section.6.p.1">No additional security considerations have been identified beyond those applicable to HTTP in general <a href="#Part1" id="rfc.xref.Part1. 6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.1199 <p id="rfc.section.6.p.1">No additional security considerations have been identified beyond those applicable to HTTP in general <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 1191 1200 </p> 1192 1201 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="acks" href="#acks">Acknowledgments</a></h1> 1193 <p id="rfc.section.7.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 11</a> of <a href="#Part1" id="rfc.xref.Part1. 7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.1202 <p id="rfc.section.7.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 11</a> of <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 1194 1203 </p> 1195 1204 <h1 id="rfc.references"><a id="rfc.section.8" href="#rfc.section.8">8.</a> References … … 1421 1430 </ul> 1422 1431 <h2 id="rfc.section.C.18"><a href="#rfc.section.C.18">C.18</a> <a id="changes.since.16" href="#changes.since.16">Since draft-ietf-httpbis-p4-conditional-16</a></h2> 1423 <p id="rfc.section.C.18.p.1">None yet.</p> 1432 <p id="rfc.section.C.18.p.1">Closed issues: </p> 1433 <ul> 1434 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/186">http://tools.ietf.org/wg/httpbis/trac/ticket/186</a>>: "Document HTTP's error-handling philosophy" 1435 </li> 1436 </ul> 1424 1437 <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> 1425 1438 <p class="noprint"><a href="#rfc.index.3">3</a> <a href="#rfc.index.4">4</a> <a href="#rfc.index.E">E</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.L">L</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.V">V</a> … … 1484 1497 </li> 1485 1498 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 1486 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1.2</a>, <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">1.2</a>, <a href="#rfc.xref.Part1.5">2.3.3</a>, <a href="#rfc.xref.Part1.6">6</a>, <a href="#rfc.xref.Part1.7">7</a>, <a href="#Part1"><b>8.1</b></a><ul> 1487 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.1">1.2</a></li> 1488 <li><em>Section 1.2.2</em> <a href="#rfc.xref.Part1.3">1.2</a></li> 1489 <li><em>Section 3.2.3</em> <a href="#rfc.xref.Part1.4">1.2</a></li> 1490 <li><em>Section 5.1</em> <a href="#rfc.xref.Part1.5">2.3.3</a></li> 1491 <li><em>Section 11</em> <a href="#rfc.xref.Part1.7">7</a></li> 1499 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1.1</a>, <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">1.2</a>, <a href="#rfc.xref.Part1.5">1.2</a>, <a href="#rfc.xref.Part1.6">2.3.3</a>, <a href="#rfc.xref.Part1.7">6</a>, <a href="#rfc.xref.Part1.8">7</a>, <a href="#Part1"><b>8.1</b></a><ul> 1500 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.2">1.2</a></li> 1501 <li><em>Section 1.2.2</em> <a href="#rfc.xref.Part1.4">1.2</a></li> 1502 <li><em>Section 2</em> <a href="#rfc.xref.Part1.1">1.1</a></li> 1503 <li><em>Section 3.2.3</em> <a href="#rfc.xref.Part1.5">1.2</a></li> 1504 <li><em>Section 5.1</em> <a href="#rfc.xref.Part1.6">2.3.3</a></li> 1505 <li><em>Section 11</em> <a href="#rfc.xref.Part1.8">7</a></li> 1492 1506 </ul> 1493 1507 </li> -
draft-ietf-httpbis/latest/p4-conditional.xml
r1443 r1452 15 15 <!ENTITY ID-MONTH "October"> 16 16 <!ENTITY ID-YEAR "2011"> 17 <!ENTITY architecture "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 17 18 <!ENTITY notation "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 18 19 <!ENTITY notation-abnf "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 254 255 </t> 255 256 256 <section title=" Requirements" anchor="intro.requirements">257 <section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling"> 257 258 <t> 258 259 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", … … 261 262 </t> 262 263 <t> 263 An implementation is not compliant if it fails to satisfy one or more 264 of the "MUST" or "REQUIRED" level requirements for the protocols it 265 implements. An implementation that satisfies all the "MUST" or "REQUIRED" 266 level and all the "SHOULD" level requirements for its protocols is said 267 to be "unconditionally compliant"; one that satisfies all the "MUST" 268 level requirements but not all the "SHOULD" level requirements for its 269 protocols is said to be "conditionally compliant". 264 This document defines conformance criteria for several roles in HTTP 265 communication, including Senders, Recipients, Clients, Servers, User-Agents, 266 Origin Servers, Intermediaries, Proxies and Gateways. See &architecture; 267 for definitions of these terms. 268 </t> 269 <t> 270 An implementation is considered conformant if it complies with all of the 271 requirements associated with its role(s). Note that SHOULD-level requirements 272 are relevant here, unless one of the documented exceptions is applicable. 273 </t> 274 <t> 275 This document also uses ABNF to define valid protocol elements 276 (<xref target="notation"/>). In addition to the prose requirements placed 277 upon them, Senders &MUST-NOT; generate protocol elements that are invalid. 278 </t> 279 <t> 280 Unless noted otherwise, Recipients &MAY; take steps to recover a usable 281 protocol element from an invalid construct. However, HTTP does not define 282 specific error handling mechanisms, except in cases where it has direct 283 impact on security. This is because different uses of the protocol require 284 different error handling strategies; for example, a Web browser may wish to 285 transparently recover from a response where the Location header field 286 doesn't parse according to the ABNF, whereby in a systems control protocol 287 using HTTP, this type of error recovery could lead to dangerous consequences. 270 288 </t> 271 289 </section> … … 1825 1843 <section title="Since draft-ietf-httpbis-p4-conditional-16" anchor="changes.since.16"> 1826 1844 <t> 1827 None yet. 1845 Closed issues: 1846 <list style="symbols"> 1847 <t> 1848 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/186"/>: 1849 "Document HTTP's error-handling philosophy" 1850 </t> 1851 </list> 1828 1852 </t> 1829 1853 </section> -
draft-ietf-httpbis/latest/p5-range.html
r1443 r1452 359 359 } 360 360 @bottom-center { 361 content: "Expires April 4, 2012";361 content: "Expires April 25, 2012"; 362 362 } 363 363 @bottom-right { … … 406 406 <meta name="dct.creator" content="Reschke, J. F."> 407 407 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest"> 408 <meta name="dct.issued" scheme="ISO8601" content="2011-10- 02">408 <meta name="dct.issued" scheme="ISO8601" content="2011-10-23"> 409 409 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 410 410 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 5 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests."> … … 432 432 </tr> 433 433 <tr> 434 <td class="left">Expires: April 4, 2012</td>434 <td class="left">Expires: April 25, 2012</td> 435 435 <td class="right">J. Mogul</td> 436 436 </tr> … … 489 489 <tr> 490 490 <td class="left"></td> 491 <td class="right">October 2 , 2011</td>491 <td class="right">October 23, 2011</td> 492 492 </tr> 493 493 </tbody> … … 517 517 in progress”. 518 518 </p> 519 <p>This Internet-Draft will expire on April 4, 2012.</p>519 <p>This Internet-Draft will expire on April 25, 2012.</p> 520 520 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 521 521 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 536 536 <ul class="toc"> 537 537 <li>1. <a href="#introduction">Introduction</a><ul> 538 <li>1.1 <a href="#intro. requirements">Requirements</a></li>538 <li>1.1 <a href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></li> 539 539 <li>1.2 <a href="#notation">Syntax Notation</a><ul> 540 540 <li>1.2.1 <a href="#core.rules">Core Rules</a></li> … … 626 626 requests for byte ranges. 627 627 </p> 628 <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="intro. requirements" href="#intro.requirements">Requirements</a></h2>628 <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="intro.conformance.and.error.handling" href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></h2> 629 629 <p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 630 630 in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>. 631 631 </p> 632 <p id="rfc.section.1.1.p.2">An implementation is not compliant if it fails to satisfy one or more of the "MUST" or "REQUIRED" level requirements for the 633 protocols it implements. An implementation that satisfies all the "MUST" or "REQUIRED" level and all the "SHOULD" level requirements 634 for its protocols is said to be "unconditionally compliant"; one that satisfies all the "MUST" level requirements but not 635 all the "SHOULD" level requirements for its protocols is said to be "conditionally compliant". 632 <p id="rfc.section.1.1.p.2">This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients, 633 Servers, User-Agents, Origin Servers, Intermediaries, Proxies and Gateways. See <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for definitions of these terms. 634 </p> 635 <p id="rfc.section.1.1.p.3">An implementation is considered conformant if it complies with all of the requirements associated with its role(s). Note that 636 SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable. 637 </p> 638 <p id="rfc.section.1.1.p.4">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section 1.2</a>). In addition to the prose requirements placed upon them, Senders <em class="bcp14">MUST NOT</em> generate protocol elements that are invalid. 639 </p> 640 <p id="rfc.section.1.1.p.5">Unless noted otherwise, Recipients <em class="bcp14">MAY</em> take steps to recover a usable protocol element from an invalid construct. However, HTTP does not define specific error handling 641 mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require 642 different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the 643 Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of 644 error recovery could lead to dangerous consequences. 636 645 </p> 637 646 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="notation" href="#notation">Syntax Notation</a></h2> 638 <p id="rfc.section.1.2.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1. 1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> (which extends the syntax defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list rule). <a href="#collected.abnf" title="Collected ABNF">Appendix C</a> shows the collected ABNF, with the list rule expanded.647 <p id="rfc.section.1.2.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> (which extends the syntax defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list rule). <a href="#collected.abnf" title="Collected ABNF">Appendix C</a> shows the collected ABNF, with the list rule expanded. 639 648 </p> 640 649 <p id="rfc.section.1.2.p.2">The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG … … 643 652 </p> 644 653 <h3 id="rfc.section.1.2.1"><a href="#rfc.section.1.2.1">1.2.1</a> <a id="core.rules" href="#core.rules">Core Rules</a></h3> 645 <p id="rfc.section.1.2.1.p.1">The core rules below are defined in <a href="#Part1" id="rfc.xref.Part1. 2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> and <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>:646 </p> 647 <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#core.rules" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1. 3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>>648 <a href="#core.rules" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1. 4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>>654 <p id="rfc.section.1.2.1.p.1">The core rules below are defined in <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> and <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>: 655 </p> 656 <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#core.rules" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>> 657 <a href="#core.rules" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>> 649 658 <a href="#core.rules" class="smpl">HTTP-date</a> = <HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 8</a>> 650 659 </pre><h3 id="rfc.section.1.2.2"><a href="#rfc.section.1.2.2">1.2.2</a> <a id="abnf.dependencies" href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></h3> … … 1046 1055 </p> 1047 1056 <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="acks" href="#acks">Acknowledgments</a></h1> 1048 <p id="rfc.section.8.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 11</a> of <a href="#Part1" id="rfc.xref.Part1. 5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.1057 <p id="rfc.section.8.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 11</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 1049 1058 </p> 1050 1059 <h1 id="rfc.references"><a id="rfc.section.9" href="#rfc.section.9">9.</a> References … … 1409 1418 </ul> 1410 1419 <h2 id="rfc.section.D.18"><a href="#rfc.section.D.18">D.18</a> <a id="changes.since.16" href="#changes.since.16">Since draft-ietf-httpbis-p5-range-16</a></h2> 1411 <p id="rfc.section.D.18.p.1">None yet.</p> 1420 <p id="rfc.section.D.18.p.1">Closed issues: </p> 1421 <ul> 1422 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/186">http://tools.ietf.org/wg/httpbis/trac/ticket/186</a>>: "Document HTTP's error-handling philosophy" 1423 </li> 1424 </ul> 1412 1425 <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> 1413 1426 <p class="noprint"><a href="#rfc.index.2">2</a> <a href="#rfc.index.4">4</a> <a href="#rfc.index.A">A</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> … … 1484 1497 </li> 1485 1498 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 1486 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1.2</a>, <a href="#rfc.xref.Part1.2">1.2.1</a>, <a href="#rfc.xref.Part1.3">1.2.1</a>, <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">8</a>, <a href="#Part1"><b>9.1</b></a><ul> 1487 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.1">1.2</a></li> 1488 <li><em>Section 1.2.2</em> <a href="#rfc.xref.Part1.3">1.2.1</a></li> 1489 <li><em>Section 3.2.3</em> <a href="#rfc.xref.Part1.4">1.2.1</a></li> 1490 <li><em>Section 11</em> <a href="#rfc.xref.Part1.5">8</a></li> 1499 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1.1</a>, <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">1.2.1</a>, <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">8</a>, <a href="#Part1"><b>9.1</b></a><ul> 1500 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.2">1.2</a></li> 1501 <li><em>Section 1.2.2</em> <a href="#rfc.xref.Part1.4">1.2.1</a></li> 1502 <li><em>Section 2</em> <a href="#rfc.xref.Part1.1">1.1</a></li> 1503 <li><em>Section 3.2.3</em> <a href="#rfc.xref.Part1.5">1.2.1</a></li> 1504 <li><em>Section 11</em> <a href="#rfc.xref.Part1.6">8</a></li> 1491 1505 </ul> 1492 1506 </li> -
draft-ietf-httpbis/latest/p5-range.xml
r1443 r1452 15 15 <!ENTITY ID-MONTH "October"> 16 16 <!ENTITY ID-YEAR "2011"> 17 <!ENTITY architecture "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 17 18 <!ENTITY notation "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 18 19 <!ENTITY notation-abnf "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 242 243 </t> 243 244 244 <section title=" Requirements" anchor="intro.requirements">245 <section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling"> 245 246 <t> 246 247 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", … … 249 250 </t> 250 251 <t> 251 An implementation is not compliant if it fails to satisfy one or more 252 of the "MUST" or "REQUIRED" level requirements for the protocols it 253 implements. An implementation that satisfies all the "MUST" or "REQUIRED" 254 level and all the "SHOULD" level requirements for its protocols is said 255 to be "unconditionally compliant"; one that satisfies all the "MUST" 256 level requirements but not all the "SHOULD" level requirements for its 257 protocols is said to be "conditionally compliant". 252 This document defines conformance criteria for several roles in HTTP 253 communication, including Senders, Recipients, Clients, Servers, User-Agents, 254 Origin Servers, Intermediaries, Proxies and Gateways. See &architecture; 255 for definitions of these terms. 256 </t> 257 <t> 258 An implementation is considered conformant if it complies with all of the 259 requirements associated with its role(s). Note that SHOULD-level requirements 260 are relevant here, unless one of the documented exceptions is applicable. 261 </t> 262 <t> 263 This document also uses ABNF to define valid protocol elements 264 (<xref target="notation"/>). In addition to the prose requirements placed 265 upon them, Senders &MUST-NOT; generate protocol elements that are invalid. 266 </t> 267 <t> 268 Unless noted otherwise, Recipients &MAY; take steps to recover a usable 269 protocol element from an invalid construct. However, HTTP does not define 270 specific error handling mechanisms, except in cases where it has direct 271 impact on security. This is because different uses of the protocol require 272 different error handling strategies; for example, a Web browser may wish to 273 transparently recover from a response where the Location header field 274 doesn't parse according to the ABNF, whereby in a systems control protocol 275 using HTTP, this type of error recovery could lead to dangerous consequences. 258 276 </t> 259 277 </section> … … 1765 1783 <section title="Since draft-ietf-httpbis-p5-range-16" anchor="changes.since.16"> 1766 1784 <t> 1767 None yet. 1785 Closed issues: 1786 <list style="symbols"> 1787 <t> 1788 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/186"/>: 1789 "Document HTTP's error-handling philosophy" 1790 </t> 1791 </list> 1768 1792 </t> 1769 1793 </section> -
draft-ietf-httpbis/latest/p6-cache.html
r1449 r1452 362 362 } 363 363 @bottom-center { 364 content: "Expires April 2 0, 2012";364 content: "Expires April 25, 2012"; 365 365 } 366 366 @bottom-right { … … 408 408 <meta name="dct.creator" content="Reschke, J. F."> 409 409 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest"> 410 <meta name="dct.issued" scheme="ISO8601" content="2011-10- 18">410 <meta name="dct.issued" scheme="ISO8601" content="2011-10-23"> 411 411 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 412 412 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 6 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages."> … … 434 434 </tr> 435 435 <tr> 436 <td class="left">Expires: April 2 0, 2012</td>436 <td class="left">Expires: April 25, 2012</td> 437 437 <td class="right">J. Mogul</td> 438 438 </tr> … … 499 499 <tr> 500 500 <td class="left"></td> 501 <td class="right">October 18, 2011</td>501 <td class="right">October 23, 2011</td> 502 502 </tr> 503 503 </tbody> … … 529 529 in progress”. 530 530 </p> 531 <p>This Internet-Draft will expire on April 2 0, 2012.</p>531 <p>This Internet-Draft will expire on April 25, 2012.</p> 532 532 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 533 533 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 550 550 <li>1.1 <a href="#intro.purpose">Purpose</a></li> 551 551 <li>1.2 <a href="#intro.terminology">Terminology</a></li> 552 <li>1.3 <a href="#intro. requirements">Requirements</a></li>552 <li>1.3 <a href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></li> 553 553 <li>1.4 <a href="#notation">Syntax Notation</a><ul> 554 554 <li>1.4.1 <a href="#core.rules">Core Rules</a></li> … … 727 727 </li> 728 728 </ul> 729 <h2 id="rfc.section.1.3"><a href="#rfc.section.1.3">1.3</a> <a id="intro. requirements" href="#intro.requirements">Requirements</a></h2>729 <h2 id="rfc.section.1.3"><a href="#rfc.section.1.3">1.3</a> <a id="intro.conformance.and.error.handling" href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></h2> 730 730 <p id="rfc.section.1.3.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 731 731 in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>. 732 732 </p> 733 <p id="rfc.section.1.3.p.2">An implementation is not compliant if it fails to satisfy one or more of the "MUST" or "REQUIRED" level requirements for the 734 protocols it implements. An implementation that satisfies all the "MUST" or "REQUIRED" level and all the "SHOULD" level requirements 735 for its protocols is said to be "unconditionally compliant"; one that satisfies all the "MUST" level requirements but not 736 all the "SHOULD" level requirements for its protocols is said to be "conditionally compliant". 733 <p id="rfc.section.1.3.p.2">This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients, 734 Servers, User-Agents, Origin Servers, Intermediaries, Proxies and Gateways. See <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for definitions of these terms. 735 </p> 736 <p id="rfc.section.1.3.p.3">An implementation is considered conformant if it complies with all of the requirements associated with its role(s). Note that 737 SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable. 738 </p> 739 <p id="rfc.section.1.3.p.4">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section 1.4</a>). In addition to the prose requirements placed upon them, Senders <em class="bcp14">MUST NOT</em> generate protocol elements that are invalid. 740 </p> 741 <p id="rfc.section.1.3.p.5">Unless noted otherwise, Recipients <em class="bcp14">MAY</em> take steps to recover a usable protocol element from an invalid construct. However, HTTP does not define specific error handling 742 mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require 743 different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the 744 Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of 745 error recovery could lead to dangerous consequences. 737 746 </p> 738 747 <h2 id="rfc.section.1.4"><a href="#rfc.section.1.4">1.4</a> <a id="notation" href="#notation">Syntax Notation</a></h2> 739 <p id="rfc.section.1.4.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1. 1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> (which extends the syntax defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list rule). <a href="#collected.abnf" title="Collected ABNF">Appendix B</a> shows the collected ABNF, with the list rule expanded.748 <p id="rfc.section.1.4.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> (which extends the syntax defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list rule). <a href="#collected.abnf" title="Collected ABNF">Appendix B</a> shows the collected ABNF, with the list rule expanded. 740 749 </p> 741 750 <p id="rfc.section.1.4.p.2">The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG … … 744 753 </p> 745 754 <h3 id="rfc.section.1.4.1"><a href="#rfc.section.1.4.1">1.4.1</a> <a id="core.rules" href="#core.rules">Core Rules</a></h3> 746 <p id="rfc.section.1.4.1.p.1">The core rules below are defined in <a href="#Part1" id="rfc.xref.Part1. 2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>:747 </p> 748 <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#core.rules" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1. 3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>>749 <a href="#core.rules" class="smpl">quoted-string</a> = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1. 4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>>750 <a href="#core.rules" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1. 5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>>755 <p id="rfc.section.1.4.1.p.1">The core rules below are defined in <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>: 756 </p> 757 <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#core.rules" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>> 758 <a href="#core.rules" class="smpl">quoted-string</a> = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>> 759 <a href="#core.rules" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>> 751 760 </pre><h3 id="rfc.section.1.4.2"><a href="#rfc.section.1.4.2">1.4.2</a> <a id="abnf.dependencies" href="#abnf.dependencies">ABNF Rules defined in other Parts of the Specification</a></h3> 752 761 <p id="rfc.section.1.4.2.p.1">The ABNF rules below are defined in other parts:</p> 753 <div id="rfc.figure.u.2"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">field-name</a> = <field-name, defined in <a href="#Part1" id="rfc.xref.Part1. 6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a>>762 <div id="rfc.figure.u.2"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">field-name</a> = <field-name, defined in <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a>> 754 763 <a href="#abnf.dependencies" class="smpl">HTTP-date</a> = <HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 8</a>> 755 <a href="#abnf.dependencies" class="smpl">port</a> = <port, defined in <a href="#Part1" id="rfc.xref.Part1. 7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>>756 <a href="#abnf.dependencies" class="smpl">pseudonym</a> = <pseudonym, defined in <a href="#Part1" id="rfc.xref.Part1. 8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.via" title="Via">Section 8.8</a>>757 <a href="#abnf.dependencies" class="smpl">uri-host</a> = <uri-host, defined in <a href="#Part1" id="rfc.xref.Part1. 9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>>764 <a href="#abnf.dependencies" class="smpl">port</a> = <port, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 765 <a href="#abnf.dependencies" class="smpl">pseudonym</a> = <pseudonym, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.via" title="Via">Section 8.8</a>> 766 <a href="#abnf.dependencies" class="smpl">uri-host</a> = <uri-host, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>> 758 767 </pre><h2 id="rfc.section.1.5"><a href="#rfc.section.1.5">1.5</a> <a id="delta-seconds" href="#delta-seconds">Delta Seconds</a></h2> 759 768 <p id="rfc.section.1.5.p.1">The delta-seconds rule specifies a non-negative integer, representing time in seconds.</p> … … 815 824 time, as such responses are not usually useful to store. However, caches are not prohibited from storing such responses. 816 825 </p> 817 <p id="rfc.section.2.1.p.5">A response message is considered complete when all of the octets indicated by the message framing (<a href="#Part1" id="rfc.xref.Part1.1 0"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) are received prior to the connection being closed. If the request is GET, the response status is 200 (OK), and the entire826 <p id="rfc.section.2.1.p.5">A response message is considered complete when all of the octets indicated by the message framing (<a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) are received prior to the connection being closed. If the request is GET, the response status is 200 (OK), and the entire 818 827 response header block has been received, a cache <em class="bcp14">MAY</em> store an incomplete response message-body if the cache entry is recorded as incomplete. Likewise, a 206 (Partial Content) 819 828 response <em class="bcp14">MAY</em> be stored as if it were an incomplete 200 (OK) cache entry. However, a cache <em class="bcp14">MUST NOT</em> store incomplete or partial content responses if it does not support the Range and Content-Range header fields or if it does … … 827 836 </p> 828 837 <ul> 829 <li>The presented effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.1 1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and that of the stored response match, and838 <li>The presented effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and that of the stored response match, and 830 839 </li> 831 840 <li>the request method associated with the stored response allows it to be used for the presented request, and</li> … … 1060 1069 to keep their contents up-to-date. 1061 1070 </p> 1062 <p id="rfc.section.2.5.p.2">A cache <em class="bcp14">MUST</em> invalidate the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.1 2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) as well as the URI(s) in the Location and Content-Location header fields (if present) when a non-error response to a request1071 <p id="rfc.section.2.5.p.2">A cache <em class="bcp14">MUST</em> invalidate the effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) as well as the URI(s) in the Location and Content-Location header fields (if present) when a non-error response to a request 1063 1072 with an unsafe method is received. 1064 1073 </p> 1065 1074 <p id="rfc.section.2.5.p.3">However, a cache <em class="bcp14">MUST NOT</em> invalidate a URI from a Location or Content-Location header field if the host part of that URI differs from the host part 1066 in the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.1 3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). This helps prevent denial of service attacks.1067 </p> 1068 <p id="rfc.section.2.5.p.4">A cache <em class="bcp14">MUST</em> invalidate the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.1 4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) when it receives a non-error response to a request with a method whose safety is unknown.1075 in the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). This helps prevent denial of service attacks. 1076 </p> 1077 <p id="rfc.section.2.5.p.4">A cache <em class="bcp14">MUST</em> invalidate the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) when it receives a non-error response to a request with a method whose safety is unknown. 1069 1078 </p> 1070 1079 <p id="rfc.section.2.5.p.5">Here, a "non-error response" is one with a 2xx or 3xx status code. "Invalidate" means that the cache will either remove all … … 1093 1102 <ul> 1094 1103 <li>adding or removing whitespace, where allowed in the header field's syntax</li> 1095 <li>combining multiple header fields with the same field name (see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.1 5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>)1104 <li>combining multiple header fields with the same field name (see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) 1096 1105 </li> 1097 1106 <li>normalizing both header field values in a way that is known to have identical semantics, according to the header field's specification … … 1704 1713 </p> 1705 1714 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="acks" href="#acks">Acknowledgments</a></h1> 1706 <p id="rfc.section.7.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 11</a> of <a href="#Part1" id="rfc.xref.Part1.1 6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.1715 <p id="rfc.section.7.p.1">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 11</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 1707 1716 </p> 1708 1717 <h1 id="rfc.references"><a id="rfc.section.8" href="#rfc.section.8">8.</a> References … … 2075 2084 <p id="rfc.section.C.18.p.1">Closed issues: </p> 2076 2085 <ul> 2086 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/186">http://tools.ietf.org/wg/httpbis/trac/ticket/186</a>>: "Document HTTP's error-handling philosophy" 2087 </li> 2077 2088 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/317">http://tools.ietf.org/wg/httpbis/trac/ticket/317</a>>: "Cache-Control directive case sensitivity" 2078 2089 </li> … … 2211 2222 </li> 2212 2223 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 2213 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1.4</a>, <a href="#rfc.xref.Part1.2">1.4.1</a>, <a href="#rfc.xref.Part1.3">1.4.1</a>, <a href="#rfc.xref.Part1.4">1.4.1</a>, <a href="#rfc.xref.Part1.5">1.4.1</a>, <a href="#rfc.xref.Part1.6">1.4.2</a>, <a href="#rfc.xref.Part1.7">1.4.2</a>, <a href="#rfc.xref.Part1.8">1.4.2</a>, <a href="#rfc.xref.Part1.9">1.4.2</a>, <a href="#rfc.xref.Part1.10">2.1</a>, <a href="#rfc.xref.Part1.11">2.2</a>, <a href="#rfc.xref.Part1.12">2.5</a>, <a href="#rfc.xref.Part1.13">2.5</a>, <a href="#rfc.xref.Part1.14">2.5</a>, <a href="#rfc.xref.Part1.15">2.7</a>, <a href="#rfc.xref.Part1.16">7</a>, <a href="#Part1"><b>8.1</b></a><ul> 2214 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.1">1.4</a></li> 2215 <li><em>Section 1.2.2</em> <a href="#rfc.xref.Part1.3">1.4.1</a></li> 2216 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.7">1.4.2</a>, <a href="#rfc.xref.Part1.9">1.4.2</a></li> 2217 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.6">1.4.2</a>, <a href="#rfc.xref.Part1.15">2.7</a></li> 2218 <li><em>Section 3.2.3</em> <a href="#rfc.xref.Part1.4">1.4.1</a>, <a href="#rfc.xref.Part1.5">1.4.1</a></li> 2219 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.11">2.2</a>, <a href="#rfc.xref.Part1.12">2.5</a>, <a href="#rfc.xref.Part1.13">2.5</a>, <a href="#rfc.xref.Part1.14">2.5</a></li> 2220 <li><em>Section 8.8</em> <a href="#rfc.xref.Part1.8">1.4.2</a></li> 2221 <li><em>Section 11</em> <a href="#rfc.xref.Part1.16">7</a></li> 2224 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1.3</a>, <a href="#rfc.xref.Part1.2">1.4</a>, <a href="#rfc.xref.Part1.3">1.4.1</a>, <a href="#rfc.xref.Part1.4">1.4.1</a>, <a href="#rfc.xref.Part1.5">1.4.1</a>, <a href="#rfc.xref.Part1.6">1.4.1</a>, <a href="#rfc.xref.Part1.7">1.4.2</a>, <a href="#rfc.xref.Part1.8">1.4.2</a>, <a href="#rfc.xref.Part1.9">1.4.2</a>, <a href="#rfc.xref.Part1.10">1.4.2</a>, <a href="#rfc.xref.Part1.11">2.1</a>, <a href="#rfc.xref.Part1.12">2.2</a>, <a href="#rfc.xref.Part1.13">2.5</a>, <a href="#rfc.xref.Part1.14">2.5</a>, <a href="#rfc.xref.Part1.15">2.5</a>, <a href="#rfc.xref.Part1.16">2.7</a>, <a href="#rfc.xref.Part1.17">7</a>, <a href="#Part1"><b>8.1</b></a><ul> 2225 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.2">1.4</a></li> 2226 <li><em>Section 1.2.2</em> <a href="#rfc.xref.Part1.4">1.4.1</a></li> 2227 <li><em>Section 2</em> <a href="#rfc.xref.Part1.1">1.3</a></li> 2228 <li><em>Section 2.7</em> <a href="#rfc.xref.Part1.8">1.4.2</a>, <a href="#rfc.xref.Part1.10">1.4.2</a></li> 2229 <li><em>Section 3.2</em> <a href="#rfc.xref.Part1.7">1.4.2</a>, <a href="#rfc.xref.Part1.16">2.7</a></li> 2230 <li><em>Section 3.2.3</em> <a href="#rfc.xref.Part1.5">1.4.1</a>, <a href="#rfc.xref.Part1.6">1.4.1</a></li> 2231 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.12">2.2</a>, <a href="#rfc.xref.Part1.13">2.5</a>, <a href="#rfc.xref.Part1.14">2.5</a>, <a href="#rfc.xref.Part1.15">2.5</a></li> 2232 <li><em>Section 8.8</em> <a href="#rfc.xref.Part1.9">1.4.2</a></li> 2233 <li><em>Section 11</em> <a href="#rfc.xref.Part1.17">7</a></li> 2222 2234 </ul> 2223 2235 </li> -
draft-ietf-httpbis/latest/p6-cache.xml
r1449 r1452 15 15 <!ENTITY ID-MONTH "October"> 16 16 <!ENTITY ID-YEAR "2011"> 17 <!ENTITY architecture "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 17 18 <!ENTITY notation "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 18 19 <!ENTITY acks "<xref target='Part1' x:rel='#acks' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 388 389 </section> 389 390 390 <section anchor="intro.requirements" title="Requirements">391 <section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling"> 391 392 <t> 392 393 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", … … 395 396 </t> 396 397 <t> 397 An implementation is not compliant if it fails to satisfy one or more of 398 the "MUST" or "REQUIRED" level requirements for the protocols it 399 implements. An implementation that satisfies all the "MUST" or "REQUIRED" 400 level and all the "SHOULD" level requirements for its protocols is said to 401 be "unconditionally compliant"; one that satisfies all the "MUST" level 402 requirements but not all the "SHOULD" level requirements for its protocols 403 is said to be "conditionally compliant". 398 This document defines conformance criteria for several roles in HTTP 399 communication, including Senders, Recipients, Clients, Servers, User-Agents, 400 Origin Servers, Intermediaries, Proxies and Gateways. See &architecture; 401 for definitions of these terms. 402 </t> 403 <t> 404 An implementation is considered conformant if it complies with all of the 405 requirements associated with its role(s). Note that SHOULD-level requirements 406 are relevant here, unless one of the documented exceptions is applicable. 407 </t> 408 <t> 409 This document also uses ABNF to define valid protocol elements 410 (<xref target="notation"/>). In addition to the prose requirements placed 411 upon them, Senders &MUST-NOT; generate protocol elements that are invalid. 412 </t> 413 <t> 414 Unless noted otherwise, Recipients &MAY; take steps to recover a usable 415 protocol element from an invalid construct. However, HTTP does not define 416 specific error handling mechanisms, except in cases where it has direct 417 impact on security. This is because different uses of the protocol require 418 different error handling strategies; for example, a Web browser may wish to 419 transparently recover from a response where the Location header field 420 doesn't parse according to the ABNF, whereby in a systems control protocol 421 using HTTP, this type of error recovery could lead to dangerous consequences. 404 422 </t> 405 423 </section> … … 2895 2913 <list style="symbols"> 2896 2914 <t> 2915 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/186"/>: 2916 "Document HTTP's error-handling philosophy" 2917 </t> 2918 <t> 2897 2919 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/317"/>: 2898 2920 "Cache-Control directive case sensitivity" -
draft-ietf-httpbis/latest/p7-auth.html
r1443 r1452 359 359 } 360 360 @bottom-center { 361 content: "Expires April 4, 2012";361 content: "Expires April 25, 2012"; 362 362 } 363 363 @bottom-right { … … 404 404 <meta name="dct.creator" content="Reschke, J. F."> 405 405 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest"> 406 <meta name="dct.issued" scheme="ISO8601" content="2011-10- 02">406 <meta name="dct.issued" scheme="ISO8601" content="2011-10-23"> 407 407 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 408 408 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 7 defines the HTTP Authentication framework."> … … 435 435 </tr> 436 436 <tr> 437 <td class="left">Expires: April 4, 2012</td>437 <td class="left">Expires: April 25, 2012</td> 438 438 <td class="right">HP</td> 439 439 </tr> … … 488 488 <tr> 489 489 <td class="left"></td> 490 <td class="right">October 2 , 2011</td>490 <td class="right">October 23, 2011</td> 491 491 </tr> 492 492 </tbody> … … 516 516 in progress”. 517 517 </p> 518 <p>This Internet-Draft will expire on April 4, 2012.</p>518 <p>This Internet-Draft will expire on April 25, 2012.</p> 519 519 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 520 520 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 535 535 <ul class="toc"> 536 536 <li>1. <a href="#introduction">Introduction</a><ul> 537 <li>1.1 <a href="#intro. requirements">Requirements</a></li>537 <li>1.1 <a href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></li> 538 538 <li>1.2 <a href="#notation">Syntax Notation</a><ul> 539 539 <li>1.2.1 <a href="#core.rules">Core Rules</a></li> … … 612 612 provide authentication information. The "basic" and "digest" authentication schemes continue to be specified in <cite title="HTTP Authentication: Basic and Digest Access Authentication" id="rfc.xref.RFC2617.2">RFC 2617</cite>. 613 613 </p> 614 <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="intro. requirements" href="#intro.requirements">Requirements</a></h2>614 <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="intro.conformance.and.error.handling" href="#intro.conformance.and.error.handling">Conformance and Error Handling</a></h2> 615 615 <p id="rfc.section.1.1.p.1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 616 616 in this document are to be interpreted as described in <a href="#RFC2119" id="rfc.xref.RFC2119.1"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>. 617 617 </p> 618 <p id="rfc.section.1.1.p.2">An implementation is not compliant if it fails to satisfy one or more of the "MUST" or "REQUIRED" level requirements for the 619 protocols it implements. An implementation that satisfies all the "MUST" or "REQUIRED" level and all the "SHOULD" level requirements 620 for its protocols is said to be "unconditionally compliant"; one that satisfies all the "MUST" level requirements but not 621 all the "SHOULD" level requirements for its protocols is said to be "conditionally compliant". 618 <p id="rfc.section.1.1.p.2">This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients, 619 Servers, User-Agents, Origin Servers, Intermediaries, Proxies and Gateways. See <a href="p1-messaging.html#architecture" title="Architecture">Section 2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for definitions of these terms. 620 </p> 621 <p id="rfc.section.1.1.p.3">An implementation is considered conformant if it complies with all of the requirements associated with its role(s). Note that 622 SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable. 623 </p> 624 <p id="rfc.section.1.1.p.4">This document also uses ABNF to define valid protocol elements (<a href="#notation" title="Syntax Notation">Section 1.2</a>). In addition to the prose requirements placed upon them, Senders <em class="bcp14">MUST NOT</em> generate protocol elements that are invalid. 625 </p> 626 <p id="rfc.section.1.1.p.5">Unless noted otherwise, Recipients <em class="bcp14">MAY</em> take steps to recover a usable protocol element from an invalid construct. However, HTTP does not define specific error handling 627 mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require 628 different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the 629 Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of 630 error recovery could lead to dangerous consequences. 622 631 </p> 623 632 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="notation" href="#notation">Syntax Notation</a></h2> 624 <p id="rfc.section.1.2.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1. 1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> (which extends the syntax defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list rule). <a href="#collected.abnf" title="Collected ABNF">Appendix B</a> shows the collected ABNF, with the list rule expanded.633 <p id="rfc.section.1.2.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> (which extends the syntax defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a> with a list rule). <a href="#collected.abnf" title="Collected ABNF">Appendix B</a> shows the collected ABNF, with the list rule expanded. 625 634 </p> 626 635 <p id="rfc.section.1.2.p.2">The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG … … 629 638 </p> 630 639 <h3 id="rfc.section.1.2.1"><a href="#rfc.section.1.2.1">1.2.1</a> <a id="core.rules" href="#core.rules">Core Rules</a></h3> 631 <p id="rfc.section.1.2.1.p.1">The core rules below are defined in <a href="#Part1" id="rfc.xref.Part1. 2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>:632 </p> 633 <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#core.rules" class="smpl">BWS</a> = <BWS, defined in <a href="#Part1" id="rfc.xref.Part1. 3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>>634 <a href="#core.rules" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1. 4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>>635 <a href="#core.rules" class="smpl">quoted-string</a> = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1. 5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>>636 <a href="#core.rules" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1. 6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>>640 <p id="rfc.section.1.2.1.p.1">The core rules below are defined in <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>: 641 </p> 642 <div id="rfc.figure.u.1"></div><pre class="inline"> <a href="#core.rules" class="smpl">BWS</a> = <BWS, defined in <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>> 643 <a href="#core.rules" class="smpl">OWS</a> = <OWS, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#basic.rules" title="Basic Rules">Section 1.2.2</a>> 644 <a href="#core.rules" class="smpl">quoted-string</a> = <quoted-string, defined in <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>> 645 <a href="#core.rules" class="smpl">token</a> = <token, defined in <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#field.rules" title="Common Field ABNF Rules">Section 3.2.3</a>> 637 646 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a id="access.authentication.framework" href="#access.authentication.framework">Access Authentication Framework</a></h1> 638 647 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> <a id="challenge.and.response" href="#challenge.and.response">Challenge and Response</a></h2> … … 695 704 <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.r.2"></span><span id="rfc.iref.r.3"></span><span id="rfc.iref.g.6"></span> realm = "realm" <a href="#core.rules" class="smpl">BWS</a> "=" <a href="#core.rules" class="smpl">BWS</a> realm-value 696 705 realm-value = quoted-string 697 </pre><p id="rfc.section.2.2.p.3">A <dfn>protection space</dfn> is defined by the canonical root URI (the scheme and authority components of the effective request URI; see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1. 7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) of the server being accessed, in combination with the realm value if present. These realms allow the protected resources706 </pre><p id="rfc.section.2.2.p.3">A <dfn>protection space</dfn> is defined by the canonical root URI (the scheme and authority components of the effective request URI; see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) of the server being accessed, in combination with the realm value if present. These realms allow the protected resources 698 707 on a server to be partitioned into a set of protection spaces, each with its own authentication scheme and/or authorization 699 708 database. The realm value is a string, generally assigned by the origin server, which can have additional semantics specific … … 727 736 <p>Authentication schemes need to be compatible with the inherent constraints of HTTP; for instance, that messages need to keep 728 737 their semantics when inspected in isolation, thus an authentication scheme can not bind information to the TCP session over 729 which the message was received (see <a href="p1-messaging.html#message-orientation-and-buffering" title="Message Orientation and Buffering">Section 2.2</a> of <a href="#Part1" id="rfc.xref.Part1. 8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).738 which the message was received (see <a href="p1-messaging.html#message-orientation-and-buffering" title="Message Orientation and Buffering">Section 2.2</a> of <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 730 739 </p> 731 740 </li> … … 800 809 <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="header.proxy-authenticate" href="#header.proxy-authenticate">Proxy-Authenticate</a></h2> 801 810 <p id="rfc.section.4.2.p.1">The "Proxy-Authenticate" header field consists of a challenge that indicates the authentication scheme and parameters applicable 802 to the proxy for this effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1. 9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It <em class="bcp14">MUST</em> be included as part of a 407 (Proxy Authentication Required) response.811 to the proxy for this effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It <em class="bcp14">MUST</em> be included as part of a 407 (Proxy Authentication Required) response. 803 812 </p> 804 813 <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.8"></span> <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> = 1#<a href="#challenge.and.response" class="smpl">challenge</a> … … 824 833 <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a> <a id="header.www-authenticate" href="#header.www-authenticate">WWW-Authenticate</a></h2> 825 834 <p id="rfc.section.4.4.p.1">The "WWW-Authenticate" header field consists of at least one challenge that indicates the authentication scheme(s) and parameters 826 applicable to the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.1 0"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).835 applicable to the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 827 836 </p> 828 837 <p id="rfc.section.4.4.p.2">It <em class="bcp14">MUST</em> be included in 401 (Unauthorized) response messages and <em class="bcp14">MAY</em> be included in other response messages to indicate that supplying credentials (or different credentials) might affect the … … 944 953 Lawrence C. Stewart for their work on that specification. See <a href="http://tools.ietf.org/html/rfc2617#section-6">Section 6</a> of <a href="#RFC2617" id="rfc.xref.RFC2617.4"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a> for further acknowledgements. 945 954 </p> 946 <p id="rfc.section.7.p.2">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 11</a> of <a href="#Part1" id="rfc.xref.Part1.1 1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the Acknowledgments related to this document revision.955 <p id="rfc.section.7.p.2">See <a href="p1-messaging.html#acks" title="Acknowledgments">Section 11</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the Acknowledgments related to this document revision. 947 956 </p> 948 957 <h1 id="rfc.references"><a id="rfc.section.8" href="#rfc.section.8">8.</a> References … … 1174 1183 </ul> 1175 1184 <h2 id="rfc.section.C.18"><a href="#rfc.section.C.18">C.18</a> <a id="changes.since.16" href="#changes.since.16">Since draft-ietf-httpbis-p7-auth-16</a></h2> 1176 <p id="rfc.section.C.18.p.1">None yet.</p> 1185 <p id="rfc.section.C.18.p.1">Closed issues: </p> 1186 <ul> 1187 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/186">http://tools.ietf.org/wg/httpbis/trac/ticket/186</a>>: "Document HTTP's error-handling philosophy" 1188 </li> 1189 </ul> 1177 1190 <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> 1178 1191 <p class="noprint"><a href="#rfc.index.4">4</a> <a href="#rfc.index.A">A</a> <a href="#rfc.index.B">B</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.W">W</a> … … 1229 1242 </li> 1230 1243 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 1231 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1.2</a>, <a href="#rfc.xref.Part1.2">1.2.1</a>, <a href="#rfc.xref.Part1.3">1.2.1</a>, <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">2.2</a>, <a href="#rfc.xref.Part1.8">2.3.1</a>, <a href="#rfc.xref.Part1.9">4.2</a>, <a href="#rfc.xref.Part1.10">4.4</a>, <a href="#rfc.xref.Part1.11">7</a>, <a href="#Part1"><b>8.1</b></a><ul> 1232 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.1">1.2</a></li> 1233 <li><em>Section 1.2.2</em> <a href="#rfc.xref.Part1.3">1.2.1</a>, <a href="#rfc.xref.Part1.4">1.2.1</a></li> 1234 <li><em>Section 2.2</em> <a href="#rfc.xref.Part1.8">2.3.1</a></li> 1235 <li><em>Section 3.2.3</em> <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a></li> 1236 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.7">2.2</a>, <a href="#rfc.xref.Part1.9">4.2</a>, <a href="#rfc.xref.Part1.10">4.4</a></li> 1237 <li><em>Section 11</em> <a href="#rfc.xref.Part1.11">7</a></li> 1244 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1.1</a>, <a href="#rfc.xref.Part1.2">1.2</a>, <a href="#rfc.xref.Part1.3">1.2.1</a>, <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a>, <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">1.2.1</a>, <a href="#rfc.xref.Part1.8">2.2</a>, <a href="#rfc.xref.Part1.9">2.3.1</a>, <a href="#rfc.xref.Part1.10">4.2</a>, <a href="#rfc.xref.Part1.11">4.4</a>, <a href="#rfc.xref.Part1.12">7</a>, <a href="#Part1"><b>8.1</b></a><ul> 1245 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.2">1.2</a></li> 1246 <li><em>Section 1.2.2</em> <a href="#rfc.xref.Part1.4">1.2.1</a>, <a href="#rfc.xref.Part1.5">1.2.1</a></li> 1247 <li><em>Section 2</em> <a href="#rfc.xref.Part1.1">1.1</a></li> 1248 <li><em>Section 2.2</em> <a href="#rfc.xref.Part1.9">2.3.1</a></li> 1249 <li><em>Section 3.2.3</em> <a href="#rfc.xref.Part1.6">1.2.1</a>, <a href="#rfc.xref.Part1.7">1.2.1</a></li> 1250 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.8">2.2</a>, <a href="#rfc.xref.Part1.10">4.2</a>, <a href="#rfc.xref.Part1.11">4.4</a></li> 1251 <li><em>Section 11</em> <a href="#rfc.xref.Part1.12">7</a></li> 1238 1252 </ul> 1239 1253 </li> -
draft-ietf-httpbis/latest/p7-auth.xml
r1443 r1452 16 16 <!ENTITY ID-YEAR "2011"> 17 17 <!ENTITY mdash "—"> 18 <!ENTITY architecture "<xref target='Part1' x:rel='#architecture' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 18 19 <!ENTITY notation "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 19 20 <!ENTITY notation-abnf "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 230 231 </t> 231 232 232 <section title=" Requirements" anchor="intro.requirements">233 <section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling"> 233 234 <t> 234 235 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", … … 237 238 </t> 238 239 <t> 239 An implementation is not compliant if it fails to satisfy one or more 240 of the "MUST" or "REQUIRED" level requirements for the protocols it 241 implements. An implementation that satisfies all the "MUST" or "REQUIRED" 242 level and all the "SHOULD" level requirements for its protocols is said 243 to be "unconditionally compliant"; one that satisfies all the "MUST" 244 level requirements but not all the "SHOULD" level requirements for its 245 protocols is said to be "conditionally compliant". 240 This document defines conformance criteria for several roles in HTTP 241 communication, including Senders, Recipients, Clients, Servers, User-Agents, 242 Origin Servers, Intermediaries, Proxies and Gateways. See &architecture; 243 for definitions of these terms. 244 </t> 245 <t> 246 An implementation is considered conformant if it complies with all of the 247 requirements associated with its role(s). Note that SHOULD-level requirements 248 are relevant here, unless one of the documented exceptions is applicable. 249 </t> 250 <t> 251 This document also uses ABNF to define valid protocol elements 252 (<xref target="notation"/>). In addition to the prose requirements placed 253 upon them, Senders &MUST-NOT; generate protocol elements that are invalid. 254 </t> 255 <t> 256 Unless noted otherwise, Recipients &MAY; take steps to recover a usable 257 protocol element from an invalid construct. However, HTTP does not define 258 specific error handling mechanisms, except in cases where it has direct 259 impact on security. This is because different uses of the protocol require 260 different error handling strategies; for example, a Web browser may wish to 261 transparently recover from a response where the Location header field 262 doesn't parse according to the ABNF, whereby in a systems control protocol 263 using HTTP, this type of error recovery could lead to dangerous consequences. 246 264 </t> 247 265 </section> … … 1389 1407 <section title="Since draft-ietf-httpbis-p7-auth-16" anchor="changes.since.16"> 1390 1408 <t> 1391 None yet. 1409 Closed issues: 1410 <list style="symbols"> 1411 <t> 1412 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/186"/>: 1413 "Document HTTP's error-handling philosophy" 1414 </t> 1415 </list> 1392 1416 </t> 1393 1417 </section>
Note: See TracChangeset
for help on using the changeset viewer.