Internet Engineering Task Force (IETF) E. Wilde
Request for Comments: 8594 May 2019
Category: Informational
ISSN: 2070-1721
Internet Engineering Task Force (IETF) E. Wilde
Request for Comments: 8594 May 2019
Category: Informational
ISSN: 2070-1721
The Sunset HTTP Header Field
日落HTTP头字段
Abstract
摘要
This specification defines the Sunset HTTP response header field, which indicates that a URI is likely to become unresponsive at a specified point in the future. It also defines a sunset link relation type that allows linking to resources providing information about an upcoming resource or service sunset.
该规范定义了Sunset HTTP响应头字段，该字段指示URI可能在将来的某个指定点变得无响应。它还定义了日落链接关系类型，允许链接到提供即将到来的资源或服务日落信息的资源。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8594.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8594.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Temporary Resources . . . . . . . . . . . . . . . . . . . 3
1.2. Migration . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Retention . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4. Deprecation . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The Sunset HTTP Response Header Field . . . . . . . . . . . . 4
4. Sunset and Caching . . . . . . . . . . . . . . . . . . . . . 5
5. Sunset Scope . . . . . . . . . . . . . . . . . . . . . . . . 6
6. The Sunset Link Relation Type . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7.1. The Sunset Response Header Field . . . . . . . . . . . . 7
7.2. The Sunset Link Relation Type . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Temporary Resources . . . . . . . . . . . . . . . . . . . 3
1.2. Migration . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Retention . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4. Deprecation . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The Sunset HTTP Response Header Field . . . . . . . . . . . . 4
4. Sunset and Caching . . . . . . . . . . . . . . . . . . . . . 5
5. Sunset Scope . . . . . . . . . . . . . . . . . . . . . . . . 6
6. The Sunset Link Relation Type . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7.1. The Sunset Response Header Field . . . . . . . . . . . . 7
7.2. The Sunset Link Relation Type . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
As a general rule, URIs should be stable and persistent so that applications can use them as stable and persistent identifiers for resources. However, there are many scenarios where, for a variety of reasons, URIs have a limited lifetime. In some of these scenarios, this limited lifetime is known in advance. In this case, it can be useful for clients if resources make this information about their limited lifetime known. This specification defines the Sunset HTTP response header field, which indicates that a URI is likely to become unresponsive at a specified point in the future.
作为一般规则，URI应该是稳定和持久的，以便应用程序可以使用它们作为资源的稳定和持久标识符。然而，在许多情况下，由于各种原因，URI的生命周期是有限的。在其中一些场景中，这一有限的生命周期是预先知道的。在这种情况下，如果资源使有关其有限生存期的信息为人所知，那么它对客户机是有用的。该规范定义了Sunset HTTP响应头字段，该字段指示URI可能在将来的某个指定点变得无响应。
This specification also defines a sunset link relation type that allows information to be provided about 1) the sunset policy of a resource or a service, and/or 2) upcoming sunsets, and/or 3) possible mitigation scenarios for resource/service users. This specification does not place any constraints on the nature of the linked resource, which can be targeted to humans, machines, or both.
本规范还定义了日落链接关系类型，该类型允许提供以下信息：1）资源或服务的日落策略，和/或2）即将到来的日落，和/或3）资源/服务用户可能的缓解方案。本规范对链接资源的性质没有任何限制，链接资源可以针对人、机器或两者。
Possible scenarios for known lifetimes of resources include, but are not limited to, the following scenarios.
已知资源生命周期的可能场景包括但不限于以下场景。
Some resources may have a limited lifetime by definition. 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. In such a case, the service managing the pending shopping order can make this limited lifetime explicit, allowing clients to understand that the pending order, unless confirmed, will disappear at some point in time.
根据定义，某些资源的生命周期可能是有限的。例如，由资源表示的待定购物订单可能已经列出了所有订单详细信息，但它可能只存在一段有限的时间，除非它得到确认，然后才成为已确认的购物订单。在这种情况下，管理挂起的购物订单的服务可以明确说明这一有限的生命周期，让客户理解，除非得到确认，否则挂起的订单将在某个时间点消失。
If resources are changing identity because a service migrates them, then this may be known in advance. While it may not yet be appropriate to use HTTP redirect status codes (3xx), it may be interesting for clients to learn about the service's plan to take down the original resource.
如果资源因为服务迁移而改变标识，那么这可能是事先知道的。虽然使用HTTP重定向状态代码（3xx）可能还不合适，但客户机了解服务删除原始资源的计划可能会感兴趣。
There are many cases where regulation or legislation require that resources are kept available for a certain amount of time. However, in many cases there is also a requirement for those resources to be permanently deleted after some period of time. Since the deletion of the resource in this scenario is governed by well-defined rules, it could be made explicit for clients interacting with the resource.
在许多情况下，法规或立法要求资源在一定时间内保持可用。然而，在许多情况下，还要求在一段时间后永久删除这些资源。由于此场景中资源的删除由定义良好的规则控制，因此可以为与资源交互的客户机显式删除资源。
For Web APIs one standard scenario is that an API or specific subsets of an API may get deprecated. Deprecation often happens in two stages: the first stage being that the API is not the preferred or recommended version anymore and the second stage being that the API or a specific version of the API gets decommissioned.
对于Web API，一个标准场景是API或API的特定子集可能会被弃用。弃用通常发生在两个阶段：第一阶段是API不再是首选或推荐版本，第二阶段是API或特定版本的API退役。
For the first stage (the API is not the preferred or recommended version anymore), the Sunset header field is not appropriate: at this stage, the API remains operational and can still be used. Other mechanisms can be used for signaling that first stage that might help with more visible deprecation management, but the Sunset header field does not aim to represent that information.
对于第一阶段（API不再是首选或推荐的版本），日落标题字段不合适：在这个阶段，API仍然可以运行，并且仍然可以使用。其他机制可用于发出第一阶段的信号，这可能有助于更明显的弃用管理，但日落标头字段并不表示该信息。
For the second stage (the API or a specific version of the API gets decommissioned), the Sunset header field is appropriate: that is when the API or a version does become unresponsive. From the Sunset header field's point of view, it does not matter that the API may not
对于第二阶段（API或特定版本的API退役），日落标头字段是合适的：即当API或版本没有响应时。从Sunset header字段的角度来看，API可能不存在并不重要
have been the preferred or recommended version anymore. The only thing that matters is that it will become unresponsive and that this time can be advertised using the Sunset header field.
已不再是首选或推荐的版本。唯一重要的是它将变得无响应，并且这一次可以使用Sunset header字段进行广告。
In this scenario, the announced sunset date typically affects all of the deprecated API or parts of it (i.e., just deprecated sets of resources), and not just a single resource. In this case, it makes sense for the API to define rules about how an announced sunset on a specific resource (such as the API's home/start resource) implies the sunsetting of the whole API or parts of it (i.e., sets of resources), and not just the resource returning the sunset header field. Section 5 discusses how the scope of the Sunset header field may change because of how a resource is using it.
在这种情况下，宣布的日落日期通常会影响所有不推荐使用的API或其部分（即，仅影响不推荐使用的资源集），而不仅仅影响单个资源。在这种情况下，API有必要定义关于特定资源（如API的home/start资源）上的已宣布日落如何暗示整个API或其部分（即资源集）日落的规则，而不仅仅是返回日落标头字段的资源。第5节讨论日落标头字段的范围如何因资源的使用方式而改变。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
The Sunset HTTP response header field allows a server to communicate the fact that a resource is expected to become unresponsive at a specific point in time. It provides information for clients that they can use to control their usage of the resource.
Sunset HTTP response header字段允许服务器传达这样一个事实，即某个资源在特定时间点预计将变得无响应。它为客户机提供信息，客户机可以使用这些信息来控制资源的使用。
The Sunset header field contains a single timestamp that advertises the point in time when the resource is expected to become unresponsive. The Sunset value is an HTTP-date timestamp, as defined in Section 7.1.1.1 of [RFC7231], and SHOULD be a timestamp in the future.
日落标头字段包含一个时间戳，该时间戳在资源预计将变得无响应时播发时间点。日落值是[RFC7231]第7.1.1.1节中定义的HTTP日期时间戳，将来应该是时间戳。
It is safest to consider timestamps in the past mean the present time, meaning that the resource is expected to become unavailable at any time.
考虑过去的时间戳是最安全的，这意味着该资源预期在任何时间变得不可用。
Sunset = HTTP-date
Sunset = HTTP-date
For example:
例如：
Sunset: Sat, 31 Dec 2018 23:59:59 GMT
Sunset: Sat, 31 Dec 2018 23:59:59 GMT
Clients SHOULD treat Sunset timestamps as hints: it is not guaranteed that the resource will, in fact, be available until that time and will not be available after that time. However, since this information is provided by the resource itself, it does have some credibility.
客户端应将日落时间戳视为提示：不能保证资源在该时间之前可用，并且在该时间之后不可用。然而，由于这些信息是由资源本身提供的，因此它确实具有一定的可信度。
After the Sunset time has arrived, it is likely that interactions with the resource will result in client-side errors (HTTP 4xx status codes), redirect responses (HTTP 3xx status codes), or the client might not be able to interact with the resource at all. The Sunset header field does not expose any information about which of those behaviors can be expected.
日落时间到达后，与资源的交互可能会导致客户端错误（HTTP 4xx状态代码）、重定向响应（HTTP 3xx状态代码），或者客户端可能根本无法与资源交互。Sunset header字段不公开任何关于哪些行为是可以预期的信息。
Clients not interpreting an existing Sunset header field can operate as usual and simply may experience the resource becoming unavailable without recognizing any notification about it beforehand.
不解释现有日落报头字段的客户端可以像往常一样操作，并且可能只是体验到资源变得不可用，而不会事先识别任何关于它的通知。
It should be noted that the Sunset HTTP response header field serves a different purpose than HTTP caching [RFC7234]. HTTP caching is concerned with making resource representations (i.e., represented resource state) reusable so that they can be used more efficiently. This is achieved by using header fields that allow clients and intermediaries to better understand when a resource representation can be reused or when resource state (and, thus, the representation) may have changed.
应该注意的是，日落HTTP响应头字段的用途不同于HTTP缓存[RFC7234]。HTTP缓存涉及使资源表示（即表示的资源状态）可重用，以便更有效地使用它们。这是通过使用头字段实现的，头字段允许客户机和中介机构更好地理解何时可以重用资源表示，或者何时资源状态（以及表示）可能已更改。
The Sunset header field is not concerned with resource state at all. It only signals that a resource is expected to become unavailable at a specific point in time. There are no assumptions about if, when, or how often a resource may change state in the meantime.
日落标头字段根本与资源状态无关。它仅表示资源在特定时间点不可用。对于资源在此期间是否、何时或多久改变一次状态，没有任何假设。
For these reasons, the Sunset header field and HTTP caching should be seen as complementary and not as overlapping in scope and functionality.
出于这些原因，日落标头字段和HTTP缓存应该被视为是互补的，而不是范围和功能上的重叠。
This also means that applications acting as intermediaries, such as search engines or archives that make resources discoverable, should treat Sunset information differently from caching information. These applications may use Sunset information for signaling to users that a resource may become unavailable. But they still have to account for the fact that resource state can change in the meantime and that Sunset information is a hint and, thus, future resource availability may differ from the advertised timestamp.
这还意味着，作为中介的应用程序，如使资源可发现的搜索引擎或档案，应该以不同于缓存信息的方式处理日落信息。这些应用程序可以使用日落信息来向用户发出资源可能变得不可用的信号。但他们仍然必须考虑到这样一个事实，即资源状态可以同时更改，日落信息是一个提示，因此，未来的资源可用性可能与公布的时间戳不同。
The Sunset header field applies to the resource that returns it, meaning that it announces the upcoming sunset of that specific resource. However, as discussed in Section 1.4, there may be scenarios where the scope of the announced Sunset information is larger than just the single resource where it appears.
日落标头字段应用于返回它的资源，这意味着它宣布该特定资源即将日落。然而，正如第1.4节所讨论的，可能存在这样的情况，即公布的日落信息的范围大于它出现的单一资源的范围。
Resources are free to define such an increased scope, and usually this scope will be documented by the resource so that consumers of the resource know about the increased scope and can behave accordingly. However, it is important to take into account that such increased scoping is invisible for consumers who are unaware of the increased scoping rules. This means that these consumers will not be aware of the increased scope, and they will not interpret Sunset information different from its standard meaning (i.e., it applies to the resource only).
资源可以自由定义这样一个增加的范围，并且通常这个范围将由资源记录，以便资源的使用者知道增加的范围，并可以相应地进行操作。然而，重要的是要考虑到，对于不知道范围规则增加的消费者来说，这种范围扩大是不可见的。这意味着这些消费者不会意识到范围的增加，他们不会解释与其标准含义不同的日落信息（即，它仅适用于资源）。
Using such an increased scope still may make sense, as Sunset information is only a hint anyway; thus, it is optional information that cannot be depended on, and clients should always be implemented in ways that allow them to function without Sunset information. Increased scope information may help clients to glean additional hints from resources (e.g., concluding that an API is being deprecated because its home/start resource announces a Sunset) and, thus, might allow them to implement behavior that allows them to make educated guesses about resources becoming unavailable.
使用这样一个增加的范围仍然是有意义的，因为日落信息只是一个提示；因此，它是不可依赖的可选信息，客户端的实现方式应始终允许它们在没有日落信息的情况下运行。增加范围信息可能有助于客户从资源中收集额外的提示（例如，认为某个API因其主/开始资源宣布日落而被弃用），因此，可能允许客户实现允许他们对资源变得不可用进行有根据的猜测的行为。
The Sunset HTTP header field indicates the upcoming retirement of a resource or a service. In addition, a resource may want to make information available that provides additional information about how retirement will be handled for resources or services. This information can be broadly described by the following three topics:
日落HTTP头字段表示资源或服务即将退役。此外，资源可能希望提供有关如何处理资源或服务的退休的附加信息。这些信息可大致通过以下三个主题来描述：
Sunset policy: The policy for which resources and in which way sunsets may occur may be published as part of service's description. Sunsets may only/mostly affect a subset of a service's resources, and they may be exposed according to a certain policy (e.g., one week in advance).
日落政策：日落可能发生的资源和方式的政策可以作为服务描述的一部分发布。日落可能只/主要影响服务资源的一部分，并且可能根据特定政策（例如提前一周）暴露。
Upcoming sunset: There may be additional information about an upcoming sunset, which can be published as a resource that can be consumed by those looking for this additional information.
即将到来的日落：可能有关于即将到来的日落的附加信息，这些信息可以作为资源发布，供那些寻找这些附加信息的人使用。
Sunset mitigation: There may be information about possible mitigation/migration strategies, such as possible ways how resource users can switch to alternative resources/services.
日落缓解：可能有关于可能的缓解/迁移策略的信息，例如资源用户如何切换到替代资源/服务的可能方式。
Any information regarding the above issues (and possibly additional ones) can be made available through a URI that then can be linked to using the sunset link relation type. This specification places no constraints on the scope or the type of the linked resource. The scope can be for a resource or for a service. The type is determined by the media type of the linked resource and can be targeted to humans, machines, or both.
有关上述问题（可能还有其他问题）的任何信息都可以通过URI获得，然后可以使用日落链接关系类型链接到该URI。此规范对链接资源的范围或类型没有任何限制。范围可以是资源或服务。类型由链接资源的媒体类型决定，可以针对人、机器或两者。
If the linked resource does provide machine-readable information, consumers should be careful before acting on this information. Such information may, for example, instruct consumers to use a migration rule so that sunset resources can be accessed at new URIs. However, this kind of information amounts to a possibly large-scale identity migration of resources, so it is crucial that the migration information is authentic and accurate.
如果链接的资源确实提供了机器可读的信息，消费者在对这些信息采取行动之前应该小心。例如，此类信息可以指示使用者使用迁移规则，以便可以在新的URI上访问日落资源。然而，这种信息相当于可能大规模的资源身份迁移，因此迁移信息的真实性和准确性至关重要。
The Sunset response header field has been added to the "Permanent Message Header Field Names" registry (see [RFC3864]), taking into account the guidelines given by HTTP/1.1 [RFC7231].
考虑到HTTP/1.1[RFC7231]给出的指南，日落响应标头字段已添加到“永久消息标头字段名称”注册表中（请参见[RFC3864]）。
Header Field Name: Sunset
标题字段名称：日落
Protocol: http
协议：http
Status: informational
状态：信息性
Author/Change controller: IETF
作者/变更控制员：IETF
Reference: RFC 8594
参考：RFC 8594
The sunset link relation type has been added to the permanent "Link Relation Types" registry according to Section 4.2 of [RFC8288]:
根据[RFC8288]第4.2节，日落链接关系类型已添加到永久“链接关系类型”注册表中：
Relation Name: sunset
关系名称：日落
Description: Identifies a resource that provides information about the context's retirement policy.
描述：标识提供有关上下文的退休策略信息的资源。
Reference: RFC 8594
参考：RFC 8594
Generally speaking, information about upcoming sunsets can leak information that otherwise might not be available. For example, a resource representing a registration can leak information about the expiration date when it exposes sunset information. For this reason, any use of sunset information where the sunset represents an expiration or allows the calculation of another date (such as calculating a creation date because it is known that resources expire after one year) should be treated in the same way as if this information would be made available directly in the resource's representation.
一般来说，关于即将到来的日落的信息可能会泄露一些原本可能无法获得的信息。例如，表示注册的资源在公开日落信息时可能会泄漏有关过期日期的信息。因此，如果日落表示过期或允许计算另一个日期（例如，计算创建日期，因为已知资源在一年后过期），则任何日落信息的使用都应以相同的方式处理，就像此信息将直接在资源的表示中可用一样。
The Sunset header field SHOULD be treated as a resource hint, meaning that the resource is indicating (and not guaranteeing with certainty) its potential retirement. The definitive test whether or not the resource in fact is available will be to attempt to interact with it. Applications should never treat an advertised Sunset date as a definitive prediction of what is going to happen at the specified point in time: the Sunset indication may have been inserted by an intermediary or the advertised date may get changed or withdrawn by the resource owner.
日落报头字段应被视为资源提示，这意味着资源正在指示（但不能确定地保证）其潜在退役。确定资源是否可用的测试将是尝试与之交互。应用程序不应将公布的日落日期视为在指定时间点将要发生的事情的最终预测：日落指示可能已由中间人插入，或者公布的日期可能已被资源所有者更改或撤销。
The main purpose of the Sunset header field is to signal intent so that applications using resources may get a warning ahead of time and can react accordingly. What an appropriate reaction is (such as switching to a different resource or service), what it will be based on (such as machine-readable formats that allow the switching to be done automatically), and when it will happen (such as ahead of the advertised date or only when the resource in fact becomes unavailable) is outside the scope of this specification.
日落标头字段的主要用途是发出意图信号，以便使用资源的应用程序可以提前收到警告，并做出相应的反应。适当的反应是什么（例如切换到不同的资源或服务），它将基于什么（例如允许自动切换的机器可读格式），以及何时发生（例如在公布日期之前或仅当资源实际上变得不可用时）不在本规范的范围内。
In cases where a sunset policy is linked by using the sunset link relation type, clients SHOULD be careful about taking any actions based on this information. It SHOULD be verified that the information is authentic and accurate. Furthermore, it SHOULD be
在使用日落链接关系类型链接日落策略的情况下，客户端应小心根据此信息执行任何操作。应验证信息的真实性和准确性。此外，它应该是
tested that this information is only applied to resources that are within the scope of the policy, making sure that sunset policies cannot "hijack" resources by for example providing migration information for them.
经测试，此信息仅适用于策略范围内的资源，以确保日落策略不能“劫持”资源，例如，为其提供迁移信息。
If a resource has been created in an archive that, for management or compliance reasons, stores resources for ten years and permanently deletes them afterwards, the Sunset header field can be used to expose this information. If such a resource has been created on November 11, 2016, then the following header field can be included in responses:
如果在存档中创建了一个资源，出于管理或法规遵从性原因，该资源存储了十年并在此后永久删除，则可以使用日落标头字段公开此信息。如果此类资源已于2016年11月11日创建，则响应中可包含以下标题字段：
Sunset: Wed, 11 Nov 2026 11:11:11 GMT
Sunset: Wed, 11 Nov 2026 11:11:11 GMT
This allows clients that are aware of the Sunset header field to understand that the resource likely will become unavailable at the specified point in time. Clients can decide to ignore this information, adjust their own behavior accordingly, or alert applications or users about this timestamp.
这允许知道日落标头字段的客户端了解资源可能在指定的时间点变得不可用。客户端可以决定忽略此信息，相应地调整自己的行为，或者向应用程序或用户发出有关此时间戳的警报。
Even though the Sunset header field is made available by the resource itself, there is no guarantee that the resource indeed will become unavailable, and if so, how the response will look like for requests made after that timestamp. In case of the archive used as an example here, the resource indeed may be permanently deleted, and requests for the URI after the Sunset timestamp may receive a "410 Gone" HTTP response. (This is assuming that the archive keeps track of the URIs that it had previously assigned; if not, the response may be a more generic "404 Not Found".)
即使Sunset header字段由资源本身提供，也不能保证资源确实会变得不可用，如果是的话，在该时间戳之后发出的请求的响应会是什么样子。在这里用作示例的存档的情况下，资源确实可以被永久删除，并且在日落时间戳之后对URI的请求可以接收“410 Gone”HTTP响应。（这是假设存档跟踪它以前分配的URI；如果没有，则响应可能是更通用的“404未找到”。）
Before the Sunset header field even appears for the first time (it may not appear from the very beginning), it is possible that the resource (or possibly just the "home" resource of the service context) communicates its sunset policy by using the sunset link relation type. If communicated as an HTTP header field, it might look as follows:
在日落标头字段第一次出现之前（它可能不会从一开始就出现），资源（或者可能只是服务上下文的“主”资源）可能通过使用日落链接关系类型来传递其日落策略。如果作为HTTP头字段进行通信，则可能如下所示：
Link: <http://example.net/sunset>;rel="sunset";type="text/html"
Link: <http://example.net/sunset>;rel="sunset";type="text/html"
In this case, the linked resource provides sunset policy information about the service context. It may be documentation aimed at developers, for example, informing them that the lifetime of a certain class of resources is ten years after creation and that Sunset header fields will be served as soon as the sunset date is
在这种情况下，链接资源提供有关服务上下文的日落策略信息。它可能是针对开发人员的文档，例如，通知他们某类资源的生命周期是创建后的十年，日落日期一到，日落标头字段就会被提供
less than some given period of time. It may also inform developers whether the service will respond with 410 or 404 after the sunset time, as discussed above.
少于某个给定的时间段。如上文所述，它还可以通知开发人员服务是否会在日落时间后以410或404响应。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, DOI 10.17487/RFC3864, September 2004, <https://www.rfc-editor.org/info/rfc3864>.
[RFC3864]Klyne，G.，Nottingham，M.和J.Mogul，“消息头字段的注册程序”，BCP 90，RFC 3864，DOI 10.17487/RFC3864，2004年9月<https://www.rfc-editor.org/info/rfc3864>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.
[RFC7231]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：语义和内容”，RFC 7231，DOI 10.17487/RFC72312014年6月<https://www.rfc-editor.org/info/rfc7231>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8288] Nottingham, M., "Web Linking", RFC 8288, DOI 10.17487/RFC8288, October 2017, <https://www.rfc-editor.org/info/rfc8288>.
[RFC8288]诺丁汉，M.，“网络链接”，RFC 8288，DOI 10.17487/RFC8288，2017年10月<https://www.rfc-editor.org/info/rfc8288>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, <https://www.rfc-editor.org/info/rfc7234>.
[RFC7234]Fielding，R.，Ed.，Nottingham，M.，Ed.，和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：缓存”，RFC 7234，DOI 10.17487/RFC72342014年6月<https://www.rfc-editor.org/info/rfc7234>.
Acknowledgements
致谢
Thanks for comments and suggestions provided by Ben Campbell, Alissa Cooper, Benjamin Kaduk, Mirja Kuhlewind, Adam Roach, Phil Sturgeon, and Asbjorn Ulsberg.
感谢Ben Campbell、Alissa Cooper、Benjamin Kaduk、Mirja Kuhlewind、Adam Roach、Phil Sturgeon和Asbjorn Ulsberg提供的意见和建议。
Author's Address
作者地址
Erik Wilde
埃里克·王尔德
Email: erik.wilde@dret.net
URI: http://dret.net/netdret/
Email: erik.wilde@dret.net
URI: http://dret.net/netdret/