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