fielding, et al. standards track [page 151]

rfc 2616 http/1.1 june 1999

the referer. even when the personal information has been removed, the
referer header might indicate a private document's uri whose
publication would be inappropriate.

the information sent in the from field might conflict with the user's
privacy interests or their site's security policy, and hence it
should not be transmitted without the user being able to disable,
enable, and modify the contents of the field. the user must be able
to set the contents of this field within a user preference or
application defaults configuration.

we suggest, though do not require, that a convenient toggle interface
be provided for the user to enable or disable the sending of from and
referer information.

the user-agent (section 14.43) or server (section 14.38) header
fields can sometimes be used to determine that a specific client or
server have a particular security hole which might be exploited.
unfortunately, this same information is often used for other valuable
purposes for which http currently has no better mechanism.

15.1.3 encoding sensitive information in uri's

because the source of a link might be private information or might
reveal an otherwise private information source, it is strongly
recommended that the user be able to select whether or not the
referer field is sent. for example, a browser client could have a
toggle switch for browsing openly/anonymously, which would
respectively enable/disable the sending of referer and from
information.

clients should not include a referer header field in a (non-secure)
http request if the referring page was transferred with a secure
protocol.

authors of services which use the http protocol should not use get
based forms for the submission of sensitive data, because this will
cause this data to be encoded in the request-uri. many existing
servers, proxies, and user agents will log the request uri in some
place where it might be visible to third parties. servers can use
post-based form submission instead

15.1.4 privacy issues connected to accept headers

accept request-headers can reveal information about the user to all
servers which are accessed. the accept-language header in particular
can reveal information the user would consider to be of a private
nature, because the understanding of particular languages is often

fielding, et al. standards track [page 152]

rfc 2616 http/1.1 june 1999

strongly correlated to the membership of a particular ethnic group.
user agents which offer the option to configure the contents of an
accept-language header to be sent in every request are strongly
encouraged to let the configuration process include a message which
makes the user aware of the loss of privacy involved.

an approach that limits the loss of privacy would be for a user agent
to omit the sending of accept-language headers by default, and to ask
the user whether or not to start sending accept-language headers to a
server if it detects, by looking for any vary response-header fields
generated by the server, that such sending could improve the quality
of service.

elaborate user-customized accept header fields sent in every request,
in particular if these include quality values, can be used by servers
as relatively reliable and long-lived user identifiers. such user
identifiers would allow content providers to do click-trail tracking,
and would allow collaborating content providers to match cross-server
click-trails or form submissions of individual users. note that for
many users not behind a proxy, the network address of the host
running the user agent will also serve as a long-lived user
identifier. in environments where proxies are used to enhance
privacy, user agents ought to be conservative in offering accept
header 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.

15.2 attacks based on file and path names

implementations of http origin servers should be careful to restrict
the documents returned by http requests to be only those that were
intended by the server administrators. if an http server translates
http uris directly into file system calls, the server must take
special care not to serve files that were not intended to be
delivered to http clients. for example, unix, microsoft windows, and
other operating systems use ".." as a path component to indicate a
directory level above the current one. on such a system, an http
server must disallow any such construct in the request-uri if it
would otherwise allow access to a resource outside those intended to
be accessible via the http server. similarly, files intended for
reference only internally to the server (such as access control
files, configuration files, and script code) must be protected from
inappropriate retrieval, since they might contain sensitive
information. experience has shown that minor bugs in such http server
implementations have turned into security risks.

fielding, et al. standards track [page 153]

rfc 2616 http/1.1 june 1999

15.3 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. it is proper for these lookups to
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 [24], 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.4 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.

15.5 content-disposition issues

rfc 1806 [35], from which the often implemented content-disposition
(see section 19.5.1) header in http is derived, has a number of very
serious security considerations. content-disposition is not part of
the http standard, but since it is widely implemented, we are
documenting its use and risks for implementors. see rfc 2183 [49]
(which updates rfc 1806) for details.

fielding, et al. standards track [page 154]

rfc 2616 http/1.1 june 1999

