When an HTTP 'Set-Cookie' header carries both Max-Age and Expires, which one wins, and how do you correctly delete a cookie you set earlier?

## Two ways to express a lifetime\n\n```\nSet-Cookie: a=1; Max-Age=86400\nSet-Cookie: b=2; Expires=Sat, 13 Sep 2026 10:00:00 GMT\n```\n\n`Max-Age` is **relative**: an integer number of seconds from the moment the response is received. `Expires` is **absolute**: an `HTTP-date`, always in GMT, in the `Day, DD Mon YYYY HH:MM:SS GMT` form. Note the comma inside that date — it is the reason multiple `Set-Cookie` headers can never be comma-folded into one line.\n\n## Precedence\n\nIf both attributes appear on the same cookie, **`Max-Age` wins**. RFC 6265 states that a user agent supporting `Max-Age` must ignore `Expires`. `Expires` came from the original Netscape cookie draft; `Max-Age` arrived with RFC 2109 and had patchy support in browsers of that era, which is why the belt-and-braces habit of sending both persists in old frameworks. Every current browser honours `Max-Age`, so sending both only creates a chance for the two to drift apart in your code and confuse the next reader. Pick `Max-Age`.\n\n## Why Max-Age is the better attribute\n\nA client with a badly wrong clock will mis-evaluate `Expires`: set an hour ahead, it may expire the cookie instantly; set a year behind, it may keep it far too long. `Max-Age` is converted to an absolute instant *at receipt* using the same clock, so absolute skew cancels out and only drift during the cookie's life matters. It also avoids date-formatting bugs — a malformed `Expires` value is ignored, silently turning your persistent cookie into a session cookie.\n\n## Deleting a cookie\n\nThere is no "delete cookie" mechanism in HTTP. You expire it:\n\n```\nSet-Cookie: sid=; Path=/; Max-Age=0\nSet-Cookie: sid=; Path=/; Expires=Thu, 01 Jan 1970 00:00:00 GMT\n```\n\n`Max-Age=0` (and, per the grammar, any non-positive value) means "expire immediately". The value you send is irrelevant — an empty string is conventional.\n\n### Matching the scope is the whole game\n\nA cookie's identity is the triple **(name, Domain, Path)**. The deletion `Set-Cookie` must reproduce the same `Domain` and `Path` the cookie was created with, or the browser treats it as a different cookie: it creates that different cookie, immediately expires it, and your original survives untouched and keeps being sent. Symptoms are exactly the classic bug report "logout doesn't log me out", or "I get logged out on /app but not on /".\n\nCommon mismatches:\n\n- Cookie set with `Path=/app`, deleted with the default path. The default path is derived from the request URI's directory, so the *same* delete code produces different paths on different endpoints.\n- Cookie set with `Domain=.example.com` (host and all subdomains), deleted without `Domain` (host-only). Those are two distinct cookies and both can exist simultaneously with the same name.\n- Cookie set on `Secure`, deleted over plain HTTP by a service that terminates TLS oddly. `Secure` is not part of identity, but a browser will refuse a non-secure overwrite of a `Secure` cookie from an insecure origin.\n\nThe defence is to centralise cookie writing in one place — one function that owns name, `Domain`, `Path`, `Secure`, `HttpOnly`, `SameSite` — and have both the set and the clear paths call it, so the attributes cannot drift. If you already have duplicate same-named cookies in the wild, you must emit a delete for **each** scope combination; you cannot see the attributes of incoming cookies, because the `Cookie` request header carries only names and values.\n\n## Expiry is client-side and cooperative\n\nExpiring a cookie only stops a cooperating browser from sending it. It does not invalidate the credential. Anyone who has copied the value can keep replaying it, and a client with a manipulated clock may keep the cookie longer than you asked. Logout must therefore invalidate the server-side session or token as well as clearing the cookie; treating `Max-Age=0` as a security action is a real vulnerability, not a style nit.