Changeset 1684
- Timestamp:
- 22/06/12 07:12:17 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 10 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r1683 r1684 449 449 } 450 450 @bottom-center { 451 content: "Expires December 2 3, 2012";451 content: "Expires December 24, 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 1">499 <meta name="dct.issued" scheme="ISO8601" content="2012-06-22"> 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 3, 2012</td>530 <td class="left">Expires: December 24, 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 1, 2012</td>535 <td class="right">June 22, 2012</td> 536 536 </tr> 537 537 </tbody> … … 563 563 in progress”. 564 564 </p> 565 <p>This Internet-Draft will expire on December 2 3, 2012.</p>565 <p>This Internet-Draft will expire on December 24, 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> … … 858 858 <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 859 859 mechanisms, except in cases where it has direct impact on security. This is because different uses of the protocol require 860 different error handling strategies; for example, a Web browser m ay wish to transparently recover from a response where the861 Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of862 error recovery could lead to dangerous consequences.860 different error handling strategies; for example, a Web browser might wish to transparently recover from a response where 861 the Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type 862 of error recovery could lead to dangerous consequences. 863 863 </p> 864 864 <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
r1683 r1684 305 305 specific error handling mechanisms, except in cases where it has direct 306 306 impact on security. This is because different uses of the protocol require 307 different error handling strategies; for example, a Web browser m aywish to307 different error handling strategies; for example, a Web browser might wish to 308 308 transparently recover from a response where the Location header field 309 309 doesn't parse according to the ABNF, whereby in a systems control protocol -
draft-ietf-httpbis/latest/p4-conditional.html
r1682 r1684 449 449 } 450 450 @bottom-center { 451 content: "Expires December 2 3, 2012";451 content: "Expires December 24, 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-2 1">492 <meta name="dct.issued" scheme="ISO8601" content="2012-06-22"> 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 2 3, 2012</td>518 <td class="left">Expires: December 24, 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 2 1, 2012</td>527 <td class="right">June 22, 2012</td> 528 528 </tr> 529 529 </tbody> … … 555 555 in progress”. 556 556 </p> 557 <p>This Internet-Draft will expire on December 2 3, 2012.</p>557 <p>This Internet-Draft will expire on December 24, 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> … … 660 660 <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 different error handling strategies; for example, a Web browser m ay wish to transparently recover from a response where the663 Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of664 error recovery could lead to dangerous consequences.662 different error handling strategies; for example, a Web browser might wish to transparently recover from a response where 663 the Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type 664 of error recovery could lead to dangerous consequences. 665 665 </p> 666 666 <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
r1682 r1684 197 197 specific error handling mechanisms, except in cases where it has direct 198 198 impact on security. This is because different uses of the protocol require 199 different error handling strategies; for example, a Web browser m aywish to199 different error handling strategies; for example, a Web browser might wish to 200 200 transparently recover from a response where the Location header field 201 201 doesn't parse according to the ABNF, whereby in a systems control protocol -
draft-ietf-httpbis/latest/p5-range.html
r1682 r1684 449 449 } 450 450 @bottom-center { 451 content: "Expires December 2 3, 2012";451 content: "Expires December 24, 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-2 1">494 <meta name="dct.issued" scheme="ISO8601" content="2012-06-22"> 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 2 3, 2012</td>520 <td class="left">Expires: December 24, 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 2 1, 2012</td>529 <td class="right">June 22, 2012</td> 530 530 </tr> 531 531 </tbody> … … 555 555 in progress”. 556 556 </p> 557 <p>This Internet-Draft will expire on December 2 3, 2012.</p>557 <p>This Internet-Draft will expire on December 24, 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> … … 682 682 <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 different error handling strategies; for example, a Web browser m ay wish to transparently recover from a response where the685 Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of686 error recovery could lead to dangerous consequences.684 different error handling strategies; for example, a Web browser might wish to transparently recover from a response where 685 the Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type 686 of error recovery could lead to dangerous consequences. 687 687 </p> 688 688 <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
r1682 r1684 187 187 specific error handling mechanisms, except in cases where it has direct 188 188 impact on security. This is because different uses of the protocol require 189 different error handling strategies; for example, a Web browser m aywish to189 different error handling strategies; for example, a Web browser might wish to 190 190 transparently recover from a response where the Location header field 191 191 doesn't parse according to the ABNF, whereby in a systems control protocol -
draft-ietf-httpbis/latest/p6-cache.html
r1682 r1684 452 452 } 453 453 @bottom-center { 454 content: "Expires December 2 3, 2012";454 content: "Expires December 24, 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-2 1">496 <meta name="dct.issued" scheme="ISO8601" content="2012-06-22"> 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 2 3, 2012</td>522 <td class="left">Expires: December 24, 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 2 1, 2012</td>539 <td class="right">June 22, 2012</td> 540 540 </tr> 541 541 </tbody> … … 567 567 in progress”. 568 568 </p> 569 <p>This Internet-Draft will expire on December 2 3, 2012.</p>569 <p>This Internet-Draft will expire on December 24, 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> … … 774 774 <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 different error handling strategies; for example, a Web browser m ay wish to transparently recover from a response where the777 Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of778 error recovery could lead to dangerous consequences.776 different error handling strategies; for example, a Web browser might wish to transparently recover from a response where 777 the Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type 778 of error recovery could lead to dangerous consequences. 779 779 </p> 780 780 <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
r1682 r1684 331 331 specific error handling mechanisms, except in cases where it has direct 332 332 impact on security. This is because different uses of the protocol require 333 different error handling strategies; for example, a Web browser m aywish to333 different error handling strategies; for example, a Web browser might wish to 334 334 transparently recover from a response where the Location header field 335 335 doesn't parse according to the ABNF, whereby in a systems control protocol -
draft-ietf-httpbis/latest/p7-auth.html
r1682 r1684 449 449 } 450 450 @bottom-center { 451 content: "Expires December 2 3, 2012";451 content: "Expires December 24, 2012"; 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-06-2 1">491 <meta name="dct.issued" scheme="ISO8601" content="2012-06-22"> 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: December 2 3, 2012</td>522 <td class="left">Expires: December 24, 2012</td> 523 523 <td class="right">greenbytes</td> 524 524 </tr> 525 525 <tr> 526 526 <td class="left"></td> 527 <td class="right">June 2 1, 2012</td>527 <td class="right">June 22, 2012</td> 528 528 </tr> 529 529 </tbody> … … 553 553 in progress”. 554 554 </p> 555 <p>This Internet-Draft will expire on December 2 3, 2012.</p>555 <p>This Internet-Draft will expire on December 24, 2012.</p> 556 556 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 557 557 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 647 647 <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 different error handling strategies; for example, a Web browser m ay wish to transparently recover from a response where the650 Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type of651 error recovery could lead to dangerous consequences.649 different error handling strategies; for example, a Web browser might wish to transparently recover from a response where 650 the Location header field doesn't parse according to the ABNF, whereby in a systems control protocol using HTTP, this type 651 of error recovery could lead to dangerous consequences. 652 652 </p> 653 653 <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
r1682 r1684 172 172 specific error handling mechanisms, except in cases where it has direct 173 173 impact on security. This is because different uses of the protocol require 174 different error handling strategies; for example, a Web browser m aywish to174 different error handling strategies; for example, a Web browser might wish to 175 175 transparently recover from a response where the Location header field 176 176 doesn't parse according to the ABNF, whereby in a systems control protocol
Note: See TracChangeset
for help on using the changeset viewer.