> > The http+signature data could then be cashed just fine, and stored in > the clear. The web site could determine what to serve up that way to > maintain security. All POST commands would have to be HTTPS (data from > client to server), and of course sensitive information would be returned > HTTPS only.
Makes a lot of sense, but… Wouldn’t you also have to require that all GET commands (or at lest GET commands for strings containing a ? character) be sent via HTTPS? In many cases, there’s little difference between the data disclosure of a POST form vs. the disclosure achieved with GET URL?attribute=value&… Indeed, there are multiple libraries out there which allow one to treat the variables from POST data and the variables from GET “query strings” as virtually identical. I suspect that in most cases, the only reason said libraries distinguish is to maintain namespace separation in case of collisions (since query strings can also be applied to POST requests). > Why doesn't that exist? Because developers are lazy? Owen
