]> Shopify

yoav@yoav.ws

next generation unicorn sparkling distributed ledger This document specifies a Delete-Cookie HTTP header that instructs clients to delete cookies of certain names, without requiring the server to know more details about them. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction Long-operating web sites can often find themselves dealing with "cookie cruft" - cookies that no longer have backend logic that corresponds with them. Such cookies may have been set at some point in the past with far-reaching expiration dates, and are now causing useless cookie bloat at best, or using up quotas at the expense of relevant cookies at worst Deleting cookies is possible today by setting their expiry date to one in the past, but that requires one to know the "domain" and "path" parameters with which the cookies were set. That is not something that can be passively observed on the server side by default. This draft proposes a new Delete-Cookie header which will enable servers to instruct clients to delete cookies of a certain name from their cookie stores.

Notational Conventions 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 when, and only when, they appear in all capitals, as shown here. This document uses the following terminology from Section 3 of to specify syntax and parsing: Lists, strings.

Delete-Cookie The Delete-Cookie response header is a Structured Field List of strings. Each string represents a cookie name to be deleted. A user agent that receives a Delete-Cookie response header MUST process it before any Set-Cookie headers received as part of the same response. Note: The relevant processing needs to happen before step 15 of the network fetch algorithm. When receiving a Delete-Cookie response header, the user agent MUST:

1. If the response was not delivered over a "secure" connection (as defined by the user agent) , return.
2. Let host be the canonicalized response URL's host name.
3. Let parsed be the result of parsing the header's value as a List, as per , Section 4.2.1.
4. If parsing fails, return.
5. For each name in parsed:
   1. If name is not a String , continue. Note: The above ignores any parameters in the header's value List.
   2. Let matching cookies be the set of cookies from the user agent's cookie store that meet all the following requirements:
      1. The cookie's name is name.
      Note: This ensures that cookies with an empty name can be deleted using the empty string. It also ensures that multiple cookies with the same name (and different paths, domains or other attributes) will all be deleted.
      1. Either of the following is true:
         1. The cookie's host-only-flag is true, and the cookie's domain is identical to host.
         Note: The ensures that a server can't delete host-only cookies that aren't destined to its host.
         1. The cookie's host-only-flag is false, and the cookie's domain domain-matches host, as per , Section 5.1.3.
   3. For each cookie in matching cookies:
      1. Remove cookie from the user agent's cookie store.

Example MegaCorp servers receive a request from a client with the following header: The server operators know that cookies named "foo" and "fizz" are no longer meaningful for their service, and are unaware when and how those cookies were set. In order to clear that user's cookie store, they send the following header: That clears the client's cookie store of "foo" and "fizz" and ensures that these cookies won't be sent again.

Security Considerations The Delete-Cookie header enables servers to delete cookies from user agents on their own registrable domains. These servers could have already deleted these same cookies by setting cookies with identical name, path and domain with an expiration date of 0. As such the header does not provide servers any new capabilities, beyond the convenience of not having to know the path and domain of a cookie in order to delete it.

IANA Considerations

Header Field Registration IANA is asked to update the "Hypertext Transfer Protocol (HTTP) Field Name Registry" registry maintained at <> according to the table below:

Field Name	Status	Reference
Delete-Cookie	permanent	of this document

Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.

Acknowledgments Thanks to Anne van Kesteren and Pat Meenan for their feedback on early versions of this proposal.