- From: Scott Lawrence <lawrence@agranat.com>
- Date: Wed, 02 Jul 1997 15:11:37 -0400
- To: http-wg@cuckoo.hpl.hp.com
>>>>> "DM" == Dave Morris DM> The BCP suggestion is valid in any case, but from an HTTP perspective, DM> there has never been a distinction between the piece of software known as DM> the server and applications it may launch ... the composite is "the DM> server". But in practice there really is an important distinction. Despite the fact that it is out of fashion to discuss any layer between transport and application in the ISO model, HTTP is really right in there. Sometimes the thing that implements it is also the application (as an httpd serving static documents), but more and more often now it is not. >>>>> "KH" == Koen Holtman <koen@win.tue.nl> writes: KH> I did not mean to specify a restriction which a poor httpd could KH> never enforce by itself. The following restatement would also work: KH> Authors of services which use the HTTP protocol SHOULD NOT use ..... That would be much better wording. My main concern because it makes clear what software is constrained here (in this case, it is something written in HTML - the ACTION attribute of the FORM). Now whether or not the HTTP specification is the most effective place for that (given that most form authors probably will never read it) is another question... >>>>> "LM" == Larry Masinter <masinter@parc.xerox.com> writes: LM> Why don't I ask for volunteers to draft a sentence or two on the LM> general issue of security/privacy around 'Referer:' and when it LM> should and shouldn't be sent. If the advice is "Never, unless blah". The RFC already has: 14.37 Referer [...] 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. Perhaps this issue should be forwareded to the W3C people who are preparing yet another revision of HTML... -- Scott Lawrence EmWeb Embedded Server <lawrence@agranat.com> Agranat Systems, Inc. Engineering http://www.agranat.com/
Received on Wednesday, 2 July 1997 12:28:42 UTC