10 ms·

The Sunset HTTP Header Field

159 points by okket 7y ago

chrismorgan 7y ago
tools.ietf.org (and only that site) seems to be down for me at present, failing in the TLS handshake, PR_CONNECT_RESET_ERROR. Here’s another URL for the content: https://www.rfc-editor.org/rfc/rfc8594.txt https://www.rfc-editor.org/rfc/rfc8594.txt
- Spare_account 7y ago
  FWIW tools.ietf.org is working for me.
peterkelly 7y ago
Google could use this whenever they launch a new service!
- FerretFred 7y ago
  LOLLLL.. if there was an equivalent of Reddit Gold I'd award you that :)
politelemon 7y ago
I am not sure if Sunset is the best term here. Sunsetting in such a context would indicate retirement: https://en.wikipedia.org/wiki/Application_retirement https://en.wikipedia.org/wiki/Application_retirement However the example given is indicative of a session duration, not a sunset period. > For example, a pending shopping order represented by a resource may already list all order details, but it may only exist for a limited time unless it is confirmed and only then becomes an acknowledged shopping order. Admittedly, naming things is hard, perhaps this could have been called Expiry: or Unavailable-After: or Valid-Until:
- rpc3 7y ago
  My impression was the shopping example would be more aligned with something like delivery info -- it's not there just for a session, but a month after the package is marked "delivered" it's probably at least marked for deletion. (To be fair, I'm not sure announcing that kind of mid-term expiry is a real need-to-be-filled in today's web.)
- shakna 7y ago
  Well, we already have Expires for marking responses as stale in cache, and it's also takes just a date string, so things could get confusing there.
  - politelemon 7y ago
    Perhaps we could Sunset the Expires header first...
- combatentropy 7y ago
  I hate Sunset too, albeit for a different reason. It's businessese, like Legacy, Utilize, and for that matter, Retire (in this sense). Choose the word that is old, short, and plain. Sunset is a little better than others because at least it is poetic. But for my HTTP headers I would prefer something a little more straightforward, rather than euphemistic --- like Expires, but that's already taken.
rpc3 7y ago
I'm kind of torn here, because I could see this being really useful for web archivists -- e.g. the people who jumped to try to preserve as much of Tumblr as possible as that seems to be "sunsetting" -- but the sites that are actually likely to configure this properly are the very ones I'd expect to have some of the best already-existing archives of. If someone cares enough to set this header, they probably also care enough to try to preserve things reasonably well, or at least have users who do. The other use cases listed in the RFC don't seem incredibly compelling. Anyone have one that comes to mind?
- deadwisdom 7y ago
  The most compelling use-case for me is the web-api deprecation. It very clearly tells you when a service will no longer be available. Currently there are no standard mechanisms for this and are mostly driven by documentation. If an api used this then a consumer could look for these and raise alarm bells.
  - sbergot 7y ago
    That is the first thing I thought of. We had several case of partners API being deprecated and we were not notified in a timely manner. This could be used to trigger monitoring alerts.
  - wongarsu 7y ago
    There are also plenty of services that host user content, but only for a short period of time. Pastebin entries with a set expiration could for example set this header to inform clients about the expiration date. That way software can detect links to content that will expire and act accordingly.
    - deadwisdom 7y ago
      Yes, and I think that's the smartness of this is they clearly came from a stance of Deprecation and realized they could make it more general. Good work, imo.
pawelk 7y ago
I really like this idea. I used to work in advertising/marketing and we were launching a lot of purpose built, short-lived landing pages, e.g. to collect entries in a contest, then announce the winners. These websites were live for a period specified in the contest terms, then usually archived. I could see myself routinely implementing this header in such cases. Also, from the resource consumer point of vie this could help guide efforts like archive.org to make snapshots before it's too late.
skrebbel 7y ago
I'm aware that the following is typical HN middlebrow matter, but I'm asking anyway. Does anyone know why RFCs are still formatted as if they were written on a typewriter in the seventies? I mean, here's a sentence quoted verbatim from this document: Sunset header fields will be served as soon as the sunset date is Wilde Informational [Page 9] -------------------------------------------------------------------------- RFC 8594 Sunset Header May 2019 less than some given period of time. What problem does this solve? How is this more useful than it is cumbersome? also, how do people write this? Do they manually space space space space align the footer and then copy it every 30 or so lines?
- _pmf_ 7y ago
  https://www.rfc-editor.org/pubprocess/tools/ https://www.rfc-editor.org/pubprocess/tools/
