Changeset 1770 for draft-ietf-httpbis/latest
- Timestamp:
- 14/07/12 12:41:41 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 12 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1768 r1770 449 449 } 450 450 @bottom-center { 451 content: "Expires January 1 4, 2013";451 content: "Expires January 15, 2013"; 452 452 } 453 453 @bottom-right { … … 491 491 <meta name="dct.creator" content="Reschke, J. F."> 492 492 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 493 <meta name="dct.issued" scheme="ISO8601" content="2012-07-1 3">493 <meta name="dct.issued" scheme="ISO8601" content="2012-07-14"> 494 494 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 495 495 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 523 523 </tr> 524 524 <tr> 525 <td class="left">Expires: January 1 4, 2013</td>525 <td class="left">Expires: January 15, 2013</td> 526 526 <td class="right">greenbytes</td> 527 527 </tr> 528 528 <tr> 529 529 <td class="left"></td> 530 <td class="right">July 1 3, 2012</td>530 <td class="right">July 14, 2012</td> 531 531 </tr> 532 532 </tbody> … … 560 560 in progress”. 561 561 </p> 562 <p>This Internet-Draft will expire on January 1 4, 2013.</p>562 <p>This Internet-Draft will expire on January 15, 2013.</p> 563 563 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 564 564 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 965 965 <p id="rfc.section.2.6.p.1">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP 966 966 requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways, 967 or caches, depending on what behavior is being constrained by the requirement. The verb "generate" is used instead of "send" 968 where a requirement differentiates between creating a protocol element and merely forwarding a received element downstream. 969 </p> 970 <p id="rfc.section.2.6.p.2">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes 971 in HTTP. 972 </p> 973 <p id="rfc.section.2.6.p.3">A sender <em class="bcp14">MUST NOT</em> generate protocol elements that do not match the grammar defined by the ABNF rules for those protocol elements that are applicable 967 or caches, depending on what behavior is being constrained by the requirement. 968 </p> 969 <p id="rfc.section.2.6.p.2">The verb "generate" is used instead of "send" where a requirement differentiates between creating a protocol element and merely 970 forwarding a received element downstream. 971 </p> 972 <p id="rfc.section.2.6.p.3">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes 973 in HTTP. Note that SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable. 974 </p> 975 <p id="rfc.section.2.6.p.4">In addition to the prose requirements placed upon them, senders <em class="bcp14">MUST NOT</em> generate protocol elements that do not match the grammar defined by the ABNF rules for those protocol elements that are applicable 974 976 to the sender's role. If a received protocol element is processed, the recipient <em class="bcp14">MUST</em> be able to parse any value that would match the ABNF rules for that protocol element, excluding only those rules not applicable 975 977 to the recipient's role. 976 978 </p> 977 <p id="rfc.section.2.6.p. 4">Unless noted otherwise, a recipient <em class="bcp14">MAY</em> attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms979 <p id="rfc.section.2.6.p.5">Unless noted otherwise, a recipient <em class="bcp14">MAY</em> attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms 978 980 except when they have a direct impact on security, since different applications of the protocol require different error handling 979 981 strategies. For example, a Web browser might wish to transparently recover from a response where the <a href="p2-semantics.html#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereas a systems control client might consider any form of error recovery -
draft-ietf-httpbis/latest/p1-messaging.xml
r1768 r1770 629 629 on senders, recipients, clients, servers, user agents, intermediaries, 630 630 origin servers, proxies, gateways, or caches, depending on what behavior 631 is being constrained by the requirement. The verb "generate" is used 632 instead of "send" where a requirement differentiates between creating a 633 protocol element and merely forwarding a received element downstream. 631 is being constrained by the requirement. 632 </t> 633 <t> 634 The verb "generate" is used instead of "send" where a requirement 635 differentiates between creating a protocol element and merely forwarding a 636 received element downstream. 634 637 </t> 635 638 <t> 636 639 An implementation is considered conformant if it complies with all of the 637 requirements associated with the roles it partakes in HTTP. 638 </t> 639 <t> 640 A sender &MUST-NOT; generate protocol elements that do not match 641 the grammar defined by the ABNF rules for those protocol elements that 642 are applicable to the sender's role. 643 If a received protocol element is processed, the recipient &MUST; be able 644 to parse any value that would match the ABNF rules for that protocol 640 requirements associated with the roles it partakes in HTTP. Note that 641 SHOULD-level requirements are relevant here, unless one of the documented 642 exceptions is applicable. 643 </t> 644 <t> 645 In addition to the prose requirements placed upon them, senders &MUST-NOT; 646 generate protocol elements that do not match the grammar defined by the 647 ABNF rules for those protocol elements that are applicable to the sender's 648 role. If a received protocol element is processed, the recipient &MUST; be 649 able to parse any value that would match the ABNF rules for that protocol 645 650 element, excluding only those rules not applicable to the recipient's role. 646 651 </t> … … 651 656 on security, since different applications of the protocol require 652 657 different error handling strategies. For example, a Web browser might 653 wish to transparently recover from a response where the <x:ref>Location</x:ref> 654 header field doesn't parse according to the ABNF, whereas a systems control 655 client might consider any form of error recovery to be dangerous. 658 wish to transparently recover from a response where the 659 <x:ref>Location</x:ref> header field doesn't parse according to the ABNF, 660 whereas a systems control client might consider any form of error recovery 661 to be dangerous. 656 662 </t> 657 663 </section> -
draft-ietf-httpbis/latest/p2-semantics.html
r1769 r1770 846 846 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>. 847 847 </p> 848 <p id="rfc.section.1.2.p.2">This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients, 849 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. 850 </p> 851 <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 852 SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable. 853 </p> 854 <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. 855 </p> 856 <p id="rfc.section.1.2.p.5">Unless noted otherwise, Recipients <em class="bcp14">MUST</em> be able to parse all protocol elements matching the ABNF rules defined for them and <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 857 mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require 858 different error handling strategies; for example, a Web browser might wish to transparently recover from a response where 859 the <a href="#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of error recovery 860 could lead to dangerous consequences. 848 <p id="rfc.section.1.2.p.2">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP 849 requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways, 850 or caches, depending on what behavior is being constrained by the requirement. 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. 851 </p> 852 <p id="rfc.section.1.2.p.3">The verb "generate" is used instead of "send" where a requirement differentiates between creating a protocol element and merely 853 forwarding a received element downstream. 854 </p> 855 <p id="rfc.section.1.2.p.4">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes 856 in HTTP. Note that SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable. 857 </p> 858 <p id="rfc.section.1.2.p.5">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 do not match the grammar defined by the ABNF rules for those protocol elements that are applicable 859 to the sender's role. If a received protocol element is processed, the recipient <em class="bcp14">MUST</em> be able to parse any value that would match the ABNF rules for that protocol element, excluding only those rules not applicable 860 to the recipient's role. 861 </p> 862 <p id="rfc.section.1.2.p.6">Unless noted otherwise, a recipient <em class="bcp14">MAY</em> attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms 863 except when they have a direct impact on security, since different applications of the protocol require different error handling 864 strategies. For example, a Web browser might wish to transparently recover from a response where the <a href="#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereas a systems control client might consider any form of error recovery 865 to be dangerous. 861 866 </p> 862 867 <h2 id="rfc.section.1.3"><a href="#rfc.section.1.3">1.3</a> <a id="notation" href="#notation">Syntax Notation</a></h2> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1769 r1770 283 283 </t> 284 284 <t> 285 This document defines conformance criteria for several roles in HTTP 286 communication, including Senders, Recipients, Clients, Servers, User-Agents, 287 Origin Servers, Intermediaries, Proxies and Gateways. See &architecture; 288 for definitions of these terms. 285 This specification targets conformance criteria according to the role of 286 a participant in HTTP communication. Hence, HTTP requirements are placed 287 on senders, recipients, clients, servers, user agents, intermediaries, 288 origin servers, proxies, gateways, or caches, depending on what behavior 289 is being constrained by the requirement. See &architecture; for definitions 290 of these terms. 291 </t> 292 <t> 293 The verb "generate" is used instead of "send" where a requirement 294 differentiates between creating a protocol element and merely forwarding a 295 received element downstream. 289 296 </t> 290 297 <t> 291 298 An implementation is considered conformant if it complies with all of the 292 requirements associated with its role(s). Note that SHOULD-level requirements 293 are relevant here, unless one of the documented exceptions is applicable. 299 requirements associated with the roles it partakes in HTTP. Note that 300 SHOULD-level requirements are relevant here, unless one of the documented 301 exceptions is applicable. 294 302 </t> 295 303 <t> 296 304 This document also uses ABNF to define valid protocol elements 297 (<xref target="notation"/>). In addition to the prose requirements placed 298 upon them, Senders &MUST-NOT; generate protocol elements that are invalid. 299 </t> 300 <t> 301 Unless noted otherwise, Recipients &MUST; be able to parse all protocol 302 elements matching the ABNF rules defined for them and &MAY; take steps to 303 recover a usable protocol element from an invalid construct. However, HTTP does not define 304 specific error handling mechanisms, except in cases where it has direct 305 impact on security. This is because different uses of the protocol require 306 different error handling strategies; for example, a Web browser might wish to 307 transparently recover from a response where the <x:ref>Location</x:ref> 308 header field doesn't parse according to the ABNF, whereby in a systems 309 control protocol using HTTP, this type of error recovery could lead to 310 dangerous consequences. 305 (<xref target="notation"/>). 306 In addition to the prose requirements placed upon them, senders &MUST-NOT; 307 generate protocol elements that do not match the grammar defined by the 308 ABNF rules for those protocol elements that are applicable to the sender's 309 role. If a received protocol element is processed, the recipient &MUST; be 310 able to parse any value that would match the ABNF rules for that protocol 311 element, excluding only those rules not applicable to the recipient's role. 312 </t> 313 <t> 314 Unless noted otherwise, a recipient &MAY; attempt to recover a usable 315 protocol element from an invalid construct. HTTP does not define 316 specific error handling mechanisms except when they have a direct impact 317 on security, since different applications of the protocol require 318 different error handling strategies. For example, a Web browser might 319 wish to transparently recover from a response where the 320 <x:ref>Location</x:ref> header field doesn't parse according to the ABNF, 321 whereas a systems control client might consider any form of error recovery 322 to be dangerous. 311 323 </t> 312 324 </section> -
draft-ietf-httpbis/latest/p4-conditional.html
r1764 r1770 449 449 } 450 450 @bottom-center { 451 content: "Expires January 1 4, 2013";451 content: "Expires January 15, 2013"; 452 452 } 453 453 @bottom-right { … … 490 490 <meta name="dct.creator" content="Reschke, J. F."> 491 491 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest"> 492 <meta name="dct.issued" scheme="ISO8601" content="2012-07-1 3">492 <meta name="dct.issued" scheme="ISO8601" content="2012-07-14"> 493 493 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 494 494 <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."> … … 516 516 </tr> 517 517 <tr> 518 <td class="left">Expires: January 1 4, 2013</td>518 <td class="left">Expires: January 15, 2013</td> 519 519 <td class="right">J. Reschke, Editor</td> 520 520 </tr> … … 525 525 <tr> 526 526 <td class="left"></td> 527 <td class="right">July 1 3, 2012</td>527 <td class="right">July 14, 2012</td> 528 528 </tr> 529 529 </tbody> … … 554 554 in progress”. 555 555 </p> 556 <p>This Internet-Draft will expire on January 1 4, 2013.</p>556 <p>This Internet-Draft will expire on January 15, 2013.</p> 557 557 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 558 558 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 649 649 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>. 650 650 </p> 651 <p id="rfc.section.1.1.p.2">This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients, 652 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. 653 </p> 654 <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 655 SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable. 656 </p> 657 <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. 658 </p> 659 <p id="rfc.section.1.1.p.5">Unless noted otherwise, Recipients <em class="bcp14">MUST</em> be able to parse all protocol elements matching the ABNF rules defined for them and <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 660 mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require 661 different error handling strategies; for example, a Web browser might wish to transparently recover from a response where 662 the <a href="p2-semantics.html#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of error recovery 663 could lead to dangerous consequences. 651 <p id="rfc.section.1.1.p.2">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP 652 requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways, 653 or caches, depending on what behavior is being constrained by the requirement. 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. 654 </p> 655 <p id="rfc.section.1.1.p.3">The verb "generate" is used instead of "send" where a requirement differentiates between creating a protocol element and merely 656 forwarding a received element downstream. 657 </p> 658 <p id="rfc.section.1.1.p.4">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes 659 in HTTP. Note that SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable. 660 </p> 661 <p id="rfc.section.1.1.p.5">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 do not match the grammar defined by the ABNF rules for those protocol elements that are applicable 662 to the sender's role. If a received protocol element is processed, the recipient <em class="bcp14">MUST</em> be able to parse any value that would match the ABNF rules for that protocol element, excluding only those rules not applicable 663 to the recipient's role. 664 </p> 665 <p id="rfc.section.1.1.p.6">Unless noted otherwise, a recipient <em class="bcp14">MAY</em> attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms 666 except when they have a direct impact on security, since different applications of the protocol require different error handling 667 strategies. For example, a Web browser might wish to transparently recover from a response where the <a href="p2-semantics.html#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereas a systems control client might consider any form of error recovery 668 to be dangerous. 664 669 </p> 665 670 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="notation" href="#notation">Syntax Notation</a></h2> -
draft-ietf-httpbis/latest/p4-conditional.xml
r1764 r1770 175 175 </t> 176 176 <t> 177 This document defines conformance criteria for several roles in HTTP 178 communication, including Senders, Recipients, Clients, Servers, User-Agents, 179 Origin Servers, Intermediaries, Proxies and Gateways. See &architecture; 180 for definitions of these terms. 177 This specification targets conformance criteria according to the role of 178 a participant in HTTP communication. Hence, HTTP requirements are placed 179 on senders, recipients, clients, servers, user agents, intermediaries, 180 origin servers, proxies, gateways, or caches, depending on what behavior 181 is being constrained by the requirement. See &architecture; for definitions 182 of these terms. 183 </t> 184 <t> 185 The verb "generate" is used instead of "send" where a requirement 186 differentiates between creating a protocol element and merely forwarding a 187 received element downstream. 181 188 </t> 182 189 <t> 183 190 An implementation is considered conformant if it complies with all of the 184 requirements associated with its role(s). Note that SHOULD-level requirements 185 are relevant here, unless one of the documented exceptions is applicable. 191 requirements associated with the roles it partakes in HTTP. Note that 192 SHOULD-level requirements are relevant here, unless one of the documented 193 exceptions is applicable. 186 194 </t> 187 195 <t> 188 196 This document also uses ABNF to define valid protocol elements 189 (<xref target="notation"/>). In addition to the prose requirements placed 190 upon them, Senders &MUST-NOT; generate protocol elements that are invalid. 191 </t> 192 <t> 193 Unless noted otherwise, Recipients &MUST; be able to parse all protocol 194 elements matching the ABNF rules defined for them and &MAY; take steps to 195 recover a usable protocol element from an invalid construct. However, HTTP does not define 196 specific error handling mechanisms, except in cases where it has direct 197 impact on security. This is because different uses of the protocol require 198 different error handling strategies; for example, a Web browser might wish to 199 transparently recover from a response where the <x:ref>Location</x:ref> 200 header field doesn't parse according to the ABNF, whereby in a systems 201 control protocol using HTTP, this type of error recovery could lead to 202 dangerous consequences. 197 (<xref target="notation"/>). 198 In addition to the prose requirements placed upon them, senders &MUST-NOT; 199 generate protocol elements that do not match the grammar defined by the 200 ABNF rules for those protocol elements that are applicable to the sender's 201 role. If a received protocol element is processed, the recipient &MUST; be 202 able to parse any value that would match the ABNF rules for that protocol 203 element, excluding only those rules not applicable to the recipient's role. 204 </t> 205 <t> 206 Unless noted otherwise, a recipient &MAY; attempt to recover a usable 207 protocol element from an invalid construct. HTTP does not define 208 specific error handling mechanisms except when they have a direct impact 209 on security, since different applications of the protocol require 210 different error handling strategies. For example, a Web browser might 211 wish to transparently recover from a response where the 212 <x:ref>Location</x:ref> header field doesn't parse according to the ABNF, 213 whereas a systems control client might consider any form of error recovery 214 to be dangerous. 203 215 </t> 204 216 </section> -
draft-ietf-httpbis/latest/p5-range.html
r1767 r1770 449 449 } 450 450 @bottom-center { 451 content: "Expires January 1 4, 2013";451 content: "Expires January 15, 2013"; 452 452 } 453 453 @bottom-right { … … 492 492 <meta name="dct.creator" content="Reschke, J. F."> 493 493 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest"> 494 <meta name="dct.issued" scheme="ISO8601" content="2012-07-1 3">494 <meta name="dct.issued" scheme="ISO8601" content="2012-07-14"> 495 495 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 496 496 <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 requests and the rules for constructing and combining responses to those requests."> … … 518 518 </tr> 519 519 <tr> 520 <td class="left">Expires: January 1 4, 2013</td>520 <td class="left">Expires: January 15, 2013</td> 521 521 <td class="right">J. Reschke, Editor</td> 522 522 </tr> … … 527 527 <tr> 528 528 <td class="left"></td> 529 <td class="right">July 1 3, 2012</td>529 <td class="right">July 14, 2012</td> 530 530 </tr> 531 531 </tbody> … … 554 554 in progress”. 555 555 </p> 556 <p>This Internet-Draft will expire on January 1 4, 2013.</p>556 <p>This Internet-Draft will expire on January 15, 2013.</p> 557 557 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 558 558 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 671 671 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>. 672 672 </p> 673 <p id="rfc.section.1.1.p.2">This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients, 674 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. 675 </p> 676 <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 677 SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable. 678 </p> 679 <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. 680 </p> 681 <p id="rfc.section.1.1.p.5">Unless noted otherwise, Recipients <em class="bcp14">MUST</em> be able to parse all protocol elements matching the ABNF rules defined for them and <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 682 mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require 683 different error handling strategies; for example, a Web browser might wish to transparently recover from a response where 684 the <a href="p2-semantics.html#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of error recovery 685 could lead to dangerous consequences. 673 <p id="rfc.section.1.1.p.2">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP 674 requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways, 675 or caches, depending on what behavior is being constrained by the requirement. 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. 676 </p> 677 <p id="rfc.section.1.1.p.3">The verb "generate" is used instead of "send" where a requirement differentiates between creating a protocol element and merely 678 forwarding a received element downstream. 679 </p> 680 <p id="rfc.section.1.1.p.4">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes 681 in HTTP. Note that SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable. 682 </p> 683 <p id="rfc.section.1.1.p.5">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 do not match the grammar defined by the ABNF rules for those protocol elements that are applicable 684 to the sender's role. If a received protocol element is processed, the recipient <em class="bcp14">MUST</em> be able to parse any value that would match the ABNF rules for that protocol element, excluding only those rules not applicable 685 to the recipient's role. 686 </p> 687 <p id="rfc.section.1.1.p.6">Unless noted otherwise, a recipient <em class="bcp14">MAY</em> attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms 688 except when they have a direct impact on security, since different applications of the protocol require different error handling 689 strategies. For example, a Web browser might wish to transparently recover from a response where the <a href="p2-semantics.html#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereas a systems control client might consider any form of error recovery 690 to be dangerous. 686 691 </p> 687 692 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="notation" href="#notation">Syntax Notation</a></h2> -
draft-ietf-httpbis/latest/p5-range.xml
r1767 r1770 165 165 </t> 166 166 <t> 167 This document defines conformance criteria for several roles in HTTP 168 communication, including Senders, Recipients, Clients, Servers, User-Agents, 169 Origin Servers, Intermediaries, Proxies and Gateways. See &architecture; 170 for definitions of these terms. 167 This specification targets conformance criteria according to the role of 168 a participant in HTTP communication. Hence, HTTP requirements are placed 169 on senders, recipients, clients, servers, user agents, intermediaries, 170 origin servers, proxies, gateways, or caches, depending on what behavior 171 is being constrained by the requirement. See &architecture; for definitions 172 of these terms. 173 </t> 174 <t> 175 The verb "generate" is used instead of "send" where a requirement 176 differentiates between creating a protocol element and merely forwarding a 177 received element downstream. 171 178 </t> 172 179 <t> 173 180 An implementation is considered conformant if it complies with all of the 174 requirements associated with its role(s). Note that SHOULD-level requirements 175 are relevant here, unless one of the documented exceptions is applicable. 181 requirements associated with the roles it partakes in HTTP. Note that 182 SHOULD-level requirements are relevant here, unless one of the documented 183 exceptions is applicable. 176 184 </t> 177 185 <t> 178 186 This document also uses ABNF to define valid protocol elements 179 (<xref target="notation"/>). In addition to the prose requirements placed 180 upon them, Senders &MUST-NOT; generate protocol elements that are invalid. 181 </t> 182 <t> 183 Unless noted otherwise, Recipients &MUST; be able to parse all protocol 184 elements matching the ABNF rules defined for them and &MAY; take steps to 185 recover a usable protocol element from an invalid construct. However, HTTP does not define 186 specific error handling mechanisms, except in cases where it has direct 187 impact on security. This is because different uses of the protocol require 188 different error handling strategies; for example, a Web browser might wish to 189 transparently recover from a response where the <x:ref>Location</x:ref> 190 header field doesn't parse according to the ABNF, whereby in a systems 191 control protocol using HTTP, this type of error recovery could lead to 192 dangerous consequences. 187 (<xref target="notation"/>). 188 In addition to the prose requirements placed upon them, senders &MUST-NOT; 189 generate protocol elements that do not match the grammar defined by the 190 ABNF rules for those protocol elements that are applicable to the sender's 191 role. If a received protocol element is processed, the recipient &MUST; be 192 able to parse any value that would match the ABNF rules for that protocol 193 element, excluding only those rules not applicable to the recipient's role. 194 </t> 195 <t> 196 Unless noted otherwise, a recipient &MAY; attempt to recover a usable 197 protocol element from an invalid construct. HTTP does not define 198 specific error handling mechanisms except when they have a direct impact 199 on security, since different applications of the protocol require 200 different error handling strategies. For example, a Web browser might 201 wish to transparently recover from a response where the 202 <x:ref>Location</x:ref> header field doesn't parse according to the ABNF, 203 whereas a systems control client might consider any form of error recovery 204 to be dangerous. 193 205 </t> 194 206 </section> -
draft-ietf-httpbis/latest/p6-cache.html
r1769 r1770 787 787 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>. 788 788 </p> 789 <p id="rfc.section.1.3.p.2">This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients, 790 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. 791 </p> 792 <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 793 SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable. 794 </p> 795 <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. 796 </p> 797 <p id="rfc.section.1.3.p.5">Unless noted otherwise, Recipients <em class="bcp14">MUST</em> be able to parse all protocol elements matching the ABNF rules defined for them and <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 798 mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require 799 different error handling strategies; for example, a Web browser might wish to transparently recover from a response where 800 the <a href="p2-semantics.html#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of error recovery 801 could lead to dangerous consequences. 789 <p id="rfc.section.1.3.p.2">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP 790 requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways, 791 or caches, depending on what behavior is being constrained by the requirement. 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. 792 </p> 793 <p id="rfc.section.1.3.p.3">The verb "generate" is used instead of "send" where a requirement differentiates between creating a protocol element and merely 794 forwarding a received element downstream. 795 </p> 796 <p id="rfc.section.1.3.p.4">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes 797 in HTTP. Note that SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable. 798 </p> 799 <p id="rfc.section.1.3.p.5">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 do not match the grammar defined by the ABNF rules for those protocol elements that are applicable 800 to the sender's role. If a received protocol element is processed, the recipient <em class="bcp14">MUST</em> be able to parse any value that would match the ABNF rules for that protocol element, excluding only those rules not applicable 801 to the recipient's role. 802 </p> 803 <p id="rfc.section.1.3.p.6">Unless noted otherwise, a recipient <em class="bcp14">MAY</em> attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms 804 except when they have a direct impact on security, since different applications of the protocol require different error handling 805 strategies. For example, a Web browser might wish to transparently recover from a response where the <a href="p2-semantics.html#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereas a systems control client might consider any form of error recovery 806 to be dangerous. 802 807 </p> 803 808 <h2 id="rfc.section.1.4"><a href="#rfc.section.1.4">1.4</a> <a id="notation" href="#notation">Syntax Notation</a></h2> -
draft-ietf-httpbis/latest/p6-cache.xml
r1769 r1770 310 310 </t> 311 311 <t> 312 This document defines conformance criteria for several roles in HTTP 313 communication, including Senders, Recipients, Clients, Servers, User-Agents, 314 Origin Servers, Intermediaries, Proxies and Gateways. See &architecture; 315 for definitions of these terms. 312 This specification targets conformance criteria according to the role of 313 a participant in HTTP communication. Hence, HTTP requirements are placed 314 on senders, recipients, clients, servers, user agents, intermediaries, 315 origin servers, proxies, gateways, or caches, depending on what behavior 316 is being constrained by the requirement. See &architecture; for definitions 317 of these terms. 318 </t> 319 <t> 320 The verb "generate" is used instead of "send" where a requirement 321 differentiates between creating a protocol element and merely forwarding a 322 received element downstream. 316 323 </t> 317 324 <t> 318 325 An implementation is considered conformant if it complies with all of the 319 requirements associated with its role(s). Note that SHOULD-level requirements 320 are relevant here, unless one of the documented exceptions is applicable. 326 requirements associated with the roles it partakes in HTTP. Note that 327 SHOULD-level requirements are relevant here, unless one of the documented 328 exceptions is applicable. 321 329 </t> 322 330 <t> 323 331 This document also uses ABNF to define valid protocol elements 324 (<xref target="notation"/>). In addition to the prose requirements placed 325 upon them, Senders &MUST-NOT; generate protocol elements that are invalid. 326 </t> 327 <t> 328 Unless noted otherwise, Recipients &MUST; be able to parse all protocol 329 elements matching the ABNF rules defined for them and &MAY; take steps to 330 recover a usable protocol element from an invalid construct. However, HTTP does not define 331 specific error handling mechanisms, except in cases where it has direct 332 impact on security. This is because different uses of the protocol require 333 different error handling strategies; for example, a Web browser might wish to 334 transparently recover from a response where the <x:ref>Location</x:ref> 335 header field doesn't parse according to the ABNF, whereby in a systems 336 control protocol using HTTP, this type of error recovery could lead to 337 dangerous consequences. 332 (<xref target="notation"/>). 333 In addition to the prose requirements placed upon them, senders &MUST-NOT; 334 generate protocol elements that do not match the grammar defined by the 335 ABNF rules for those protocol elements that are applicable to the sender's 336 role. If a received protocol element is processed, the recipient &MUST; be 337 able to parse any value that would match the ABNF rules for that protocol 338 element, excluding only those rules not applicable to the recipient's role. 339 </t> 340 <t> 341 Unless noted otherwise, a recipient &MAY; attempt to recover a usable 342 protocol element from an invalid construct. HTTP does not define 343 specific error handling mechanisms except when they have a direct impact 344 on security, since different applications of the protocol require 345 different error handling strategies. For example, a Web browser might 346 wish to transparently recover from a response where the 347 <x:ref>Location</x:ref> header field doesn't parse according to the ABNF, 348 whereas a systems control client might consider any form of error recovery 349 to be dangerous. 338 350 </t> 339 351 </section> -
draft-ietf-httpbis/latest/p7-auth.html
r1764 r1770 449 449 } 450 450 @bottom-center { 451 content: "Expires January 1 4, 2013";451 content: "Expires January 15, 2013"; 452 452 } 453 453 @bottom-right { … … 489 489 <meta name="dct.creator" content="Reschke, J. F."> 490 490 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest"> 491 <meta name="dct.issued" scheme="ISO8601" content="2012-07-1 3">491 <meta name="dct.issued" scheme="ISO8601" content="2012-07-14"> 492 492 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 493 493 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. 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."> … … 520 520 </tr> 521 521 <tr> 522 <td class="left">Expires: January 1 4, 2013</td>522 <td class="left">Expires: January 15, 2013</td> 523 523 <td class="right">greenbytes</td> 524 524 </tr> 525 525 <tr> 526 526 <td class="left"></td> 527 <td class="right">July 1 3, 2012</td>527 <td class="right">July 14, 2012</td> 528 528 </tr> 529 529 </tbody> … … 552 552 in progress”. 553 553 </p> 554 <p>This Internet-Draft will expire on January 1 4, 2013.</p>554 <p>This Internet-Draft will expire on January 15, 2013.</p> 555 555 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 556 556 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 636 636 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>. 637 637 </p> 638 <p id="rfc.section.1.1.p.2">This document defines conformance criteria for several roles in HTTP communication, including Senders, Recipients, Clients, 639 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. 640 </p> 641 <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 642 SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable. 643 </p> 644 <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. 645 </p> 646 <p id="rfc.section.1.1.p.5">Unless noted otherwise, Recipients <em class="bcp14">MUST</em> be able to parse all protocol elements matching the ABNF rules defined for them and <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 647 mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require 648 different error handling strategies; for example, a Web browser might wish to transparently recover from a response where 649 the <a href="p2-semantics.html#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of error recovery 650 could lead to dangerous consequences. 638 <p id="rfc.section.1.1.p.2">This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, HTTP 639 requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways, 640 or caches, depending on what behavior is being constrained by the requirement. 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. 641 </p> 642 <p id="rfc.section.1.1.p.3">The verb "generate" is used instead of "send" where a requirement differentiates between creating a protocol element and merely 643 forwarding a received element downstream. 644 </p> 645 <p id="rfc.section.1.1.p.4">An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes 646 in HTTP. Note that SHOULD-level requirements are relevant here, unless one of the documented exceptions is applicable. 647 </p> 648 <p id="rfc.section.1.1.p.5">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 do not match the grammar defined by the ABNF rules for those protocol elements that are applicable 649 to the sender's role. If a received protocol element is processed, the recipient <em class="bcp14">MUST</em> be able to parse any value that would match the ABNF rules for that protocol element, excluding only those rules not applicable 650 to the recipient's role. 651 </p> 652 <p id="rfc.section.1.1.p.6">Unless noted otherwise, a recipient <em class="bcp14">MAY</em> attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms 653 except when they have a direct impact on security, since different applications of the protocol require different error handling 654 strategies. For example, a Web browser might wish to transparently recover from a response where the <a href="p2-semantics.html#header.location" class="smpl">Location</a> header field doesn't parse according to the ABNF, whereas a systems control client might consider any form of error recovery 655 to be dangerous. 651 656 </p> 652 657 <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a> <a id="notation" href="#notation">Syntax Notation</a></h2> -
draft-ietf-httpbis/latest/p7-auth.xml
r1764 r1770 151 151 </t> 152 152 <t> 153 This document defines conformance criteria for several roles in HTTP 154 communication, including Senders, Recipients, Clients, Servers, User-Agents, 155 Origin Servers, Intermediaries, Proxies and Gateways. See &architecture; 156 for definitions of these terms. 153 This specification targets conformance criteria according to the role of 154 a participant in HTTP communication. Hence, HTTP requirements are placed 155 on senders, recipients, clients, servers, user agents, intermediaries, 156 origin servers, proxies, gateways, or caches, depending on what behavior 157 is being constrained by the requirement. See &architecture; for definitions 158 of these terms. 159 </t> 160 <t> 161 The verb "generate" is used instead of "send" where a requirement 162 differentiates between creating a protocol element and merely forwarding a 163 received element downstream. 157 164 </t> 158 165 <t> 159 166 An implementation is considered conformant if it complies with all of the 160 requirements associated with its role(s). Note that SHOULD-level requirements 161 are relevant here, unless one of the documented exceptions is applicable. 167 requirements associated with the roles it partakes in HTTP. Note that 168 SHOULD-level requirements are relevant here, unless one of the documented 169 exceptions is applicable. 162 170 </t> 163 171 <t> 164 172 This document also uses ABNF to define valid protocol elements 165 (<xref target="notation"/>). In addition to the prose requirements placed 166 upon them, Senders &MUST-NOT; generate protocol elements that are invalid. 167 </t> 168 <t> 169 Unless noted otherwise, Recipients &MUST; be able to parse all protocol 170 elements matching the ABNF rules defined for them and &MAY; take steps to 171 recover a usable protocol element from an invalid construct. However, HTTP does not define 172 specific error handling mechanisms, except in cases where it has direct 173 impact on security. This is because different uses of the protocol require 174 different error handling strategies; for example, a Web browser might wish to 175 transparently recover from a response where the <x:ref>Location</x:ref> 176 header field doesn't parse according to the ABNF, whereby in a systems 177 control protocol using HTTP, this type of error recovery could lead to 178 dangerous consequences. 173 (<xref target="notation"/>). 174 In addition to the prose requirements placed upon them, senders &MUST-NOT; 175 generate protocol elements that do not match the grammar defined by the 176 ABNF rules for those protocol elements that are applicable to the sender's 177 role. If a received protocol element is processed, the recipient &MUST; be 178 able to parse any value that would match the ABNF rules for that protocol 179 element, excluding only those rules not applicable to the recipient's role. 180 </t> 181 <t> 182 Unless noted otherwise, a recipient &MAY; attempt to recover a usable 183 protocol element from an invalid construct. HTTP does not define 184 specific error handling mechanisms except when they have a direct impact 185 on security, since different applications of the protocol require 186 different error handling strategies. For example, a Web browser might 187 wish to transparently recover from a response where the 188 <x:ref>Location</x:ref> header field doesn't parse according to the ABNF, 189 whereas a systems control client might consider any form of error recovery 190 to be dangerous. 179 191 </t> 180 192 </section>
Note: See TracChangeset
for help on using the changeset viewer.