configuration options to end users. As an extreme privacy measure,
proxies could filter the accept headers in relayed requests. General
purpose user agents which provide a high degree of header
configurability should warn users about the loss of privacy which can
be involved.
RFC 2068 HTTP/1.1 January 1997
15.8 DNS Spoofing
Clients using HTTP rely heavily on the Domain Name Service, and are
thus generally prone to security attacks based on the deliberate
mis-association of IP addresses and DNS names. Clients need to be
cautious in assuming the continuing validity of an IP number/DNS name
association.
In particular, HTTP clients SHOULD rely on their name resolver for
confirmation of an IP number/DNS name association, rather than
caching the result of previous host name lookups. Many platforms
already can cache host name lookups locally when appropriate, and
they SHOULD be configured to do so. These lookups should be cached,
however, only when the TTL (Time To Live) information reported by the
name server makes it likely that the cached information will remain
useful.
If HTTP clients cache the results of host name lookups in order to
achieve a performance improvement, they MUST observe the TTL
information reported by DNS.
If HTTP clients do not observe this rule, they could be spoofed when
a previously-accessed server's IP address changes. As network
renumbering is expected to become increasingly common, the
possibility of this form of attack will grow. Observing this
requirement thus reduces this potential security vulnerability.
This requirement also improves the load-balancing behavior of clients
for replicated servers using the same DNS name and reduces the
likelihood of a user's experiencing failure in accessing sites which
use that strategy.
15.9 Location Headers and Spoofing
If a single server supports multiple organizations that do not trust
one another, then it must check the values of Location and Content-
Location headers in responses that are generated under control of
said organizations to make sure that they do not attempt to
invalidate resources over which they have no authority.
16 Acknowledgments
This specification makes heavy use of the augmented BNF and generic
constructs defined by David H. Crocker for RFC 822. Similarly, it
reuses many of the definitions provided by Nathaniel Borenstein and
Ned Freed for MIME. We hope that their inclusion in this
specification will help reduce past confusion over the relationship
between HTTP and Internet mail message formats.
RFC 2068 HTTP/1.1 January 1997
The HTTP protocol has evolved considerably over the past four years.
It has benefited from a large and active developer community--the
many people who have participated on the www-talk mailing list--and
it is that community which has been most responsible for the success
of HTTP and of the World-Wide Web in general. Marc Andreessen, Robert
Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois
Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob
McCool, Lou Montulli, Dave Raggett, Tony Sanders, and Marc
VanHeyningen deserve special recognition for their efforts in
defining early aspects of the protocol.
This document has benefited greatly from the comments of all those
participating in the HTTP-WG. In addition to those already mentioned,
the following individuals have contributed to this specification:
Gary Adams Albert Lunde
Harald Tveit Alvestrand John C. Mallery
Keith Ball Jean-Philippe Martin-Flatin
Brian Behlendorf Larry Masinter
Paul Burchard Mitra
Maurizio Codogno David Morris
Mike Cowlishaw Gavin Nicol
Roman Czyborra Bill Perry
Michael A. Dolan Jeffrey Perry
David J. Fiander Scott Powers
Alan Freier Owen Rees
Marc Hedlund Luigi Rizzo
Greg Herlihy David Robinson
Koen Holtman Marc Salomon
Alex Hopmann Rich Salz
=81= |