- tinus_hn 7y ago
  You can read it with any software you like, now and in 30 years when Microsoft Word is a quaint relic in a museum.
  - jl6 7y ago
    To be fair, I recall having conversations in the 1990s about how MS Word was such an evil proprietary format and that one day we wouldn’t be able to read it. And here we are nearly 30 years later and Word docs (in a much evolved file format) are still here and still widely supported and easy to read using many tools, including open source ones. Not saying that proprietary formats aren’t still a bad idea for other reasons, but predictions of unreadability don’t seem to have panned out for any common file formats.
    - tinus_hn 7y ago
      Good luck editing these WordPerfect and CorelDraw files!
sascha_sl 7y ago
This RFC is really indicative of what I hate about certain standards. This is all very abstract. No user agent will use this in the same way. You'll end up writing code per application anyway. All this is is a convention that people will interpret a bunch into. This is not going to be interoperable. The epitome of this is ActivityPub.
- userbinator 7y ago
  It's not surprising, almost anyone can publish an RFC by doing the appropriate bureaucracy so there are plenty of RFCs which no one really cares about.
- derefr 7y ago
  What does it matter what the UA does with the information? The point is that the information is supplied; the UA can provide whatever benefit from it that the user wants from it. For example, I was just thinking that forum software could have their backends scrape image links you attempt to embed; and, if they find that the link has a sunset policy (e.g. it was from an anonymous image upload service that expires posts after a week), then they could rehost the image instead of hotlinking to it. (Or, cache the image for now, and then rewrite the link from a hotlink to a cached link when the deadline hits.) That’s not something you would standardize behaviour on. But, once you have servers providing the information—not to a particular client, but just spewing it out as an objective fact out into the world—clients can do all sorts of things.
  - jimktrains2 7y ago
    Or HTTP-based APIs could check for it and write out log entries or send out alerts to notify ops or the devs that they'll need to investigate further as to how this affects them.
  - sascha_sl 7y ago
    Standardisation does nothing for this. The software could've always just used an X-Sunset header or just another field in their dto. My point was that there will never be a client that will blindly read that value and understand what to do with it. Which is why the only difference to "X-Sunset" is that there's an RFC with suggestions on how it could potentially be meant there, along with a syntax restriction. ActivityPub is the epitome of this because they supply a lot of vocabulary and syntax variation to express them (including very complex ways to normalise that syntax, JSON-LD is not fun to parse) but doesn't actually made the implementation commit to anything. It's setting up a bunch of arbitrary rules for nothing. Every single AP implementation still orients itself on compatibility with Mastodon.