15.6 authentication credentials and idle clients

existing http clients and user agents typically retain authentication
information indefinitely. http/1.1. does not provide a method for a
server to direct clients to discard these cached credentials. this is
a significant defect that requires further extensions to http.
circumstances under which credential caching can interfere with the
application's security model include but are not limited to:

- clients which have been idle for an extended period following
which the server might wish to cause the client to reprompt the
user for credentials.

- applications which include a session termination indication
(such as a logout' orcommit' button on a page) after which
the server side of the application `knows' that there is no
further reason for the client to retain the credentials.

this is currently under separate study. there are a number of work-
arounds to parts of this problem, and we encourage the use of
password protection in screen savers, idle time-outs, and other
methods which mitigate the security problems inherent in this
problem. in particular, user agents which cache credentials are
encouraged to provide a readily accessible mechanism for discarding
cached credentials under user control.

15.7 proxies and caching

by their very nature, http proxies are men-in-the-middle, and
represent an opportunity for man-in-the-middle attacks. compromise of
the systems on which the proxies run can result in serious security
and privacy problems. proxies have access to security-related
information, personal information about individual users and
organizations, and proprietary information belonging to users and
content providers. a compromised proxy, or a proxy implemented or
configured without regard to security and privacy considerations,
might be used in the commission of a wide range of potential attacks.

proxy operators should protect the systems on which proxies run as
they would protect any system that contains or transports sensitive
information. in particular, log information gathered at proxies often
contains highly sensitive personal information, and/or information
about organizations. log information should be carefully guarded, and
appropriate guidelines for use developed and followed. (section
15.1.1).

fielding, et al. standards track [page 155]

rfc 2616 http/1.1 june 1999

caching proxies provide additional potential vulnerabilities, since
the contents of the cache represent an attractive target for
malicious exploitation. because cache contents persist after an http
request is complete, an attack on the cache can reveal information
long after a user believes that the information has been removed from
the network. therefore, cache contents should be protected as
sensitive information.

proxy implementors should consider the privacy and security
implications of their design and coding decisions, and of the
configuration options they provide to proxy operators (especially the
default configuration).

users of a proxy need to be aware that they are no trustworthier than
the people who run the proxy; http itself cannot solve this problem.

the judicious use of cryptography, when appropriate, may suffice to
protect against a broad range of security and privacy attacks. such
cryptography is beyond the scope of the http/1.1 specification.

15.7.1 denial of service attacks on proxies

they exist. they are hard to defend against. research continues.
beware.

16 acknowledgments

this specification makes heavy use of the augmented bnf and generic
constructs defined by david h. crocker for rfc 822 [9]. similarly, it
reuses many of the definitions provided by nathaniel borenstein and
ned freed for mime [7]. we hope that their inclusion in this
specification will help reduce past confusion over the relationship
between http and internet mail message formats.

the http protocol has evolved considerably over the 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:

fielding, et al. standards track [page 156]

rfc 2616 http/1.1 june 1999

gary adams ross patterson
harald tveit alvestrand albert lunde
keith ball john c. mallery
brian behlendorf jean-philippe martin-flatin
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
bob jernigan allan m. schiffman
shel kaphan jim seidman
rohit khare chuck shotton
john klensin eric w. sink
martijn koster simon e. spero
alexei kosut richard n. taylor
david m. kristol robert s. thau
daniel laliberte bill (bearheart) weinman
ben laurie francois yergeau
paul j. leach mary ellen zurko
daniel dubois josh cohen

much of the content and presentation of the caching design is due to
suggestions and comments from individuals including: shel kaphan,
paul leach, koen holtman, david morris, and larry masinter.

most of the specification of ranges is based on work originally done
by ari luotonen and john franks, with additional input from steve
zilles.

thanks to the "cave men" of palo alto. you know who you are.

jim gettys (the current editor of this document) wishes particularly
to thank roy fielding, the previous editor of this document, along
with john klensin, jeff mogul, paul leach, dave kristol, koen
holtman, john franks, josh cohen, alex hopmann, scott lawrence, and
larry masinter for their help. and thanks go particularly to jeff
mogul and scott lawrence for performing the "must/may/should" audit.

fielding, et al. standards track [page 157]

rfc 2616 http/1.1 june 1999

the apache group, anselm baird-smith, author of jigsaw, and henrik
frystyk implemented rfc 2068 early, and we wish to thank them for the
discovery of many of the problems that this document attempts to
rectify.

17 references

[1] alvestrand, h., "tags for the identification of languages", rfc
1766, march 1995.

[2] anklesaria, f., mccahill, m., lindner, p., johnson, d., torrey,
d. and b. alberti, "the internet gopher protocol (a distributed
document search and retrieval protocol)", rfc 1436, march 1993.

[3] berners-lee, t., "universal resource identifiers in www", rfc
1630, june 1994.

[4] berners-lee, t., masinter, l. and m. mccahill, "uniform resource
locators (url)", rfc 1738, december 1994.

[5] berners-lee, t. and d. connolly, "hypertext markup language -
2.0", rfc 1866, november 1995.

[6] berners-lee, t., fielding, r. and h. frystyk, "hypertext transfer
protocol -- http/1.0", rfc 1945, may 1996.

[7] freed, n. and n. borenstein, "multipurpose internet mail
extensions (mime) part one: format of internet message bodies",
rfc 2045, november 1996.

[8] braden, r., "requirements for internet hosts -- communication
layers", std 3, rfc 1123, october 1989.

[9] crocker, d., "standard for the format of arpa internet text
messages", std 11, rfc 822, august 1982.

[10] davis, f., kahle, b., morris, h., salem, j., shen, t., wang, r.,
sui, j., and m. grinbaum, "wais interface protocol prototype
functional specification," (v1.5), thinking machines
corporation, april 1990.

[11] fielding, r., "relative uniform resource locators", rfc 1808,
june 1995.

[12] horton, m. and r. adams, "standard for interchange of usenet
messages", rfc 1036, december 1987.

fielding, et al. standards track [page 158]

rfc 2616 http/1.1 june 1999

[13] kantor, b. and p. lapsley, "network news transfer protocol", rfc
977, february 1986.

[14] moore, k., "mime (multipurpose internet mail extensions) part
three: message header extensions for non-ascii text", rfc 2047,
november 1996.

[15] nebel, e. and l. masinter, "form-based file upload in html", rfc
1867, november 1995.

[16] postel, j., "simple mail transfer protocol", std 10, rfc 821,
august 1982.

[17] postel, j., "media type registration procedure", rfc 1590,
november 1996.

[18] postel, j. and j. reynolds, "file transfer protocol", std 9, rfc
959, october 1985.

[19] reynolds, j. and j. postel, "assigned numbers", std 2, rfc 1700,
october 1994.

[20] sollins, k. and l. masinter, "functional requirements for
uniform resource names", rfc 1737, december 1994.

[21] us-ascii. coded character set - 7-bit american standard code for
information interchange. standard ansi x3.4-1986, ansi, 1986.

[22] iso-8859. international standard -- information processing --
8-bit single-byte coded graphic character sets --
part 1: latin alphabet no. 1, iso-8859-1:1987.
part 2: latin alphabet no. 2, iso-8859-2, 1987.
part 3: latin alphabet no. 3, iso-8859-3, 1988.
part 4: latin alphabet no. 4, iso-8859-4, 1988.
part 5: latin/cyrillic alphabet, iso-8859-5, 1988.
part 6: latin/arabic alphabet, iso-8859-6, 1987.
part 7: latin/greek alphabet, iso-8859-7, 1987.
part 8: latin/hebrew alphabet, iso-8859-8, 1988.
part 9: latin alphabet no. 5, iso-8859-9, 1990.

[23] meyers, j. and m. rose, "the content-md5 header field", rfc
1864, october 1995.

[24] carpenter, b. and y. rekhter, "renumbering needs work", rfc
1900, february 1996.

[25] deutsch, p., "gzip file format specification version 4.3", rfc
1952, may 1996.

fielding, et al. standards track [page 159]

rfc 2616 http/1.1 june 1999

[26] venkata n. padmanabhan, and jeffrey c. mogul. "improving http
latency", computer networks and isdn systems, v. 28, pp. 25-35,
dec. 1995. slightly revised version of paper in proc. 2nd
international www conference '94: mosaic and the web, oct. 1994,
which is available at
http://www.ncsa.uiuc.edu/…edings/dday/mogul/httplat
ency.html.

[27] joe touch, john heidemann, and katia obraczka. "analysis of http
performance", <url: http://www.isi.edu/touch/pubs/http-perf96/>,
isi research report isi/rr-98-463, (original report dated aug.
1996), usc/information sciences institute, august 1998.

[28] mills, d., "network time protocol (version 3) specification,
implementation and analysis", rfc 1305, march 1992.

[29] deutsch, p., "deflate compressed data format specification
version 1.3", rfc 1951, may 1996.

[30] s. spero, "analysis of http performance problems,"
http://sunsite.unc.edu/…dma-release/http-prob.html.

[31] deutsch, p. and j. gailly, "zlib compressed data format
specification version 3.3", rfc 1950, may 1996.

[32] franks, j., hallam-baker, p., hostetler, j., leach, p.,
luotonen, a., sink, e. and l. stewart, "an extension to http:
digest access authentication", rfc 2069, january 1997.

[33] fielding, r., gettys, j., mogul, j., frystyk, h. and t.
berners-lee, "hypertext transfer protocol -- http/1.1", rfc
2068, january 1997.

[34] bradner, s., "key words for use in rfcs to indicate requirement
levels", bcp 14, rfc 2119, march 1997.

[35] troost, r. and dorner, s., "communicating presentation
information in internet messages: the content-disposition
header", rfc 1806, june 1995.

[36] mogul, j., fielding, r., gettys, j. and h. frystyk, "use and
interpretation of http version numbers", rfc 2145, may 1997.
[jg639]

[37] palme, j., "common internet message headers", rfc 2076, february
1997. [jg640]

fielding, et al. standards track [page 160]

rfc 2616 http/1.1 june 1999

[38] yergeau, f., "utf-8, a transformation format of unicode and
iso-10646", rfc 2279, january 1998. [jg641]

[39] nielsen, h.f., gettys, j., baird-smith, a., prud'hommeaux, e.,
lie, h., and c. lilley. "network performance effects of
http/1.1, css1, and png," proceedings of acm sigcomm '97, cannes
france, september 1997.[jg642]

[40] freed, n. and n. borenstein, "multipurpose internet mail
extensions (mime) part two: media types", rfc 2046, november
1996. [jg643]

[41] alvestrand, h., "ietf policy on character sets and languages",
bcp 18, rfc 2277, january 1998. [jg644]

[42] berners-lee, t., fielding, r. and l. masinter, "uniform resource
identifiers (uri): generic syntax and semantics", rfc 2396,
august 1998. [jg645]

[43] franks, j., hallam-baker, p., hostetler, j., lawrence, s.,
leach, p., luotonen, a., sink, e. and l. stewart, "http
authentication: basic and digest access authentication", rfc
2617, june 1999. [jg646]

[44] luotonen, a., "tunneling tcp based protocols through web proxy
servers," work in progress. [jg647]

[45] palme, j. and a. hopmann, "mime e-mail encapsulation of
aggregate documents, such as html (mhtml)", rfc 2110, march
1997.

[46] bradner, s., "the internet standards process -- revision 3", bcp
9, rfc 2026, october 1996.

[47] masinter, l., "hyper text coffee pot control protocol
(htcpcp/1.0)", rfc 2324, 1 april 1998.

[48] freed, n. and n. borenstein, "multipurpose internet mail
extensions (mime) part five: conformance criteria and examples",
rfc 2049, november 1996.

[49] troost, r., dorner, s. and k. moore, "communicating presentation
information in internet messages: the content-disposition header
field", rfc 2183, august 1997.

(huzursuz - 28 Nisan 2003 19:09)