-1

I understand that some HTTP status codes are cacheable by default. From RFC 7231:

6.1. Overview of Status Codes

Responses with status codes that are defined as cacheable by default (e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501 in this specification) can be reused by a cache with heuristic expiration unless otherwise indicated by the method definition or explicit cache controls [RFC7234]; all other status codes are not cacheable by default.

Why is HTTP status code 451 cacheable by default? From RFC 7725:

3. 451 Unavailable For Legal Reasons

... A 451 response is cacheable by default, i.e., unless otherwise indicated by the method definition or explicit cache controls...

451 is a new HTTP status code used for signifying a resource that is unavailable for legal reasons e.g. such as for copyright issues. GitHub uses it for DMCA notice'd repositories.

A resource that was legally unavailable yesterday might be made available today. I understand obviously that caches are short-term, so 404 being cacheable makes sense, but I would have thought that when it comes to matters of legal censorship, currentness would be of vital importance. Why then should this status code be cacheable by default? A response could specify when it wants the status code to be cached, when the responder believes that the resource will remain blocked for a while.

Community
  • 1
  • 1
ShivanKaul
  • 505
  • 1
  • 6
  • 21

1 Answers1

2

The second section of RFC 7234 you mention (4.2.3) is not related to Response Codes, it is only talking about request methods - it is distinguishing GET, HEAD and theoretically POST from other methods such as DELETE, PUT, etc. As such, it has no bearing on why the authors of RFC 7725 defined response code 451 as cacheable.

A more relevant comparison is to the other status codes mentioned in section 6.1, which include 206 (modified by proxy), 301 (redirect), 404 (not found), and many others. The cacheability here doesn't imply that the status will never change in future; rather it means that the status is not likely to change in the short term, so two identical requests within a short period will result in the same response, and can safely be skipped. Contrastingly, status 201 (Created) is not marked as cacheable by default, because a second identical request would have a different result (creating a second copy) or a different response (e.g. returning the existing resource with status 200).

Status 451 is cacheable in the sense that retrying 30 seconds later is unlikely to reveal the resource. Retrying 30 days later might well have a different result, but that can be indicated by expiry and cache control headers, and by sensible defaults in the cache implementation.

404 is a particularly good comparison, since this is a plausible alternative to 451 in many cases - the resource is not available, and there may be no way to make it available. But 404 is cacheable by default because repeatedly requesting a missing page isn't going to make it suddenly appear, so a cache can usefully skip requests until a communicated lifetime is reached.

IMSoP
  • 65,743
  • 7
  • 83
  • 127
  • I updated the question to remove section on request methods. – ShivanKaul Jul 23 '17 at 19:25
  • Then feel free to ignore the first paragraph here, but the rest of my answer stands. – IMSoP Jul 23 '17 at 19:27
  • Would you mind striking out or removing the first paragraph so this question-answer is useful to someone who comes upon it in the future? You can mention that it was removed because of a mistake in the question. – ShivanKaul Jul 23 '17 at 19:42