Should try to keep this at P3 unless this is tied to a particular milestone.

seems like cacheable POST responses would silently avoid POST-ing, but only within a browsing session.

gavinp: do you think it is an extension of the spec that all browsers use? or maybe it is by the spec, and just my reading of the spec is wrong? or maybe my reading of the code is wrong?

One place I have seen this is used is if there is a Save-As behavior to prevent having to repost or go over the network. Not sure about extension to spec though.

The spec is pretty clear, POST responses are cacheable. In RFC 2616, it required explicit cache control https://tools.ietf.org/html/rfc2616#section-9.5 :

   Responses to this method are not cacheable, unless the response
   includes appropriate Cache-Control or Expires header fields. However,
   the 303 (See Other) response can be used to direct the user agent to
   retrieve a cacheable resource.

RFC 7231 goes into much more detail:

   Responses to POST requests are only cacheable when they include
   explicit freshness information (see Section 4.2.1 of [RFC7234]).
   However, POST caching is not widely implemented.  For cases where an
   origin server wishes the client to be able to cache the result of a
   POST in a way that can be reused by a later GET, the origin server
   MAY send a 200 (OK) response containing the result and a
   Content-Location header field that has the same value as the POST's
   effective request URI (Section 3.1.4.2).

So, I don't think we're out of spec to store POST responses, although if we're using heuristic freshness, we sure are. I can't imagine that we would cache POST requests across sessions; that would require figuring out if the upload data streams were identical, and that's hard.

As to whether it conforms to spec to store POST responses that lack explicit freshness in the cache, I really don't know. It hinges on your interpretation of RFC 7234 3., which in part says:

   A cache MUST NOT store a response to any request, unless:

   o  The request method is understood by the cache and defined as being
      cacheable, and
   ...

And since the language there doesn't talk about the response despite the definition of POST talking about it... So I guess we're nonconformant. But I am not sad about it, isn't it only history navigation that's going to be affected?

I think even "reload" creates a distinct upload identifier, but I'm not sure.

Oups, wrong bug.

Does "not caching POST requests across sessions" include session restore, and navigating back in history to a POST?

As no one else has chimed in otherwise, going to mark this WontFix - cached POSTs are used for history navigations, save-as, and (presumably) session restore.