- From: Ross Patterson <Ross_Patterson@ns.reston.vmd.sterling.com>
- Date: Thu, 26 Jun 97 18:03:41 EDT
- To: http-wg@cuckoo.hpl.hp.com
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 >optional 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 information. 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