Changeset 625 for draft-ietf-httpbis/latest/p1-messaging.xml
- Timestamp:
- 26/07/09 12:11:17 (12 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r624 r625 617 617 </section> 618 618 619 <section title="HTTP Version" anchor="http.version"> 620 <x:anchor-alias value="HTTP-Version"/> 621 <x:anchor-alias value="HTTP-Prot-Name"/> 622 <t> 623 HTTP uses a "<major>.<minor>" numbering scheme to indicate versions 624 of the protocol. The protocol versioning policy is intended to allow 625 the sender to indicate the format of a message and its capacity for 626 understanding further HTTP communication, rather than the features 627 obtained via that communication. No change is made to the version 628 number for the addition of message components which do not affect 629 communication behavior or which only add to extensible field values. 630 The <minor> number is incremented when the changes made to the 631 protocol add features which do not change the general message parsing 632 algorithm, but which may add to the message semantics and imply 633 additional capabilities of the sender. The <major> number is 634 incremented when the format of a message within the protocol is 635 changed. See <xref target="RFC2145"/> for a fuller explanation. 636 </t> 637 <t> 638 The version of an HTTP message is indicated by an HTTP-Version field 639 in the first line of the message. HTTP-Version is case-sensitive. 640 </t> 641 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="HTTP-Version"/><iref primary="true" item="Grammar" subitem="HTTP-Prot-Name"/> 642 <x:ref>HTTP-Version</x:ref> = <x:ref>HTTP-Prot-Name</x:ref> "/" 1*<x:ref>DIGIT</x:ref> "." 1*<x:ref>DIGIT</x:ref> 643 <x:ref>HTTP-Prot-Name</x:ref> = <x:abnf-char-sequence>"HTTP"</x:abnf-char-sequence> ; "HTTP", case-sensitive 644 </artwork></figure> 645 <t> 646 Note that the major and minor numbers &MUST; be treated as separate 647 integers and that each &MAY; be incremented higher than a single digit. 648 Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is 649 lower than HTTP/12.3. Leading zeros &MUST; be ignored by recipients and 650 &MUST-NOT; be sent. 651 </t> 652 <t> 653 An application that sends a request or response message that includes 654 HTTP-Version of "HTTP/1.1" &MUST; be at least conditionally compliant 655 with this specification. Applications that are at least conditionally 656 compliant with this specification &SHOULD; use an HTTP-Version of 657 "HTTP/1.1" in their messages, and &MUST; do so for any message that is 658 not compatible with HTTP/1.0. For more details on when to send 659 specific HTTP-Version values, see <xref target="RFC2145"/>. 660 </t> 661 <t> 662 The HTTP version of an application is the highest HTTP version for 663 which the application is at least conditionally compliant. 664 </t> 665 <t> 666 Proxy and gateway applications need to be careful when forwarding 667 messages in protocol versions different from that of the application. 668 Since the protocol version indicates the protocol capability of the 669 sender, a proxy/gateway &MUST-NOT; send a message with a version 670 indicator which is greater than its actual version. If a higher 671 version request is received, the proxy/gateway &MUST; either downgrade 672 the request version, or respond with an error, or switch to tunnel 673 behavior. 674 </t> 675 <t> 676 Due to interoperability problems with HTTP/1.0 proxies discovered 677 since the publication of <xref target="RFC2068"/>, caching proxies &MUST;, gateways 678 &MAY;, and tunnels &MUST-NOT; upgrade the request to the highest version 679 they support. The proxy/gateway's response to that request &MUST; be in 680 the same major version as the request. 681 </t> 682 <x:note> 683 <t> 684 <x:h>Note:</x:h> Converting between versions of HTTP may involve modification 685 of header fields required or forbidden by the versions involved. 686 </t> 687 </x:note> 688 </section> 689 619 690 <section title="Uniform Resource Identifiers" anchor="uri"> 620 691 <iref primary="true" item="resource"/> … … 1421 1492 1422 1493 <section title="Protocol Parameters" anchor="protocol.parameters"> 1423 1424 <section title="HTTP Version" anchor="http.version">1425 <x:anchor-alias value="HTTP-Version"/>1426 <x:anchor-alias value="HTTP-Prot-Name"/>1427 <t>1428 HTTP uses a "<major>.<minor>" numbering scheme to indicate versions1429 of the protocol. The protocol versioning policy is intended to allow1430 the sender to indicate the format of a message and its capacity for1431 understanding further HTTP communication, rather than the features1432 obtained via that communication. No change is made to the version1433 number for the addition of message components which do not affect1434 communication behavior or which only add to extensible field values.1435 The <minor> number is incremented when the changes made to the1436 protocol add features which do not change the general message parsing1437 algorithm, but which may add to the message semantics and imply1438 additional capabilities of the sender. The <major> number is1439 incremented when the format of a message within the protocol is1440 changed. See <xref target="RFC2145"/> for a fuller explanation.1441 </t>1442 <t>1443 The version of an HTTP message is indicated by an HTTP-Version field1444 in the first line of the message. HTTP-Version is case-sensitive.1445 </t>1446 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="HTTP-Version"/><iref primary="true" item="Grammar" subitem="HTTP-Prot-Name"/>1447 <x:ref>HTTP-Version</x:ref> = <x:ref>HTTP-Prot-Name</x:ref> "/" 1*<x:ref>DIGIT</x:ref> "." 1*<x:ref>DIGIT</x:ref>1448 <x:ref>HTTP-Prot-Name</x:ref> = <x:abnf-char-sequence>"HTTP"</x:abnf-char-sequence> ; "HTTP", case-sensitive1449 </artwork></figure>1450 <t>1451 Note that the major and minor numbers &MUST; be treated as separate1452 integers and that each &MAY; be incremented higher than a single digit.1453 Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is1454 lower than HTTP/12.3. Leading zeros &MUST; be ignored by recipients and1455 &MUST-NOT; be sent.1456 </t>1457 <t>1458 An application that sends a request or response message that includes1459 HTTP-Version of "HTTP/1.1" &MUST; be at least conditionally compliant1460 with this specification. Applications that are at least conditionally1461 compliant with this specification &SHOULD; use an HTTP-Version of1462 "HTTP/1.1" in their messages, and &MUST; do so for any message that is1463 not compatible with HTTP/1.0. For more details on when to send1464 specific HTTP-Version values, see <xref target="RFC2145"/>.1465 </t>1466 <t>1467 The HTTP version of an application is the highest HTTP version for1468 which the application is at least conditionally compliant.1469 </t>1470 <t>1471 Proxy and gateway applications need to be careful when forwarding1472 messages in protocol versions different from that of the application.1473 Since the protocol version indicates the protocol capability of the1474 sender, a proxy/gateway &MUST-NOT; send a message with a version1475 indicator which is greater than its actual version. If a higher1476 version request is received, the proxy/gateway &MUST; either downgrade1477 the request version, or respond with an error, or switch to tunnel1478 behavior.1479 </t>1480 <t>1481 Due to interoperability problems with HTTP/1.0 proxies discovered1482 since the publication of <xref target="RFC2068"/>, caching proxies &MUST;, gateways1483 &MAY;, and tunnels &MUST-NOT; upgrade the request to the highest version1484 they support. The proxy/gateway's response to that request &MUST; be in1485 the same major version as the request.1486 </t>1487 <x:note>1488 <t>1489 <x:h>Note:</x:h> Converting between versions of HTTP may involve modification1490 of header fields required or forbidden by the versions involved.1491 </t>1492 </x:note>1493 </section>1494 1494 1495 1495 <section title="Date/Time Formats: Full Date" anchor="date.time.formats.full.date">
Note: See TracChangeset
for help on using the changeset viewer.