DomreiRoam 7y ago
At WS-REST 2015(I think), I did talk about this with Erik Wilde (@dret), and we talked about the fact that is no good way to deprecate bookmarked url or an url stored in an uncommitted transaction. The idea was to add information so clients and user agent could keep track of resources: you can check it before their sunset date. The resource then could change the sunset date or redirect you to the new url.
ihuman 7y ago
I'm happy to see this is finally entering the RFC phase. I've already seen this used in the wild for an API (imgur [0]), and I was surprised when they linked to the proposal from 2017 [1] [0] https://apidocs.imgur.com/?version=latest#api-deprecation https://apidocs.imgur.com/?version=latest#api-deprecation [1] https://tools.ietf.org/id/draft-wilde-sunset-header-03.html https://tools.ietf.org/id/draft-wilde-sunset-header-03.html
scottrblock 7y ago
I'm afraid this won't be useful in the real world. API consumers who continue to use legacy endpoints after being told not to are unlikely to update their code to listen to a new HTTP header. This strikes me as a great idea in theory, but unlikely to be useful to websites actually looking to deprecate endpoints.
- derefr 7y ago
  I don’t think this is intended to be about endpoints, but rather about the resources under an endpoint. E.g., “this image will be deleted from this image-hosting service in 30 days” or “this is a link to an item in your Dropbox Trash folder, and the Trash is emptied every 48 hours” or even “this is a temporary share link and will work for 24 hours.” Given these use-cases, I could also see the use of a version of the header that doesn’t specify when the retirement of the resource will happen, but just specifies that the resource is, by design, not going to stick around forever. E.g. the URL of a “previous version” of something, where the system only keeps around N previous versions (so as soon as someone adds enough newer versions, the version you’ve linked to will disappear.) Another fun use-case is sticking this header on everything on a given domain (by e.g. reconfiguring your web load-balancer to emit the header.) Archive.org could then use this as a signal to automatically prioritize archiving content from the domain, before any human being realizes the service is being retired and prioritizes that archiving.
SergeAx 7y ago
Was looking for a way to tell API client about endpoint deprecation and stumbled upon another RFC from Feb 2019: https://tools.ietf.org/html/draft-dalal-deprecation-header-00 https://tools.ietf.org/html/draft-dalal-deprecation-header-0... Actually, "E. Wilde" is on of the authors there too.
- okket 7y ago
  That is an early stage draft, not a RFC.
doubletgl 7y ago
Terribly vague naming. As a non-native speaker I would've never guessed the purpose, and I've been in the English speaking tech sphere for many years. Does anybody actually say "this website will sunset in 5 years"?
- news_to_me 7y ago
  I've heard the term used for deprecation before, but not in a long time. I agree it's not great. At least they spelled it right, though!
  - whatshisface 7y ago
    Tech is never really deprecated; instead, like the setting sun, it simply departs to rise again another morning (when a web developer independently re-discovers it).
- save_ferris 7y ago
  Some big companies do, but I never heard a startup use the term.
0x70dd 7y ago
The header that inspired Evan Spiegel

159 points by okket 7y ago

tools.ietf.org (and only that site) seems to be down for me at present, failing in the TLS handshake, PR_CONNECT_RESET_ERROR. Here’s another URL for the content: https://www.rfc-editor.org/rfc/rfc8594.txt https://www.rfc-editor.org/rfc/rfc8594.txt

Spare_account 7y ago
FWIW tools.ietf.org is working for me.

peterkelly 7y ago

Google could use this whenever they launch a new service!

FerretFred 7y ago
LOLLLL.. if there was an equivalent of Reddit Gold I'd award you that :)

politelemon 7y ago

I am not sure if Sunset is the best term here. Sunsetting in such a context would indicate retirement: https://en.wikipedia.org/wiki/Application_retirement https://en.wikipedia.org/wiki/Application_retirement However the example given is indicative of a session duration, not a sunset period. > For example, a pending shopping order represented by a resource may already list all order details, but it may only exist for a limited time unless it is confirmed and only then becomes an acknowledged shopping order. Admittedly, naming things is hard, perhaps this could have been called Expiry: or Unavailable-After: or Valid-Until:

rpc3 7y ago
My impression was the shopping example would be more aligned with something like delivery info -- it's not there just for a session, but a month after the package is marked "delivered" it's probably at least marked for deletion. (To be fair, I'm not sure announcing that kind of mid-term expiry is a real need-to-be-filled in today's web.)
shakna 7y ago
Well, we already have Expires for marking responses as stale in cache, and it's also takes just a date string, so things could get confusing there.
- politelemon 7y ago
  Perhaps we could Sunset the Expires header first...
combatentropy 7y ago
I hate Sunset too, albeit for a different reason. It's businessese, like Legacy, Utilize, and for that matter, Retire (in this sense). Choose the word that is old, short, and plain. Sunset is a little better than others because at least it is poetic. But for my HTTP headers I would prefer something a little more straightforward, rather than euphemistic --- like Expires, but that's already taken.

