/cc @bradfitz

Never considered either way.

The http.Client does no caching of responses at all. It's not just 301/308.

What is the context here? Is there a situation where this is causing problems? Also, if you are making the same request repeatedly, why is it problematic to be repeating the redirected call but not problematic to be repeating the final call?

I believe @Gaillard filed this issue since 301: Moved Permanently and 308: Permanent Redirect both have permanency in them, thus we can assume that those responses will never change, so perhaps we can consider these as cacheable.

The issue though is that what happens if we have uncapped/unlimited response caching and many responses are cached; what if a server responds with refresh deadline/tokens in the 301/308 responses?

@neild @bradfitz what do y'all think about the points that I raised here #29776 (comment)? Or perhaps we can use some sort of bounded cache or perhaps an LRU of fixed size containing domain+code whose keys when being evicted pop from the map[domain+code]->response

I don't think the defaults for net/http should have any caching at all, my expectation is for requests to correspond directly to requests sent on the wire.
Adding caching makes the behavior less predictable and subverts user control over the requests they send.