
The Sunset HTTP Header Field - okket
https://tools.ietf.org/html/rfc8594
======
skrebbel
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?

~~~
tinus_hn
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
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.

~~~
hedora
How do you open word documents from the 90’s?!? Do you have a Windows 95 VM or
something?

Even with modern Microsoft Word, the formatting of old documents is often
mangled.

To this day, up-to-date PowerPoint can’t reliably display presentations made
with up-to-date PowerPoint on a different machine, let alone OS!

~~~
okket
> How do you open word documents from the 90’s?

LibreOffice

------
peterkelly
Google could use this whenever they launch a new service!

------
sascha_sl
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.

~~~
derefr
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.

~~~
sascha_sl
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.

~~~
jayd16
>Standardisation does nothing for this

Sure it does. If the information is standardized then the community as a whole
can innovate around it. Browser plugins and the like can be made that make use
of the information, etc.

------
rpc3
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
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.

~~~
wongarsu
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
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.

------
politelemon
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:

~~~
shakna
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
Perhaps we could Sunset the Expires header first...

------
scottrblock
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
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.

------
DomreiRoam
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
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)

------
doubletgl
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
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
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).

------
pawelk
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.

------
SergeAx
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-0...](https://tools.ietf.org/html/draft-dalal-
deprecation-header-00)

Actually, "E. Wilde" is on of the authors there too.

~~~
okket
That is an early stage draft, not a RFC.

------
chrismorgan
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
FWIW tools.ietf.org is working for me.

------
0x70dd
The header that inspired Evan Spiegel