rpc3 7y ago

I'm kind of torn here, because I could see this being really useful for web archivists -- e.g. the people who jumped to try to preserve as much of Tumblr as possible as that seems to be "sunsetting" -- but the sites that are actually likely to configure this properly are the very ones I'd expect to have some of the best already-existing archives of. If someone cares enough to set this header, they probably also care enough to try to preserve things reasonably well, or at least have users who do. The other use cases listed in the RFC don't seem incredibly compelling. Anyone have one that comes to mind?

deadwisdom 7y ago
The most compelling use-case for me is the web-api deprecation. It very clearly tells you when a service will no longer be available. Currently there are no standard mechanisms for this and are mostly driven by documentation. If an api used this then a consumer could look for these and raise alarm bells.
- sbergot 7y ago
  That is the first thing I thought of. We had several case of partners API being deprecated and we were not notified in a timely manner. This could be used to trigger monitoring alerts.
- wongarsu 7y ago
  There are also plenty of services that host user content, but only for a short period of time. Pastebin entries with a set expiration could for example set this header to inform clients about the expiration date. That way software can detect links to content that will expire and act accordingly.
  - deadwisdom 7y ago
    Yes, and I think that's the smartness of this is they clearly came from a stance of Deprecation and realized they could make it more general. Good work, imo.

pawelk 7y ago

I really like this idea. I used to work in advertising/marketing and we were launching a lot of purpose built, short-lived landing pages, e.g. to collect entries in a contest, then announce the winners. These websites were live for a period specified in the contest terms, then usually archived. I could see myself routinely implementing this header in such cases. Also, from the resource consumer point of vie this could help guide efforts like archive.org to make snapshots before it's too late.

skrebbel 7y ago

I'm aware that the following is typical HN middlebrow matter, but I'm asking anyway. Does anyone know why RFCs are still formatted as if they were written on a typewriter in the seventies? I mean, here's a sentence quoted verbatim from this document: Sunset header fields will be served as soon as the sunset date is Wilde Informational [Page 9] -------------------------------------------------------------------------- RFC 8594 Sunset Header May 2019 less than some given period of time. What problem does this solve? How is this more useful than it is cumbersome? also, how do people write this? Do they manually space space space space align the footer and then copy it every 30 or so lines?

_pmf_ 7y ago
https://www.rfc-editor.org/pubprocess/tools/ https://www.rfc-editor.org/pubprocess/tools/
tinus_hn 7y ago
You can read it with any software you like, now and in 30 years when Microsoft Word is a quaint relic in a museum.
- jl6 7y ago
  To be fair, I recall having conversations in the 1990s about how MS Word was such an evil proprietary format and that one day we wouldn’t be able to read it. And here we are nearly 30 years later and Word docs (in a much evolved file format) are still here and still widely supported and easy to read using many tools, including open source ones. Not saying that proprietary formats aren’t still a bad idea for other reasons, but predictions of unreadability don’t seem to have panned out for any common file formats.
  - tinus_hn 7y ago
    Good luck editing these WordPerfect and CorelDraw files!

sascha_sl 7y ago

This RFC is really indicative of what I hate about certain standards. This is all very abstract. No user agent will use this in the same way. You'll end up writing code per application anyway. All this is is a convention that people will interpret a bunch into. This is not going to be interoperable. The epitome of this is ActivityPub.

userbinator 7y ago
It's not surprising, almost anyone can publish an RFC by doing the appropriate bureaucracy so there are plenty of RFCs which no one really cares about.
derefr 7y ago
What does it matter what the UA does with the information? The point is that the information is supplied; the UA can provide whatever benefit from it that the user wants from it. For example, I was just thinking that forum software could have their backends scrape image links you attempt to embed; and, if they find that the link has a sunset policy (e.g. it was from an anonymous image upload service that expires posts after a week), then they could rehost the image instead of hotlinking to it. (Or, cache the image for now, and then rewrite the link from a hotlink to a cached link when the deadline hits.) That’s not something you would standardize behaviour on. But, once you have servers providing the information—not to a particular client, but just spewing it out as an objective fact out into the world—clients can do all sorts of things.
- jimktrains2 7y ago
  Or HTTP-based APIs could check for it and write out log entries or send out alerts to notify ops or the devs that they'll need to investigate further as to how this affects them.
