As per Relevance of the word mechanism, we have this rfc below:
Network Working Group K.
Request for Comments: 2964 University of
BCP: 44 N.
Category: Best Current Practice
October 2000
Use of HTTP State
Status of this
This document specifies an Internet Best Current Practices for
Internet Community, and requests discussion and suggestions
improvements. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
IESG
The IESG notes that this mechanism makes use of the .local top-
domain (TLD) internally when handling host names that don't
any dots, and that this mechanism might not work in the expected
should an actual .local TLD ever be registered
The mechanisms described in "HTTP State Management Mechanism" (RFC
2965), and its predecessor (RFC-2109), can be used for many
purposes. However, some current and potential uses of the
are controversial because they have significant user privacy
security implications. This memo identifies specific uses
Hypertext Transfer Protocol (HTTP) State Management protocol
are either (a) not recommended by the IETF, or (b) believed to
harmful, and discouraged. This memo also details additional
considerations which are not covered by the HTTP State
protocol specification
1.
The HTTP State Management mechanism is both useful and controversial
It is useful because numerous applications of HTTP benefit from
ability to save state between HTTP transactions, without
such state in URLs. It is controversial because the mechanism
been used to accomplish things for which it was not designed and
not well-suited. Some of these uses have attracted a great deal
public criticism because they threaten to violate the privacy of
Moore & Freed Best Current Practice [Page 1]
RFC 2964 Use of HTTP State Management October 2000
users, specifically by leaking potentially sensitive information
third parties such as the Web sites a user has visited. There
also other uses of HTTP State Management which are inappropriate
though they do not threaten user privacy
This memo therefore identifies uses of the HTTP State
protocol specified in RFC-2965 which are not recommended by the IETF
or which are believed to be harmful and are therefore discouraged
This document occasionally uses terms that appear in capital letters
When the terms "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY
appear capitalized, they are being used to indicate
requirements of this specification. A discussion of the meanings
the terms "MUST", "SHOULD", and "MAY" appears in [RFC-1123];
terms "MUST NOT" and "SHOULD NOT" are logical extensions of
usage
2. Uses of HTTP State
The purpose of HTTP State Management is to allow an HTTP-
service to create stateful "sessions" which persist across
HTTP transactions. A single session may involve transactions
multiple server hosts. Multiple client hosts may also be involved
a single session when the session data for a particular user
shared between client hosts (e.g., via a networked file system).
other words, the "session" retains state between a "user" and
"service", not between particular hosts
It's important to realize that similar capabilities may also
achieved using the "bare" HTTP protocol, and/or dynamically-
HTML, without the State Management extensions. For example,
information can be transmitted from the service to the user
embedding a session identifier in one or more URLs which appear
HTTP redirects, or dynamically generated HTML; and the
information may be returned from the user to the service when
URLs appear in a GET or POST request. HTML forms can also be used
pass state information from the service to the user and back,
the user being aware of this happening
However, the HTTP State Management facility does provide an
in functionality over ordinary HTTP and HTML. In practice,
additional functionality includes
(1) The ability to exchange URLs between users, of
accessed during stateful sessions, without leaking the
information associated with those sessions. (e.g. "Here's
URL for the FooCorp web catalog entry for those sandals
you wanted.")
Moore & Freed Best Current Practice [Page 2]
RFC 2964 Use of HTTP State Management October 2000
(2) The ability to maintain session state without "cache-busting".
That is, separating the session state from the URL allows a
cache to maintain only a single copy of the named resource.
the state is maintained in session-specific URLs, the
would likely have to maintain several identical copies of
resource
(3) The ability to implement sessions with minimal
configuration and minimal protocol overhead, as compared
other techniques of maintaining session state
(4) The ability to associate the user with session state whenever
user accesses the service, regardless of whether the
enters through a particular "home page" or "portal".
(5) The ability to save session information in stable storage,
that a "session" can be maintained across client invocations
system reboots, and client or system crashes
2.1. Recommended
Use of HTTP State Management is appropriate whenever it is
to maintain state between a user and a service across multiple
transactions, provided that
(1) the user is aware that session state is being maintained
consents to it
(2) the user has the ability to delete the state associated
such a session at any time
(3) the information obtained through the ability to track
user's usage of the service is not disclosed to other
without the user's explicit consent,
(4) session information itself cannot contain sensitive
and cannot be used to obtain sensitive information that is
otherwise available to an eavesdropper
This last point is important because cookies are usually sent in
clear and hence are readily available to eavesdroppers
An example of such a recommended use would be a "shopping cart",
where the existence of the shopping cart is explicitly made known
the user, the user can explicitly "empty" his or her shopping
(either by requesting that it be emptied or by purchasing
Moore & Freed Best Current Practice [Page 3]
RFC 2964 Use of HTTP State Management October 2000
items) and thus cause the shared state to be discarded, and
service asserts that it will not disclose the user's shopping
browsing habits to third parties without the user's consent
Note that the HTTP State Management protocol effectively allows
service provider to refuse to provide a service, or provide a
level of service, if the user or a user's client fails to honor
request to maintain session state. Absent legal prohibition to
contrary, the server MAY refuse to provide the service, or provide
reduced level of service, under these conditions. As a
practical consideration, services designed to utilize HTTP
Management may be unable to function properly if the client does
provide it. Such servers SHOULD gracefully handle such
and explain to the user why the full level of service is
available
2.2. Problematic
The following uses of HTTP State Management are deemed
and contrary to this specification
2.2.1. Leakage of Information to Third
HTTP State Management MUST NOT be used to leak information about
user or the user's browsing habits to other parties besides the
or service, without the user's explicit consent. Such usage
prohibited even if the user's name or other externally-
identifier are not exposed to other parties, because the
management mechanism itself provides an identifier which can be
to compile information about the user
Because such practices encourage users to defeat HTTP
Management mechanisms, they tend to reduce the effectiveness of
State Management, and are therefore considered detrimental to
operation of the web
2.2.2. Use as an Authentication
It is generally inappropriate to use the HTTP State
protocol as an authentication mechanism. HTTP State Management
not designed with such use in mind, and safeguards for protection
authentication credentials are lacking in both the
specification and in widely deployed HTTP clients and servers.
HTTP sessions are not encrypted and "cookies" may therefore
exposed to passive eavesdroppers. Furthermore, HTTP clients
servers typically store "cookies" in cleartext with little or
protection against exposure. HTTP State Management therefore
Moore & Freed Best Current Practice [Page 4]
RFC 2964 Use of HTTP State Management October 2000
NOT be used as an authentication mechanism to protect
from being exposed to unauthorized parties, even if the HTTP
are encrypted
The prohibition against using HTTP State Management
authentication includes both its use to protect information which
provided by the service, and its use to protect potentially
information about the user which is entrusted to the service's care
For example, it would be inappropriate to expose a user's name
address, telephone number, or billing information to a client
merely presented a cookie which had been previously associated
the user
Similarly, HTTP State Management SHOULD NOT be used to
user requests if unauthorized requests might have undesirable side
effects for the user, unless the user is aware of the potential
such side-effects and explicitly consents to such use. For example
a service which allowed a user to order merchandise with a
"click", based entirely on the user's stored "cookies",
inconvenience the user by requiring her to dispute charges to
credit card, and/or return the unwanted merchandise, in the
that the cookies were exposed to third parties
Some uses of HTTP State Management to identify users may
relatively harmless, for example, if the only information which
be thus exposed belongs to the service, and the service will
little harm from the exposure of such information
3. User Interface Considerations for HTTP State
HTTP State Management has been very controversial because of
potential to expose information about a user's browsing habits
third parties, without the knowledge or consent of the user.
such exposure is possible, this is less a flaw in the protocol
than a failure of HTTP client implementations (and of some
of HTTP-based services) to protect users' interests
As implied above, there are other ways to maintain session state
using HTTP State Management, and therefore other ways in which users
browsing habits can be tracked. Indeed, it is difficult to
how the HTTP protocol or an HTTP client could actually prevent
service from disclosing a user's "click trail" to other parties
the service chose to do so. Protection of such information
inappropriate exposure must therefore be the responsibility of
service. HTTP client implementations inherently cannot provide
protection, though they can implement countermeasures which make
more difficult for HTTP State Management to be used as the
by which such information is exposed
Moore & Freed Best Current Practice [Page 5]
RFC 2964 Use of HTTP State Management October 2000
It is arguable that HTTP clients should provide more protection
general against inappropriate exposure of tracking information
regardless of whether the exposure were facilitated by use of
State Management or by some other means. However, issues related
other mechanisms are beyond the scope of this memo
3.1. Capabilities Required of an HTTP
A user's willingness to consent to use of HTTP State Management
likely to vary from one service to another, according to whether
user trusts the service to use the information appropriately and
limit its exposure to other parties. The user therefore SHOULD
able to control whether his client supports a service's request
use HTTP State Management, on a per-service basis. In particular
(1) Clients MUST NOT respond to HTTP State Management
unless explicitly enabled by the user
(2) Clients SHOULD provide an effective interface which
users to review, and approve or refuse, any particular
from a server to maintain state information, before the
provides any state information to the server
(3) Clients SHOULD provide an effective interface which
users to instruct their clients to ignore all requests from
particular service to maintain state information, on a per
service basis, immediately in response to any
request from a server, before the client provides any
information to the server
(4) Clients SHOULD provide an effective interface which allows
user to disable future transmission of any state information
a service, and/or discard any saved state information for
service, even though the user has previously approved
service's request to maintain state information
(5) Clients SHOULD provide an effective interface which allows
user to terminate a previous request not to retain
management information for a given service
3.2. Limitations of the domain-match
The domain-match algorithm in RFC-2965 section 2 is intended as
heuristic to allow a client to "guess" whether or not two domains
part of the same service. There are few rules about how domain
can be used, and the structure of domain names and how they
delegated varies from one top-level domain to another (i.e.
client cannot tell which part of the domain was assigned to
Moore & Freed Best Current Practice [Page 6]
RFC 2964 Use of HTTP State Management October 2000
service). Therefore NO string comparison algorithm (including
domain-match algorithm) can be relied on to distinguish a domain
belongs to a particular service, from a domain that belongs
another party
As stated above, each service is ultimately responsible for
that user information is not inappropriately leaked to third parties
Leaking information to third parties via State Management by
selection of domain names, or by assigning domain names to
maintained by third parties, is at least as inappropriate as
the same information by other means
4. Security
This entire memo is about security considerations
5. Authors'
Keith
University of Tennessee Computer Science
1122 Volunteer Blvd, Suite 203
Knoxville TN, 37996-3450
EMail: moore@cs.utk.
Ned
Innosoft International, Inc
1050 Lakes
West Covina, CA 81790
EMail: ned.freed@innosoft.
6.
[RFC 1123] Braden, R., "Requirements for Internet Hosts --
Application and Support", STD 3, RFC 1123, October 1989.
[RFC 2965] Kristol, D. and L. Montulli, "HTTP State
Mechanism", RFC 2965, October 2000.
[RFC 2109] Kristol, D. and L. Montulli, "HTTP State
Mechanism", RFC 2109, February 1997.
Moore & Freed Best Current Practice [Page 7]
RFC 2964 Use of HTTP State Management October 2000
7. Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Moore & Freed Best Current Practice [Page 8]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
