HTTP 302 Found responses with Cache Headers not being cached

[mklein0]

The particular use case for this problem is the JFrog Artifactory uses 302 Found responses for signed URLs to cloud storage in HTTP requests to their PYPI proxy cache. Python PIP which leverages the CacheControl library in turn fails to cache those responses and downloads the packages everytime. This is a pain for CI processes which download large packages like PyTorch.

Additionally RFC2616 section 10.3.3 claims the 302 Found HTTP response can be cached if the Cache-Control or Expires response headers are present.

[woodruffw]

Hi @mklein0, thanks for opening an issue.

I think the reason we don't cache this is because the various RFCs are ambiguous about temporary redirects vs. permanent ones: RFC 2616 doesn't proscribe caching for these ("cacheable" isn't qualified by SHOULD or similar), while RFC 7231 doesn't mention caching for 302 at all and RFC 7234 mentions only permanent redirects explicitly.

I'm not opposed to changing this per se, but I'd like to better understand why JFrog is using HTTP 302 instead of HTTP 301 for these redirects -- ideally this is something they'd fix on their own end, since other mirror indices don't appear to have this problem.

[woodruffw]

(More broadly, I agree with the appraisal in pypa/pip#13396 (comment) -- it would be good to better understand the intended behavior here, since a signed URL strongly suggests that caching shouldn't be done.)

[mklein0]

As you pointed out the standards are vague on required behavior, so I interpretted it as a suggestion as well. I do not know how common the usage of a private CDN redirect is, so I thought to bring it up and see if there is a best practice.

I will take these two tickets to JFROG and have them advocate for a behavior or have them alter theirs. Thank you.