Changeset 965 for draft-ietf-httpbis/latest/p1-messaging.xml
- Timestamp:
- 30/07/10 06:11:34 (12 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r963 r965 24 24 <!ENTITY diff-mime "<xref target='Part3' x:rel='#differences.between.http.and.mime' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 25 25 <!ENTITY representation "<xref target='Part3' x:rel='#representation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 26 <!ENTITY entity-header-fields "<xref target='Part3' x:rel='#entity.header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">27 26 <!ENTITY header-cache-control "<xref target='Part6' x:rel='#header.cache-control' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 28 27 <!ENTITY header-expect "<xref target='Part2' x:rel='#header.expect' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 521 520 <x:anchor-alias value="request-header"/> 522 521 <x:anchor-alias value="response-header"/> 523 <x:anchor-alias value="entity-header"/>524 522 <x:anchor-alias value="Cache-Control"/> 525 523 <x:anchor-alias value="Pragma"/> … … 534 532 </artwork></figure> 535 533 <figure><!-- Part3--><artwork type="abnf2616"> 536 <x:ref>entity-header</x:ref> = <entity-header, defined in &entity-header-fields;>537 534 <x:ref>MIME-Version</x:ref> = <MIME-Version, defined in &header-mime-version;> 538 535 </artwork></figure> … … 556 553 557 554 <section title="Client/Server Messaging" anchor="operation"> 558 <iref item="client"/>559 <iref item="server"/>560 <iref item="connection"/>555 <iref primary="true" item="client"/> 556 <iref primary="true" item="server"/> 557 <iref primary="true" item="connection"/> 561 558 <t> 562 559 HTTP is a stateless request/response protocol that operates by exchanging … … 567 564 sending HTTP responses. 568 565 </t> 569 <iref item="user agent"/> 570 <iref item="origin server"/> 566 <iref primary="true" item="user agent"/> 567 <iref primary="true" item="origin server"/> 568 <iref primary="true" item="browser"/> 569 <iref primary="true" item="spider"/> 571 570 <t> 572 571 Note that the terms client and server refer only to the roles that … … 576 575 such as a WWW browser, editor, or spider (web-traversing robot), and 577 576 the term "origin server" to refer to the program that can originate 578 authoritative responses to a request. 577 authoritative responses to a request. For general requirements, we use 578 the term "sender" to refer to whichever component sent a given message 579 and the term "recipient" to refer to any component that receives the 580 message. 579 581 </t> 580 582 <t> … … 589 591 < response 590 592 </artwork></figure> 591 <iref item="message"/>592 <iref item="request"/>593 <iref item="response"/>593 <iref primary="true" item="message"/> 594 <iref primary="true" item="request"/> 595 <iref primary="true" item="response"/> 594 596 <t> 595 597 A client sends an HTTP request to the server in the form of a request … … 639 641 640 642 <section title="Intermediaries" anchor="intermediaries"> 643 <iref primary="true" item="intermediary"/> 641 644 <t> 642 645 A more complicated situation occurs when one or more intermediaries … … 665 668 </t> 666 669 <t> 667 <iref item="upstream"/><irefitem="downstream"/>668 <iref item="inbound"/><irefitem="outbound"/>670 <iref primary="true" item="upstream"/><iref primary="true" item="downstream"/> 671 <iref primary="true" item="inbound"/><iref primary="true" item="outbound"/> 669 672 We use the terms "upstream" and "downstream" to describe various 670 673 requirements in relation to the directional flow of a message: … … 674 677 the origin server and "outbound" means toward the user agent. 675 678 </t> 676 <t><iref item="proxy"/>679 <t><iref primary="true" item="proxy"/> 677 680 A "proxy" is a message forwarding agent that is selected by the 678 681 client, usually via local configuration rules, to receive requests … … 685 688 sake of security, annotation services, or shared caching. 686 689 </t> 687 <t><iref item="gateway"/><irefitem="reverse proxy"/>690 <t><iref primary="true" item="gateway"/><iref primary="true" item="reverse proxy"/> 688 691 A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts 689 692 as a layer above some other server(s) and translates the received … … 692 695 multiple machines. 693 696 Unlike a proxy, a gateway receives requests as if it were the 694 origin server for the requestedresource; the requesting client697 origin server for the target resource; the requesting client 695 698 will not be aware that it is communicating with a gateway. 696 699 A gateway communicates with the client as if the gateway is the … … 701 704 specification. 702 705 </t> 703 <t><iref item="tunnel"/>706 <t><iref primary="true" item="tunnel"/> 704 707 A "tunnel" acts as a blind relay between two connections 705 708 without changing the messages. Once active, a tunnel is not … … 714 717 715 718 <section title="Caches" anchor="caches"> 716 <iref item="cache"/>719 <iref primary="true" item="cache"/> 717 720 <t> 718 721 A "cache" is a local store of previous response messages and the … … 735 738 < < 736 739 </artwork></figure> 737 <t><iref item="cacheable"/>740 <t><iref primary="true" item="cacheable"/> 738 741 A response is "cacheable" if a cache is allowed to store a copy of 739 742 the response message for use in answering subsequent requests. … … 1128 1131 like UTF-16 might introduce security flaws due to the differing ways 1129 1132 that such parsers interpret invalid characters. 1133 </t> 1134 <t> 1135 HTTP allows the set of defined header fields to be extended without 1136 changing the protocol version (see <xref target="header.field.registration"/>). 1137 However, such fields might not be recognized by a downstream recipient 1138 and might be stripped by non-transparent intermediaries. 1139 Unrecognized header fields &MUST; be forwarded by transparent proxies 1140 and &SHOULD; be ignored by a recipient. 1130 1141 </t> 1131 1142 </section> … … 1444 1455 experimental header fields might be given the semantics of general 1445 1456 header fields if all parties in the communication recognize them to 1446 be general-header fields. Unrecognized header fields are treated as 1447 entity-header fields. 1457 be general-header fields. 1448 1458 </t> 1449 1459 </section> … … 1460 1470 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Request"/> 1461 1471 <x:ref>Request</x:ref> = <x:ref>Request-Line</x:ref> ; <xref target="request-line"/> 1462 *(( <x:ref>general-header</x:ref> ; <xref target="general.header.fields"/> 1463 / <x:ref>request-header</x:ref> ; &request-header-fields; 1464 / <x:ref>entity-header</x:ref> ) <x:ref>CRLF</x:ref> ) ; &entity-header-fields; 1472 *( <x:ref>header-field</x:ref> <x:ref>CRLF</x:ref> ) ; <xref target="header.fields"/> 1465 1473 <x:ref>CRLF</x:ref> 1466 1474 [ <x:ref>message-body</x:ref> ] ; <xref target="message.body"/> … … 1658 1666 1659 1667 <section title="Effective Request URI" anchor="effective.request.uri"> 1660 <iref primary="true" item="Effective Request URI"/> 1668 <iref primary="true" item="effective request URI"/> 1669 <iref primary="true" item="target resource"/> 1661 1670 <t> 1662 1671 HTTP requests often do not carry the absolute URI (<xref target="RFC3986" x:fmt="," x:sec="4.3"/>) 1663 for the resource they are intended for; instead, the value needs to be inferred from the 1664 request-target, Host header and other context. The result of this process is 1665 the "Effective Request URI". 1666 </t> 1667 <t> 1668 If the request-target is an absolute-URI, then the Effective Request URI is 1672 for the target resource; instead, the URI needs to be inferred from the 1673 request-target, Host header field, and connection context. The result of 1674 this process is called the "effective request URI". The "target resource" 1675 is the resource identified by the effective request URI. 1676 </t> 1677 <t> 1678 If the request-target is an absolute-URI, then the effective request URI is 1669 1679 the request-target. 1670 1680 </t> 1671 1681 <t> 1672 1682 If the request-target uses the path-absolute (plus optional query) syntax 1673 or if it is just the asterisk "*", then the Effective Request URI is1683 or if it is just the asterisk "*", then the effective request URI is 1674 1684 constructed by concatenating 1675 1685 </t> … … 1704 1714 <figure> 1705 1715 <preamble> 1706 Example 1: the Effective Request URI for the message1716 Example 1: the effective request URI for the message 1707 1717 </preamble> 1708 1718 <artwork type="example" x:indent-with=" "> … … 1719 1729 <figure> 1720 1730 <preamble> 1721 Example 2: the Effective Request URI for the message1731 Example 2: the effective request URI for the message 1722 1732 </preamble> 1723 1733 <artwork type="example" x:indent-with=" "> … … 1731 1741 </figure> 1732 1742 <t> 1733 Effective Request URIs are compared using the rules described in1743 Effective request URIs are compared using the rules described in 1734 1744 <xref target="uri.comparison"/>, except that empty path components &MUST-NOT; 1735 1745 be treated as equivalent to an absolute path of "/". … … 1748 1758 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Response"/> 1749 1759 <x:ref>Response</x:ref> = <x:ref>Status-Line</x:ref> ; <xref target="status-line"/> 1750 *(( <x:ref>general-header</x:ref> ; <xref target="general.header.fields"/> 1751 / <x:ref>response-header</x:ref> ; &response-header-fields; 1752 / <x:ref>entity-header</x:ref> ) <x:ref>CRLF</x:ref> ) ; &entity-header-fields; 1760 *( <x:ref>header-field</x:ref> <x:ref>CRLF</x:ref> ) ; <xref target="header.fields"/> 1753 1761 <x:ref>CRLF</x:ref> 1754 1762 [ <x:ref>message-body</x:ref> ] ; <xref target="message.body"/> … … 2031 2039 The chunked encoding modifies the body of a message in order to 2032 2040 transfer it as a series of chunks, each with its own size indicator, 2033 followed by an &OPTIONAL; trailer containing entity-header fields. This2041 followed by an &OPTIONAL; trailer containing header fields. This 2034 2042 allows dynamically produced content to be transferred along with the 2035 2043 information necessary for the recipient to verify that it has … … 2052 2060 <x:ref>chunk-ext-val</x:ref> = <x:ref>token</x:ref> / <x:ref>quoted-str-nf</x:ref> 2053 2061 <x:ref>chunk-data</x:ref> = 1*<x:ref>OCTET</x:ref> ; a sequence of chunk-size octets 2054 <x:ref>trailer-part</x:ref> = *( <x:ref> entity-header</x:ref> <x:ref>CRLF</x:ref> )2062 <x:ref>trailer-part</x:ref> = *( <x:ref>header-field</x:ref> <x:ref>CRLF</x:ref> ) 2055 2063 2056 2064 <x:ref>quoted-str-nf</x:ref> = <x:ref>DQUOTE</x:ref> *( <x:ref>qdtext-nf</x:ref> / <x:ref>quoted-pair</x:ref> ) <x:ref>DQUOTE</x:ref> … … 2843 2851 related to message framing and transport protocols. 2844 2852 </t> 2845 <t>2846 For entity-header fields, both sender and recipient refer to either the2847 client or the server, depending on who sends and who receives the message.2848 </t>2849 2853 2850 2854 <section title="Connection" anchor="header.connection"> … … 3231 3235 &MUST; be listed in the order in which they were applied. 3232 3236 Additional information about the encoding parameters &MAY; be provided 3233 by other entity-header fields not defined by this specification.3237 by other header fields not defined by this specification. 3234 3238 </t> 3235 3239 <t> … … 4936 4940 <x:ref>RWS</x:ref> = 1*( [ obs-fold ] WSP ) 4937 4941 <x:ref>Reason-Phrase</x:ref> = *( WSP / VCHAR / obs-text ) 4938 <x:ref>Request</x:ref> = Request-Line *( ( general-header / request-header / 4939 entity-header ) CRLF ) CRLF [ message-body ] 4942 <x:ref>Request</x:ref> = Request-Line *( header-field CRLF ) CRLF [ message-body ] 4940 4943 <x:ref>Request-Line</x:ref> = Method SP request-target SP HTTP-Version CRLF 4941 <x:ref>Response</x:ref> = Status-Line *( ( general-header / response-header / 4942 entity-header ) CRLF ) CRLF [ message-body ] 4944 <x:ref>Response</x:ref> = Status-Line *( header-field CRLF ) CRLF [ message-body ] 4943 4945 4944 4946 <x:ref>Status-Code</x:ref> = 3DIGIT … … 5001 5003 / %x53.75.6E.64.61.79 ; Sunday 5002 5004 5003 <x:ref>entity-header</x:ref> = <entity-header, defined in [Part3], Section 3.1>5004 5005 5005 <x:ref>field-content</x:ref> = *( WSP / VCHAR / obs-text ) 5006 5006 <x:ref>field-name</x:ref> = token … … 5081 5081 <x:ref>time-of-day</x:ref> = hour ":" minute ":" second 5082 5082 <x:ref>token</x:ref> = 1*tchar 5083 <x:ref>trailer-part</x:ref> = *( entity-headerCRLF )5083 <x:ref>trailer-part</x:ref> = *( header-field CRLF ) 5084 5084 <x:ref>transfer-coding</x:ref> = "chunked" / "compress" / "deflate" / "gzip" / 5085 5085 transfer-extension … … 5638 5638 </t> 5639 5639 <t> 5640 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/109"/>: 5641 "Clarify entity / representation / variant terminology" 5642 </t> 5643 <t> 5640 5644 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/220"/>: 5641 5645 "consider removing the 'changes from 2068' sections"
Note: See TracChangeset
for help on using the changeset viewer.