Changeset 901 for draft-ietf-httpbis/latest/p1-messaging.xml
- Timestamp:
- 24/07/10 07:25:07 (13 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r899 r901 265 265 actions should be reflected in corresponding changes to the 266 266 observable interface provided by servers. However, since multiple 267 clients m ayact in parallel and perhaps at cross-purposes, we267 clients might act in parallel and perhaps at cross-purposes, we 268 268 cannot require that such changes be observable beyond the scope 269 269 of a single response. … … 429 429 </t> 430 430 <t> 431 The OWS rule is used where zero or more linear whitespace characters m ay431 The OWS rule is used where zero or more linear whitespace characters might 432 432 appear. OWS &SHOULD; either not be produced or be produced as a single SP 433 433 character. Multiple OWS characters that occur within field-content &SHOULD; … … 569 569 Note that the terms client and server refer only to the roles that 570 570 these programs perform for a particular connection. The same program 571 m ayact as a client on some connections and a server on others. We use571 might act as a client on some connections and a server on others. We use 572 572 the term "user agent" to refer to the program that initiates a request, 573 573 such as a WWW browser, editor, or spider (web-traversing robot), and … … 578 578 Most HTTP communication consists of a retrieval request (GET) for 579 579 a representation of some resource identified by a URI. In the 580 simplest case, this m aybe accomplished via a single bidirectional580 simplest case, this might be accomplished via a single bidirectional 581 581 connection (===) between the user agent (UA) and the origin server (O). 582 582 </t> … … 640 640 are present in the request/response chain. There are three common 641 641 forms of intermediary: proxy, gateway, and tunnel. In some cases, 642 a single intermediary m ayact as an origin server, proxy, gateway,642 a single intermediary might act as an origin server, proxy, gateway, 643 643 or tunnel, switching behavior based on the nature of each request. 644 644 </t> … … 653 653 travels the whole chain will pass through four separate connections. 654 654 Some HTTP communication options 655 m ayapply only to the connection with the nearest, non-tunnel655 might apply only to the connection with the nearest, non-tunnel 656 656 neighbor, only to the end-points of the chain, or to all connections 657 along the chain. Although the diagram is linear, each participant m ay657 along the chain. Although the diagram is linear, each participant might 658 658 be engaged in multiple, simultaneous communications. For example, B 659 m aybe receiving requests from many clients other than A, and/or659 might be receiving requests from many clients other than A, and/or 660 660 forwarding requests to servers other than C, at the same time that it 661 661 is handling A's request. … … 677 677 requests via translation through the HTTP interface. Some translations 678 678 are minimal, such as for proxy requests for "http" URIs, whereas 679 other requests m ayrequire translation to and from entirely different679 other requests might require translation to and from entirely different 680 680 application-layer protocols. Proxies are often used to group an 681 681 organization's HTTP requests through a common intermediary for the … … 701 701 A "tunnel" acts as a blind relay between two connections 702 702 without changing the messages. Once active, a tunnel is not 703 considered a party to the HTTP communication, though the tunnel m ay703 considered a party to the HTTP communication, though the tunnel might 704 704 have been initiated by an HTTP request. A tunnel ceases to exist when 705 705 both ends of the relayed connection are closed. Tunnels are used to … … 713 713 <iref item="cache"/> 714 714 <t> 715 Any party to HTTP communication that is not acting as a tunnel may716 employ an internal cache for handling requests.717 715 A "cache" is a local store of previous response messages and the 718 716 subsystem that controls its message storage, retrieval, and deletion. 719 717 A cache stores cacheable responses in order to reduce the response 720 718 time and network bandwidth consumption on future, equivalent 721 requests. Any client or server may includea cache, though a cache719 requests. Any client or server &MAY; employ a cache, though a cache 722 720 cannot be used by a server while it is acting as a tunnel. 723 721 </t> … … 737 735 A response is "cacheable" if a cache is allowed to store a copy of 738 736 the response message for use in answering subsequent requests. 739 Even when a response is cacheable, there m aybe additional737 Even when a response is cacheable, there might be additional 740 738 constraints placed by the client or by the origin server on when 741 739 that cached response can be used for a particular request. HTTP … … 771 769 <t> 772 770 In HTTP/1.0, most implementations used a new connection for each 773 request/response exchange. In HTTP/1.1, a connection m aybe used for774 one or more request/response exchanges, although connections m aybe771 request/response exchange. In HTTP/1.1, a connection might be used for 772 one or more request/response exchanges, although connections might be 775 773 closed for a variety of reasons (see <xref target="persistent.connections"/>). 776 774 </t> … … 790 788 The <minor> number is incremented when the changes made to the 791 789 protocol add features which do not change the general message parsing 792 algorithm, but which m ayadd to the message semantics and imply790 algorithm, but which might add to the message semantics and imply 793 791 additional capabilities of the sender. The <major> number is 794 792 incremented when the format of a message within the protocol is … … 842 840 <x:note> 843 841 <t> 844 <x:h>Note:</x:h> Converting between versions of HTTP m ayinvolve modification842 <x:h>Note:</x:h> Converting between versions of HTTP might involve modification 845 843 of header fields required or forbidden by the versions involved. 846 844 </t> … … 854 852 throughout HTTP as the means for identifying resources. URI references 855 853 are used to target requests, indicate redirects, and define relationships. 856 HTTP does not limit what a resource m aybe; it merely defines an interface854 HTTP does not limit what a resource might be; it merely defines an interface 857 855 that can be used to interact with a resource via HTTP. More information on 858 856 the scope of URIs and resources can be found in <xref target="RFC3986"/>. … … 930 928 <t> 931 929 Regardless of the form of host identifier, access to that host is not 932 implied by the mere presence of its name or address. The host m ay or may933 not exist and, even when it does exist, m ay or maynot be running an930 implied by the mere presence of its name or address. The host might or might 931 not exist and, even when it does exist, might or might not be running an 934 932 HTTP server or listening to the indicated port. The "http" URI scheme 935 933 makes use of the delegated nature of Internet names and addresses to … … 955 953 would presumably be identified using a different URI scheme, just as 956 954 the "https" scheme (below) is used for servers that require an SSL/TLS 957 transport layer on a connection. Other protocols m ayalso be used to955 transport layer on a connection. Other protocols might also be used to 958 956 provide access to "http" identified resources --- it is only the 959 957 authoritative interface used for mapping the namespace that is … … 995 993 Unlike the "http" scheme, responses to "https" identified requests 996 994 are never "public" and thus are ineligible for shared caching. 997 Their default is "private" and m aybe further constrained via use995 Their default is "private" and might be further constrained via use 998 996 of the Cache-Control header field. 999 997 </t> … … 1092 1090 header field. The presence of whitespace might be an attempt to trick a 1093 1091 noncompliant implementation of HTTP into ignoring that field or processing 1094 the next line as a new request, either of which m ayresult in security1092 the next line as a new request, either of which might result in security 1095 1093 issues when implementations within the request chain interpret the 1096 1094 same message differently. HTTP/1.1 servers &MUST; reject such a message … … 1125 1123 of octets in an encoding that is a superset of US-ASCII. Attempting 1126 1124 to parse HTTP as a stream of Unicode characters in a character encoding 1127 like UTF-16 m ayintroduce security flaws due to the differing ways1125 like UTF-16 might introduce security flaws due to the differing ways 1128 1126 that such parsers interpret invalid characters. 1129 1127 </t> … … 1311 1309 If a message is received with both a Transfer-Encoding header field and a 1312 1310 Content-Length header field, the Transfer-Encoding overrides the Content-Length. 1313 Such a message m ayindicate an attempt to perform request or response1311 Such a message might indicate an attempt to perform request or response 1314 1312 smuggling (bypass of security-related checks on message routing or content) 1315 1313 and thus should be handled as an error. The provided Content-Length &MUST; … … 1431 1429 General-header field names can be extended reliably only in 1432 1430 combination with a change in the protocol version. However, new or 1433 experimental header fields m aybe given the semantics of general1431 experimental header fields might be given the semantics of general 1434 1432 header fields if all parties in the communication recognize them to 1435 1433 be general-header fields. Unrecognized header fields are treated as … … 1936 1934 <t> 1937 1935 <x:h>Note:</x:h> Recipients of date values are encouraged to be robust in 1938 accepting date values that m ayhave been sent by non-HTTP1936 accepting date values that might have been sent by non-HTTP 1939 1937 applications, as is sometimes the case when retrieving or posting 1940 1938 messages via proxies/gateways to SMTP or NNTP. … … 1956 1954 <t> 1957 1955 Transfer-coding values are used to indicate an encoding 1958 transformation that has been, can be, or m ayneed to be applied to a1956 transformation that has been, can be, or might need to be applied to a 1959 1957 payload body in order to ensure "safe transport" through the network. 1960 1958 This differs from a content coding in that the transfer-coding is a … … 2654 2652 <t> 2655 2653 Because of the presence of older implementations, the protocol allows 2656 ambiguous situations in which a client m aysend "Expect: 100-continue"2654 ambiguous situations in which a client might send "Expect: 100-continue" 2657 2655 without receiving either a 417 (Expectation Failed) status 2658 2656 or a 100 (Continue) status. Therefore, when a client sends this … … 2795 2793 2796 2794 2797 <section title="Miscellaneous notes that m aydisappear" anchor="misc">2795 <section title="Miscellaneous notes that might disappear" anchor="misc"> 2798 2796 <section title="Scheme aliases considered harmful" anchor="scheme.aliases"> 2799 2797 <t> … … 2864 2862 a connection-token in the Connection header field, not by any 2865 2863 corresponding additional header field(s), since the additional header 2866 field m aynot be sent if there are no parameters associated with that2864 field might not be sent if there are no parameters associated with that 2867 2865 connection option. 2868 2866 </t> … … 3088 3086 </t> 3089 3087 <t> 3090 Its value m ayconsist of the keyword "trailers" and/or a comma-separated3088 Its value might consist of the keyword "trailers" and/or a comma-separated 3091 3089 list of extension transfer-coding names with optional accept 3092 3090 parameters (as described in <xref target="transfer.codings"/>). … … 3865 3863 </t> 3866 3864 <t> 3867 The judicious use of cryptography, when appropriate, m aysuffice to3865 The judicious use of cryptography, when appropriate, might suffice to 3868 3866 protect against a broad range of security and privacy attacks. Such 3869 3867 cryptography is beyond the scope of the HTTP/1.1 specification. … … 4226 4224 <seriesInfo name="RFC" value="1950"/> 4227 4225 <annotation> 4228 RFC 1950 is an Informational RFC, thus it m aybe less stable than4226 RFC 1950 is an Informational RFC, thus it might be less stable than 4229 4227 this specification. On the other hand, this downward reference was 4230 4228 present since the publication of RFC 2068 in 1997 (<xref target="RFC2068"/>), … … 4245 4243 <seriesInfo name="RFC" value="1951"/> 4246 4244 <annotation> 4247 RFC 1951 is an Informational RFC, thus it m aybe less stable than4245 RFC 1951 is an Informational RFC, thus it might be less stable than 4248 4246 this specification. On the other hand, this downward reference was 4249 4247 present since the publication of RFC 2068 in 1997 (<xref target="RFC2068"/>), … … 4276 4274 <seriesInfo name="RFC" value="1952"/> 4277 4275 <annotation> 4278 RFC 1952 is an Informational RFC, thus it m aybe less stable than4276 RFC 1952 is an Informational RFC, thus it might be less stable than 4279 4277 this specification. On the other hand, this downward reference was 4280 4278 present since the publication of RFC 2068 in 1997 (<xref target="RFC2068"/>), … … 4863 4861 experimental implementations of persistent connections are faulty, 4864 4862 and the new facilities in HTTP/1.1 are designed to rectify these 4865 problems. The problem was that some existing HTTP/1.0 clients m ay be4866 send ingKeep-Alive to a proxy server that doesn't understand4863 problems. The problem was that some existing HTTP/1.0 clients might 4864 send Keep-Alive to a proxy server that doesn't understand 4867 4865 Connection, which would then erroneously forward it to the next 4868 4866 inbound server, which would establish the Keep-Alive connection and … … 4895 4893 Transfer-coding and message lengths all interact in ways that 4896 4894 required fixing exactly when chunked encoding is used (to allow for 4897 transfer encoding that m aynot be self delimiting); it was important4895 transfer encoding that might not be self delimiting); it was important 4898 4896 to straighten out exactly how message lengths are computed. (Sections 4899 4897 <xref target="transfer.codings" format="counter"/>, <xref target="message.body" format="counter"/>, … … 5571 5569 <t> 5572 5570 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/88"/>: 5573 "205 Bodies" (took out language that implied that there m aybe5571 "205 Bodies" (took out language that implied that there might be 5574 5572 methods for which a request body MUST NOT be included) 5575 5573 </t>
Note: See TracChangeset
for help on using the changeset viewer.