It is generally considered to be good practice to make URIs (the identifiers of resources on the web) as stable as possible. However, there are many things on the Web that will not last forever; many of those by design. Some of those even disappear according to a schedule, such as an archive that stores resources only for a limited period of time, or transient services such as URI shorteners that may only provide redirection services for a fixed period of time.
A little while ago in a thread on apps-discuss it was discussed that a mechanism for exposing this information could be made available through an HTTP header field.
It may be interesting for clients to know that some resources will become unavailable at a certain point in time. Clients can either inform their users, or maybe adjust their application logic. The newly proposed HTTP Sunset header field takes a very simple form to convey this information in an HTTP response:
Sunset: Sat, 31 Dec 2016 23:59:59 GMT
A client seeing such a header field in a response may conclude that it is likely that the resource will become unavailable at that point in time. It may start serving 404, 410, or some 3xx code, depending on how the service is designed (it is conceivable that they report 451, if they have been taken down for legal reasons).
And how does all of this relate to caching? Not at all, actually. The important thing to understand about Sunset is that it is all about resource expiration, and not resource state expiration. HTTP caching tells you how to hold on to resource state so that you can reliably reuse representations. Sunset tells you when a URI might go out of business, but tells you nothing about if and when it might change state before doing so. Which means that even if a resource advertises a Sunset, regular caching information and methods may still apply and have the same HTTP semantics as always.
If you think this kind of information is useful, but would like to see additional features, please raise an issue on GitHub, and/or share your feedback and opinion on the apps-discuss email list.
Comments