Changeset 1682 for draft-ietf-httpbis
- Timestamp:
- 21/06/12 09:01:49 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 13 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1677 r1682 449 449 } 450 450 @bottom-center { 451 content: "Expires December 17, 2012";451 content: "Expires December 23, 2012"; 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-06- 15">493 <meta name="dct.issued" scheme="ISO8601" content="2012-06-21"> 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: December 17, 2012</td>525 <td class="left">Expires: December 23, 2012</td> 526 526 <td class="right">greenbytes</td> 527 527 </tr> 528 528 <tr> 529 529 <td class="left"></td> 530 <td class="right">June 15, 2012</td>530 <td class="right">June 21, 2012</td> 531 531 </tr> 532 532 </tbody> … … 561 561 in progress”. 562 562 </p> 563 <p>This Internet-Draft will expire on December 17, 2012.</p>563 <p>This Internet-Draft will expire on December 23, 2012.</p> 564 564 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 565 565 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 959 959 <p id="rfc.section.2.5.p.3">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. 960 960 </p> 961 <p id="rfc.section.2.5.p.4">Unless otherwise noted, recipients<em class="bcp14">MAY</em> attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms961 <p id="rfc.section.2.5.p.4">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> attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms 962 962 except when they have a direct impact on security, since different applications of the protocol require different error handling 963 963 strategies. For example, a Web browser might wish to transparently recover from a response where the Location header field … … 3530 3530 <ul> 3531 3531 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/346">http://tools.ietf.org/wg/httpbis/trac/ticket/346</a>>: "make IANA policy definitions consistent" 3532 </li> 3533 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/361">http://tools.ietf.org/wg/httpbis/trac/ticket/361</a>>: "ABNF requirements for recipients" 3532 3534 </li> 3533 3535 </ul> -
draft-ietf-httpbis/latest/p1-messaging.xml
r1677 r1682 602 602 </t> 603 603 <t> 604 Unless otherwise noted, recipients &MAY; attempt to recover a usable 604 Unless noted otherwise, recipients &MUST; be able to parse all protocol 605 elements matching the ABNF rules defined for them and &MAY; attempt to recover a usable 605 606 protocol element from an invalid construct. HTTP does not define 606 607 specific error handling mechanisms except when they have a direct impact … … 5823 5824 "make IANA policy definitions consistent" 5824 5825 </t> 5826 <t> 5827 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/361"/>: 5828 "ABNF requirements for recipients" 5829 </t> 5825 5830 </list> 5826 5831 </t> -
draft-ietf-httpbis/latest/p2-semantics.html
r1680 r1682 449 449 } 450 450 @bottom-center { 451 content: "Expires December 2 2, 2012";451 content: "Expires December 23, 2012"; 452 452 } 453 453 @bottom-right { … … 497 497 <meta name="dct.creator" content="Reschke, J. F."> 498 498 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 499 <meta name="dct.issued" scheme="ISO8601" content="2012-06-2 0">499 <meta name="dct.issued" scheme="ISO8601" content="2012-06-21"> 500 500 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 501 501 <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. Furthermore, it defines HTTP message content, metadata, and content negotiation."> … … 528 528 </tr> 529 529 <tr> 530 <td class="left">Expires: December 2 2, 2012</td>530 <td class="left">Expires: December 23, 2012</td> 531 531 <td class="right">greenbytes</td> 532 532 </tr> 533 533 <tr> 534 534 <td class="left"></td> 535 <td class="right">June 2 0, 2012</td>535 <td class="right">June 21, 2012</td> 536 536 </tr> 537 537 </tbody> … … 552 552 <p>The current issues list is at <<a href="http://tools.ietf.org/wg/httpbis/trac/report/3">http://tools.ietf.org/wg/httpbis/trac/report/3</a>> and related documents (including fancy diffs) can be found at <<a href="http://tools.ietf.org/wg/httpbis/">http://tools.ietf.org/wg/httpbis/</a>>. 553 553 </p> 554 <p>The changes in this draft are summarized in <a href="#changes.since.19" title="Since draft-ietf-httpbis-p2-semantics-19 ">Appendix E.40</a>.554 <p>The changes in this draft are summarized in <a href="#changes.since.19" title="Since draft-ietf-httpbis-p2-semantics-19 and draft-ietf-httpbis-p3-payload-19">Appendix E.40</a>. 555 555 </p> 556 556 <h1><a id="rfc.status" href="#rfc.status">Status of This Memo</a></h1> … … 563 563 in progress”. 564 564 </p> 565 <p>This Internet-Draft will expire on December 2 2, 2012.</p>565 <p>This Internet-Draft will expire on December 23, 2012.</p> 566 566 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 567 567 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 807 807 <li>E.38 <a href="#changes.since.18">Since draft-ietf-httpbis-p2-semantics-18</a></li> 808 808 <li>E.39 <a href="#changes.3.since.18">Since draft-ietf-httpbis-p3-payload-18</a></li> 809 <li>E.40 <a href="#changes.since.19">Since draft-ietf-httpbis-p2-semantics-19</a></li> 810 <li>E.41 <a href="#changes.3.since.19">Since draft-ietf-httpbis-p3-payload-19</a></li> 809 <li>E.40 <a href="#changes.since.19">Since draft-ietf-httpbis-p2-semantics-19 and draft-ietf-httpbis-p3-payload-19</a></li> 811 810 </ul> 812 811 </li> … … 857 856 <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. 858 857 </p> 859 <p id="rfc.section.1.2.p.5">Unless noted otherwise, Recipients <em class="bcp14">M AY</em> take steps to recover a usable protocol element from an invalid construct. However, HTTP does not define specific error handling858 <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 860 859 mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require 861 860 different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the … … 4729 4728 </li> 4730 4729 </ul> 4731 <h2 id="rfc.section.E.40"><a href="#rfc.section.E.40">E.40</a> <a id="changes.since.19" href="#changes.since.19">Since draft-ietf-httpbis-p2-semantics-19 </a></h2>4730 <h2 id="rfc.section.E.40"><a href="#rfc.section.E.40">E.40</a> <a id="changes.since.19" href="#changes.since.19">Since draft-ietf-httpbis-p2-semantics-19 and draft-ietf-httpbis-p3-payload-19</a></h2> 4732 4731 <p id="rfc.section.E.40.p.1">Closed issues: </p> 4733 4732 <ul> 4734 4733 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/312">http://tools.ietf.org/wg/httpbis/trac/ticket/312</a>>: "should there be a permanent variant of 307" 4735 4734 </li> 4736 </ul>4737 <h2 id="rfc.section.E.41"><a href="#rfc.section.E.41">E.41</a> <a id="changes.3.since.19" href="#changes.3.since.19">Since draft-ietf-httpbis-p3-payload-19</a></h2>4738 < p id="rfc.section.E.41.p.1">None yet.</p>4735 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/361">http://tools.ietf.org/wg/httpbis/trac/ticket/361</a>>: "ABNF requirements for recipients" 4736 </li> 4737 </ul> 4739 4738 <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> 4740 4739 <p class="noprint"><a href="#rfc.index.1">1</a> <a href="#rfc.index.2">2</a> <a href="#rfc.index.3">3</a> <a href="#rfc.index.4">4</a> <a href="#rfc.index.5">5</a> <a href="#rfc.index.A">A</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.D">D</a> <a href="#rfc.index.E">E</a> <a href="#rfc.index.F">F</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.O">O</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.T">T</a> <a href="#rfc.index.U">U</a> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1680 r1682 300 300 </t> 301 301 <t> 302 Unless noted otherwise, Recipients &MAY; take steps to recover a usable 303 protocol element from an invalid construct. However, HTTP does not define 302 Unless noted otherwise, Recipients &MUST; be able to parse all protocol 303 elements matching the ABNF rules defined for them and &MAY; take steps to 304 recover a usable protocol element from an invalid construct. However, HTTP does not define 304 305 specific error handling mechanisms, except in cases where it has direct 305 306 impact on security. This is because different uses of the protocol require … … 6764 6765 </section> 6765 6766 6766 <section title="Since draft-ietf-httpbis-p2-semantics-19 " anchor="changes.since.19">6767 <section title="Since draft-ietf-httpbis-p2-semantics-19 and draft-ietf-httpbis-p3-payload-19" anchor="changes.since.19"> 6767 6768 <t> 6768 6769 Closed issues: … … 6772 6773 "should there be a permanent variant of 307" 6773 6774 </t> 6775 <t> 6776 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/361"/>: 6777 "ABNF requirements for recipients" 6778 </t> 6774 6779 </list> 6775 </t>6776 </section>6777 6778 <section title="Since draft-ietf-httpbis-p3-payload-19" anchor="changes.3.since.19">6779 <t>6780 None yet.6781 6780 </t> 6782 6781 </section> -
draft-ietf-httpbis/latest/p3-payload.html
r1679 r1682 374 374 } 375 375 @bottom-center { 376 content: "Expires December 2 1, 2012";376 content: "Expires December 23, 2012"; 377 377 } 378 378 @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-p3-payload-latest"> 406 <meta name="dct.issued" scheme="ISO8601" content="2012-06- 19">406 <meta name="dct.issued" scheme="ISO8601" content="2012-06-21"> 407 407 <meta name="dct.abstract" content="This part is now obsolete. Please see HTTPbis, Part 2."> 408 408 <meta name="description" content="This part is now obsolete. Please see HTTPbis, Part 2."> … … 424 424 </tr> 425 425 <tr> 426 <td class="left">Expires: December 2 1, 2012</td>426 <td class="left">Expires: December 23, 2012</td> 427 427 <td class="right">W3C</td> 428 428 </tr> … … 437 437 <tr> 438 438 <td class="left"></td> 439 <td class="right">June 19, 2012</td>439 <td class="right">June 21, 2012</td> 440 440 </tr> 441 441 </tbody> … … 453 453 in progress”. 454 454 </p> 455 <p>This Internet-Draft will expire on December 2 1, 2012.</p>455 <p>This Internet-Draft will expire on December 23, 2012.</p> 456 456 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 457 457 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> -
draft-ietf-httpbis/latest/p4-conditional.html
r1667 r1682 449 449 } 450 450 @bottom-center { 451 content: "Expires December 3, 2012";451 content: "Expires December 23, 2012"; 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-06- 01">492 <meta name="dct.issued" scheme="ISO8601" content="2012-06-21"> 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: December 3, 2012</td>518 <td class="left">Expires: December 23, 2012</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">June 1, 2012</td>527 <td class="right">June 21, 2012</td> 528 528 </tr> 529 529 </tbody> … … 555 555 in progress”. 556 556 </p> 557 <p>This Internet-Draft will expire on December 3, 2012.</p>557 <p>This Internet-Draft will expire on December 23, 2012.</p> 558 558 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 559 559 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 658 658 <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. 659 659 </p> 660 <p id="rfc.section.1.1.p.5">Unless noted otherwise, Recipients <em class="bcp14">M AY</em> take steps to recover a usable protocol element from an invalid construct. However, HTTP does not define specific error handling660 <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 661 661 mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require 662 662 different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the … … 1339 1339 </p> 1340 1340 <h2 id="rfc.section.C.1"><a href="#rfc.section.C.1">C.1</a> <a id="changes.since.19" href="#changes.since.19">Since draft-ietf-httpbis-p4-conditional-19</a></h2> 1341 <p id="rfc.section.C.1.p.1">None yet.</p> 1341 <p id="rfc.section.C.1.p.1">Closed issues: </p> 1342 <ul> 1343 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/361">http://tools.ietf.org/wg/httpbis/trac/ticket/361</a>>: "ABNF requirements for recipients" 1344 </li> 1345 </ul> 1342 1346 <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> 1343 1347 <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> -
draft-ietf-httpbis/latest/p4-conditional.xml
r1667 r1682 192 192 </t> 193 193 <t> 194 Unless noted otherwise, Recipients &MAY; take steps to recover a usable 195 protocol element from an invalid construct. However, HTTP does not define 194 Unless noted otherwise, Recipients &MUST; be able to parse all protocol 195 elements matching the ABNF rules defined for them and &MAY; take steps to 196 recover a usable protocol element from an invalid construct. However, HTTP does not define 196 197 specific error handling mechanisms, except in cases where it has direct 197 198 impact on security. This is because different uses of the protocol require … … 1409 1410 <section title="Since draft-ietf-httpbis-p4-conditional-19" anchor="changes.since.19"> 1410 1411 <t> 1411 None yet. 1412 Closed issues: 1413 <list style="symbols"> 1414 <t> 1415 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/361"/>: 1416 "ABNF requirements for recipients" 1417 </t> 1418 </list> 1412 1419 </t> 1413 1420 </section> -
draft-ietf-httpbis/latest/p5-range.html
r1667 r1682 449 449 } 450 450 @bottom-center { 451 content: "Expires December 3, 2012";451 content: "Expires December 23, 2012"; 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-06- 01">494 <meta name="dct.issued" scheme="ISO8601" content="2012-06-21"> 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: December 3, 2012</td>520 <td class="left">Expires: December 23, 2012</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">June 1, 2012</td>529 <td class="right">June 21, 2012</td> 530 530 </tr> 531 531 </tbody> … … 555 555 in progress”. 556 556 </p> 557 <p>This Internet-Draft will expire on December 3, 2012.</p>557 <p>This Internet-Draft will expire on December 23, 2012.</p> 558 558 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 559 559 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 680 680 <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. 681 681 </p> 682 <p id="rfc.section.1.1.p.5">Unless noted otherwise, Recipients <em class="bcp14">M AY</em> take steps to recover a usable protocol element from an invalid construct. However, HTTP does not define specific error handling682 <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 683 683 mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require 684 684 different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the … … 1493 1493 <ul> 1494 1494 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/358">http://tools.ietf.org/wg/httpbis/trac/ticket/358</a>>: "ABNF list expansion code problem" 1495 </li> 1496 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/361">http://tools.ietf.org/wg/httpbis/trac/ticket/361</a>>: "ABNF requirements for recipients" 1495 1497 </li> 1496 1498 </ul> -
draft-ietf-httpbis/latest/p5-range.xml
r1667 r1682 182 182 </t> 183 183 <t> 184 Unless noted otherwise, Recipients &MAY; take steps to recover a usable 185 protocol element from an invalid construct. However, HTTP does not define 184 Unless noted otherwise, Recipients &MUST; be able to parse all protocol 185 elements matching the ABNF rules defined for them and &MAY; take steps to 186 recover a usable protocol element from an invalid construct. However, HTTP does not define 186 187 specific error handling mechanisms, except in cases where it has direct 187 188 impact on security. This is because different uses of the protocol require … … 1717 1718 "ABNF list expansion code problem" 1718 1719 </t> 1720 <t> 1721 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/361"/>: 1722 "ABNF requirements for recipients" 1723 </t> 1719 1724 </list> 1720 1725 </t> -
draft-ietf-httpbis/latest/p6-cache.html
r1675 r1682 452 452 } 453 453 @bottom-center { 454 content: "Expires December 13, 2012";454 content: "Expires December 23, 2012"; 455 455 } 456 456 @bottom-right { … … 494 494 <meta name="dct.creator" content="Reschke, J. F."> 495 495 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest"> 496 <meta name="dct.issued" scheme="ISO8601" content="2012-06- 11">496 <meta name="dct.issued" scheme="ISO8601" content="2012-06-21"> 497 497 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 498 498 <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."> … … 520 520 </tr> 521 521 <tr> 522 <td class="left">Expires: December 13, 2012</td>522 <td class="left">Expires: December 23, 2012</td> 523 523 <td class="right">M. Nottingham, Editor</td> 524 524 </tr> … … 537 537 <tr> 538 538 <td class="left"></td> 539 <td class="right">June 11, 2012</td>539 <td class="right">June 21, 2012</td> 540 540 </tr> 541 541 </tbody> … … 567 567 in progress”. 568 568 </p> 569 <p>This Internet-Draft will expire on December 13, 2012.</p>569 <p>This Internet-Draft will expire on December 23, 2012.</p> 570 570 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 571 571 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 772 772 <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. 773 773 </p> 774 <p id="rfc.section.1.3.p.5">Unless noted otherwise, Recipients <em class="bcp14">M AY</em> take steps to recover a usable protocol element from an invalid construct. However, HTTP does not define specific error handling774 <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 775 775 mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require 776 776 different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the … … 2022 2022 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/356">http://tools.ietf.org/wg/httpbis/trac/ticket/356</a>>: "Spurious 'MAY's" 2023 2023 </li> 2024 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/361">http://tools.ietf.org/wg/httpbis/trac/ticket/361</a>>: "ABNF requirements for recipients" 2025 </li> 2024 2026 </ul> 2025 2027 <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> -
draft-ietf-httpbis/latest/p6-cache.xml
r1675 r1682 326 326 </t> 327 327 <t> 328 Unless noted otherwise, Recipients &MAY; take steps to recover a usable 329 protocol element from an invalid construct. However, HTTP does not define 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 330 331 specific error handling mechanisms, except in cases where it has direct 331 332 impact on security. This is because different uses of the protocol require … … 2507 2508 "Spurious 'MAY's" 2508 2509 </t> 2510 <t> 2511 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/361"/>: 2512 "ABNF requirements for recipients" 2513 </t> 2509 2514 </list> 2510 2515 </t> -
draft-ietf-httpbis/latest/p7-auth.html
r1681 r1682 645 645 <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. 646 646 </p> 647 <p id="rfc.section.1.1.p.5">Unless noted otherwise, Recipients <em class="bcp14">M AY</em> take steps to recover a usable protocol element from an invalid construct. However, HTTP does not define specific error handling647 <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 648 648 mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require 649 649 different error handling strategies; for example, a Web browser may wish to transparently recover from a response where the … … 1150 1150 </li> 1151 1151 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/357">http://tools.ietf.org/wg/httpbis/trac/ticket/357</a>>: "Authentication exchanges" 1152 </li> 1153 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/361">http://tools.ietf.org/wg/httpbis/trac/ticket/361</a>>: "ABNF requirements for recipients" 1152 1154 </li> 1153 1155 </ul> -
draft-ietf-httpbis/latest/p7-auth.xml
r1681 r1682 167 167 </t> 168 168 <t> 169 Unless noted otherwise, Recipients &MAY; take steps to recover a usable 170 protocol element from an invalid construct. However, HTTP does not define 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 171 172 specific error handling mechanisms, except in cases where it has direct 172 173 impact on security. This is because different uses of the protocol require … … 1164 1165 "Authentication exchanges" 1165 1166 </t> 1167 <t> 1168 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/361"/>: 1169 "ABNF requirements for recipients" 1170 </t> 1166 1171 </list> 1167 1172 </t>
Note: See TracChangeset
for help on using the changeset viewer.