Changeset 1829 for draft-ietf-httpbis/latest/p1-messaging.html
- Timestamp:
- 19/08/12 04:39:58 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1828 r1829 867 867 <p id="rfc.section.2.2.p.1">When considering the design of HTTP, it is easy to fall into a trap of thinking that all user agents are general-purpose browsers 868 868 and all origin servers are large public websites. That is not the case in practice. Common HTTP user agents include household 869 appliances, stereos, scales, software/firmware updaters, command-line programs, mobile apps, and communication devices in870 a multitude of shapes and sizes. Likewise, common HTTP origin servers include home automation units, configurable networking871 components,office machines, autonomous robots, news feeds, traffic cameras, ad selectors, and video delivery platforms.869 appliances, stereos, scales, firmware update scripts, command-line programs, mobile apps, and communication devices in a multitude 870 of shapes and sizes. Likewise, common HTTP origin servers include home automation units, configurable networking components, 871 office machines, autonomous robots, news feeds, traffic cameras, ad selectors, and video delivery platforms. 872 872 </p> 873 873 <p id="rfc.section.2.2.p.2">The term "user agent" does not imply that there is a human user directly interacting with the software agent at the time of … … 878 878 <p id="rfc.section.2.2.p.3">The implementation diversity of HTTP means that we cannot assume the user agent can make interactive suggestions to a user 879 879 or provide adequate warning for security or privacy options. In the few cases where this specification requires reporting 880 of errors to the user, it is acceptable for such reporting to only be visible in an error console or log file. Likewise, requirements881 that an automated action be confirmed by the user before proceeding can me met via advance configuration choices, run-time882 options, or simply not proceeding with the unsafe action.880 of errors to the user, it is acceptable for such reporting to only be observable in an error console or log file. Likewise, 881 requirements that an automated action be confirmed by the user before proceeding can me met via advance configuration choices, 882 run-time options, or simply not proceeding with the unsafe action. 883 883 </p> 884 884 <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a> <a id="transport-independence" href="#transport-independence">Connections and Transport Independence</a></h2> … … 938 938 to the HTTP communication, though the tunnel might have been initiated by an HTTP request. A tunnel ceases to exist when both 939 939 ends of the relayed connection are closed. Tunnels are used to extend a virtual connection through an intermediary, such as 940 when transport-layer security is used to establish privatecommunication through a shared firewall proxy.940 when transport-layer security is used to establish confidential communication through a shared firewall proxy. 941 941 </p> 942 942 <p id="rfc.section.2.4.p.10"><span id="rfc.iref.i.3"></span> <span id="rfc.iref.t.3"></span> <span id="rfc.iref.c.3"></span> The above categories for intermediary only consider those acting as participants in the HTTP communication. There are also … … 1115 1115 </p> 1116 1116 <p id="rfc.section.2.8.2.p.2">All of the requirements listed above for the "http" scheme are also requirements for the "https" scheme, except that a default 1117 TCP port of 443 is assumed if the port subcomponent is empty or not given, and the TCP connection <em class="bcp14">MUST</em> be secured for privacythrough the use of strong encryption prior to sending the first HTTP request.1117 TCP port of 443 is assumed if the port subcomponent is empty or not given, and the TCP connection <em class="bcp14">MUST</em> be secured through the use of strong encryption prior to sending the first HTTP request. 1118 1118 </p> 1119 1119 <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.25"></span> <a href="#https.uri" class="smpl">https-URI</a> = "https:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ] … … 2059 2059 the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host. 2060 2060 </p> 2061 <p id="rfc.section.6.2.p.10"> For organizations that have strong privacy requirements for hiding internal structures, a proxy or gateway <em class="bcp14">MAY</em> combine an ordered subsequence of Via header field entries with identical received-protocol values into a single such entry.2062 For example,2061 <p id="rfc.section.6.2.p.10">A proxy or gateway <em class="bcp14">MAY</em> combine an ordered subsequence of Via header field entries into a single such entry if the entries have identical received-protocol 2062 values. For example, 2063 2063 </p> 2064 2064 <div id="rfc.figure.u.56"></div><pre class="text"> Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy … … 2612 2612 </p> 2613 2613 <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a> <a id="personal.information" href="#personal.information">Personal Information</a></h2> 2614 <p id="rfc.section.8.1.p.1">HTTP clients are often privy to large amounts of personal information (e.g., the user's name, location, mail address, passwords, 2615 encryption keys, etc.), and <em class="bcp14">SHOULD</em> be very careful to prevent unintentional leakage of this information. We very strongly recommend that a convenient interface 2616 be provided for the user to control dissemination of such information, and that designers and implementers be particularly 2617 careful in this area. History shows that errors in this area often create serious security and/or privacy problems and generate 2618 highly adverse publicity for the implementer's company. 2614 <p id="rfc.section.8.1.p.1">HTTP clients are often privy to large amounts of personal information, including both information provided by the user to 2615 interact with resources (e.g., the user's name, location, mail address, passwords, encryption keys, etc.) and information 2616 about the user's browsing activity over time (e.g., history, bookmarks, etc.). HTTP implementations need to prevent unintentional 2617 leakage of this information. 2619 2618 </p> 2620 2619 <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a> <a id="abuse.of.server.log.information" href="#abuse.of.server.log.information">Abuse of Server Log Information</a></h2> … … 2660 2659 <p id="rfc.section.8.5.p.4">Users need to be aware that intermediaries are no more trustworthy than the people who run them; HTTP itself cannot solve 2661 2660 this problem. 2662 </p>2663 <p id="rfc.section.8.5.p.5">The judicious use of cryptography, when appropriate, might suffice to protect against a broad range of security and privacy2664 attacks. Such cryptography is beyond the scope of the HTTP/1.1 specification.2665 2661 </p> 2666 2662 <h2 id="rfc.section.8.6"><a href="#rfc.section.8.6">8.6</a> <a id="attack.protocol.element.size.overflows" href="#attack.protocol.element.size.overflows">Protocol Element Size Overflows</a></h2>
Note: See TracChangeset
for help on using the changeset viewer.