How can we improve the Microsoft Edge developer experience?

Support for Cookie max-age

All other browsers allow cookies to be specified with a max-age property that replaces the expires timestamp. This allows servers to have cookies that work regardless of the clock skew on an end users computer.

94 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Anthony Ryan shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    2 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      Submitting...
      • Simon Willison commented  ·   ·  Flag as inappropriate

        I have a couple of specific use-cases for this.

        1. Leader/follower database replication and follower lag

        The first one relates to operating large-scale websites using database replication. A common pattern here is to have a leader database and a number of follower databases (also sometimes called master/*****). Any writes to the application get sent to the leader database, but reads can be distributed amongst the followers. This makes it easy to scale read traffic by adding more follower capacity.

        The catch here is when a user updates some data (e.g. submits a form to update their user profile) and then subsequently views a page where they expect to see the data they just entered. If there is any follower lag, it can take a few seconds for their updates to trickle down from the leader to the followers. The user might see the old data, at which point they will assume that their update was lost and will become confused/angry/frustrated.

        One way of solving this issue involves the use of cookies. Every time the user submits a POST request that updates data, we set a cookie that expires after a few seconds "pinning" that user's subsequent requests to the leader database. Any read requests while that cookie is still valid will hence be served directly from the leader, eliminating the risk of follower lag returning stale data.

        With the max-age cookie parameter implementing this solution is easy: max-age=3. The expires parameter is much less useful, since clock skew between the server and the user's browser may mean the cookie does not last for the desired amount of time.

        2. Setting cookies from "dumb" proxies

        There are a number of technologies that can be placed in front of a web application server as an HTTP proxy, to solve all sorts of issues - load balancing, high availability, even full-response-caching. In some situations these technologies may need to set cookies by appending a Set-Cookie header to the response that is being proxied through. Setting a max-age parameter is significantly easier than setting an expires header, because the max-age header doesn't require any date arithmetic to be performed.

        I ran into this exact problem recently using Varnish, a high-performance caching proxy. I needed to have Varnish set a cookie that lasted for a year. VCL (the Varnish Configuration Language) provides a function for appending an additional HTTP header, but it does not have any mechanisms for performing date arithmetic. It's easy for me to set a "Set-Cookie: guest=1234567; Max-Age=31449600" header - but if I want to add an "Expires=..." parameter I need to be able to calculate today's date + 365 days - a capability that VCL does not provide.

        In both of the above cases support for the Max-Age cookie parameter would make implementing solutions enormously easier.

      Feedback and Knowledge Base