Re: GET and referer security considerations

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 UTC