Problem with nonces and HTTP GET

[Peter Watkins]

On Fri, Jan 22, 2010 at 10:06:48AM -0800, Andrew Arnott wrote:
> Ideally we could use POST, but avoid the browser warning that information is
> crossing the SSL world into the non-SSL world.  This might be arguable
> anyway since sending information can be done with GET or POST, so why warn
> for POST and not for GET? 

I think you answered that in your first email -- GET is supposed to be "safe".

> If we can get browsers to not warn for POST we're
> gold.

That's a huge if. And one that I wouldn't want. It would make life a little
bit easier for OpenID users, but at what cost?

I thought maybe the server could somehow indicate to the browser that 
the POST was OK, not to warn. But I think the main purpose of the https-vs-http
warnings is to let the end user see when the servers are downgrading
the channel security, so the end user can decide whether to allow it.
RFC 2616, section 9.1.1:

  Naturally, it is not possible to ensure that the server does not 
  generate side-effects as a result of performing a GET request; in fact, 
  some dynamic resources consider that a feature. The important 
  distinction here is that the user did not request the side-effects, 
  so therefore cannot be held accountable for them. 

If users are not held accountable for the side effects of GET requests, 
there's little reason to warn them about simple GET redirects.

Of course a lot of the old RFCs on HTTP seem quaint when one considers
current client-side technology, for instance how client-side scripting
can turn a simple HTML <A> hyperlink into a trigger for a POST request.

-Peter