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

Re: GET and referer security considerations

From: David W. Morris <dwm@xpasc.com>
Date: Wed, 2 Jul 1997 22:13:52 -0700 (PDT)
To: Andrew Daviel <advax@triumf.ca>
Cc: Matthew Rubenstein <ruby@name.net>, http-wg@cuckoo.hpl.hp.com
Message-Id: <Pine.GSO.3.96.970702221015.29438A-100000@shell1.aimnet.com>


On Wed, 2 Jul 1997, Andrew Daviel wrote:

> On Wed, 2 Jul 1997, Matthew Rubenstein wrote:
> 
> > 	Submitting a <FORM> via GET is bad for several reasons. The insecurity of
> > the subsequent GET/HEAD/POST request's REFERER field containing information
> > intended to be private is an important consideration. It is also important
> > to realize that the info-encoded URL will likely be visible in the UA, in
> 
> I think the convention is to use POST for submitting information and GET
> for queries (like search engines). POST results may not be cached; so
> if the result is a list of links, exploring several links
> in a simplistic manner may require re-posting the form data each time
> one goes back to the list - clearly an inefficient process. So 
> GET is not always bad.
> 
> Andrew
> 
> (this was a real example from the IBM patent server, but I didn't
> investigate to check Expires headers, etc. Netscape 3.0 made me re-post)

This is another example of a broken relationship between the history
list and caching. I don't know if your example is a POST but there is
a possiblity that what you are seeing from the server has an 
exception HTTP status (not 200, etc.) which the browsers refuse
to leave alone in the history list but insist in resubmitting each
time. A real pain when what is there is a real error, perhaps
temporary, but you have to suffer the error delay if for any reason
you want to navigate the history list.

Dave Morris
Received on Wednesday, 2 July 1997 22:17:20 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:45 EDT