W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1997

Re: confidentiality and the referer field

From: Ross Patterson <Ross_Patterson@ns.reston.vmd.sterling.com>
Date: Thu, 26 Jun 97 18:03:41 EDT
Message-Id: <199706262236.AA00172@reston.vmd.sterling.com>
To: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3585
Matthew Rubenstein <ruby@name.net> writes:

>       We're defining the spec to specify a good protocol that reflects common
>usage. A good protocol allows developers to rely on essential conditions
>being reported/modeled in parameters. Worse than omission (which can often
>be worked around) is unreliable availability (which
>requires a mass of non-symmetrical code; cf "Cookie2").

>                                                        The disintegrity
>inherent in stateless HTTP already forces too many fall-back scenario
>handlers to offer developers a predictable C/S environment; making REFERER

RERERER is already optional.  RFC 2068 "HTTP 1.1" section 14.37 "Referer"
contains the following:

   Note: Because the source of a link may be private information or
   may 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

In fact, what Phill appears to be suggesting is that a server be able
to tell a compliant client how to set the toggle switch.

Ross Patterson
Sterling Software, Inc.
VM Software Division
Received on Thursday, 26 June 1997 15:34:34 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:20 UTC