- sascha_sl 7y ago
  Standardisation does nothing for this. The software could've always just used an X-Sunset header or just another field in their dto. My point was that there will never be a client that will blindly read that value and understand what to do with it. Which is why the only difference to "X-Sunset" is that there's an RFC with suggestions on how it could potentially be meant there, along with a syntax restriction. ActivityPub is the epitome of this because they supply a lot of vocabulary and syntax variation to express them (including very complex ways to normalise that syntax, JSON-LD is not fun to parse) but doesn't actually made the implementation commit to anything. It's setting up a bunch of arbitrary rules for nothing. Every single AP implementation still orients itself on compatibility with Mastodon.

DomreiRoam 7y ago

At WS-REST 2015(I think), I did talk about this with Erik Wilde (@dret), and we talked about the fact that is no good way to deprecate bookmarked url or an url stored in an uncommitted transaction. The idea was to add information so clients and user agent could keep track of resources: you can check it before their sunset date. The resource then could change the sunset date or redirect you to the new url.

ihuman 7y ago

I'm happy to see this is finally entering the RFC phase. I've already seen this used in the wild for an API (imgur [0]), and I was surprised when they linked to the proposal from 2017 [1] [0] https://apidocs.imgur.com/?version=latest#api-deprecation https://apidocs.imgur.com/?version=latest#api-deprecation [1] https://tools.ietf.org/id/draft-wilde-sunset-header-03.html https://tools.ietf.org/id/draft-wilde-sunset-header-03.html

scottrblock 7y ago

I'm afraid this won't be useful in the real world. API consumers who continue to use legacy endpoints after being told not to are unlikely to update their code to listen to a new HTTP header. This strikes me as a great idea in theory, but unlikely to be useful to websites actually looking to deprecate endpoints.

derefr 7y ago
I don’t think this is intended to be about endpoints, but rather about the resources under an endpoint. E.g., “this image will be deleted from this image-hosting service in 30 days” or “this is a link to an item in your Dropbox Trash folder, and the Trash is emptied every 48 hours” or even “this is a temporary share link and will work for 24 hours.” Given these use-cases, I could also see the use of a version of the header that doesn’t specify when the retirement of the resource will happen, but just specifies that the resource is, by design, not going to stick around forever. E.g. the URL of a “previous version” of something, where the system only keeps around N previous versions (so as soon as someone adds enough newer versions, the version you’ve linked to will disappear.) Another fun use-case is sticking this header on everything on a given domain (by e.g. reconfiguring your web load-balancer to emit the header.) Archive.org could then use this as a signal to automatically prioritize archiving content from the domain, before any human being realizes the service is being retired and prioritizes that archiving.

SergeAx 7y ago

Was looking for a way to tell API client about endpoint deprecation and stumbled upon another RFC from Feb 2019: https://tools.ietf.org/html/draft-dalal-deprecation-header-00 https://tools.ietf.org/html/draft-dalal-deprecation-header-0... Actually, "E. Wilde" is on of the authors there too.

okket 7y ago
That is an early stage draft, not a RFC.

doubletgl 7y ago

Terribly vague naming. As a non-native speaker I would've never guessed the purpose, and I've been in the English speaking tech sphere for many years. Does anybody actually say "this website will sunset in 5 years"?

news_to_me 7y ago
I've heard the term used for deprecation before, but not in a long time. I agree it's not great. At least they spelled it right, though!
- whatshisface 7y ago
  Tech is never really deprecated; instead, like the setting sun, it simply departs to rise again another morning (when a web developer independently re-discovers it).
save_ferris 7y ago
Some big companies do, but I never heard a startup use the term.

0x70dd 7y ago

The header that inspired Evan Spiegel