Should okhttp cache HTTP 307 (or 302) responses as per w3 doc?

I am using retrofit and okhttp in my android app to download documents, images and music files. The files are hosted on Amazon via a CDN, so the URLs change frequently. My backend server will try to use redirects to reduce the need to constantly update my content in the mobile app every time the CDN URL changes. Devices must also cache responses in case the device is offline. For this reason I use 301 redirects which I don't know is the best idea.

I was reading the description for 307 redirect to http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

10.3.8 307 Temporary Redirect

The requested resource resides temporarily under a different URI. 
Since the redirection MAY be altered on occasion, the client SHOULD 
continue to use the Request-URI for future requests. 
This response is only cacheable if indicated by a Cache-Control or Expires header field.

      

        
        
        
      

    

At http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html ,

13.4 - Response Cacheability

A response received with a status code of 200, 203, 206, 300, 301 or 410 
MAY be stored by a cache and used in reply to a subsequent request, 
subject to the expiration mechanism, unless a cache-control directive 
prohibits caching. However, a cache that does not support the Range and 
Content-Range headers MUST NOT cache 206 (Partial Content) responses.

A response received with any other status code 
(e.g. status codes 302 and 307) MUST NOT be returned in a reply to 
a subsequent request unless there are cache-control directives or another 
header(s) that explicitly allow it. For example, these include the 
following: an Expires header (section 14.21); a "max-age", "s-maxage", 
"must- revalidate", "proxy-revalidate", "public" or "private" 
cache-control directive (section 14.9).

      

        
        
        
      

    

It seems that the description states that caching is possible. I haven't tried this yet, but I noticed that in the ohttp class CacheStrategy.java it has the following code:

public static boolean isCacheable(Response response, Request request) {
    // Always go to network for uncacheable response codes (RFC 2616, 13.4),
    // This implementation doesn't support caching partial content.
    int responseCode = response.code();
    if (responseCode != HttpURLConnection.HTTP_OK // 200
        && responseCode != HttpURLConnection.HTTP_NOT_AUTHORITATIVE // 203
        && responseCode != HttpURLConnection.HTTP_MULT_CHOICE // 300
        && responseCode != HttpURLConnection.HTTP_MOVED_PERM / 301
        && responseCode != HttpURLConnection.HTTP_GONE) { // 410
    return false;
}

      

        
        
        
      

    

And to make sure caching is not enabled during 302-308, the tests unit from CacheTest.java states the following

for (int i = 302; i <= 308; ++i) {
  assertCached(false, i);
}

      

        
        
        
      

    

So the okhttp code explicitly ignores caching for 307 as well as 302. I just wanted to clarify this. Is the spec for 307 wrong? Or is there something wrong with 307 caching that it was intentionally excluded? If I were to set my own cache headers to 307 this would seem to be overlooked.

One more background information. I know Amazon will support caching with appropriate cache headers. But since I have to redirect my own backend, if I have no caching capability, my offline access to my redirect url will not respond to the fact that I have a cached version from the CDN locally. Of course, if I hadn't redirected from my backend and went straight to Amazon, then caching wouldn't be a problem through Amazon. Could you provide some guidance in this scenario?