On Wed, Dec 23, 2015 at 6:48 AM, Willy Tarreau <w@1wt.eu> wrote: > Based on Mike's and your proposal, I'm wondering if a solution would not > be to use special name cookies in addition to the regular ones to pass > back *all* attributes and even to help define new attributes. We could > have something like this : > > Set-Cookie: __SID=12345; secure; path=/; domain=example.com; > > Cookie: __SID=12345; __attr_secure__SID=1; __attr_path__SID=/; > __attr_domain__SID=example.com; __attr_origin__SID=https://example.com > > etc... The idea being that "__attr_<attribute_name>" being prefixed in > front of the cookie name in requests so that the client can pass the > attributes it learned. This way, a cookie learned from the wrong > location (eg: injected from HTTP, JS or anything) could be detected > and replaced by the server. And it still provides unicity on the cookie > names and value in the request. > Elliott (CC'd) proposed something similar in https://groups.google.com/a/chromium.org/d/msg/blink-dev/IU5t6eLuS2Y/H6HJ-j6TBwAJ, with a special cookie being sent along with the request that contained all the attributes (and presumably scopes) of the rest of the cookies. We didn't spend a whole lot of time with that proposal, as our intuition was that such a scheme would require some amount of work for each developer to parse and enforce on their own, while prefixes were a pragmatic solution that the user agent could enforce for everyone. It might well be worth picking up (in addition to prefixes?) if there's interest in this group. -mike
Received on Thursday, 7 January 2016 15:42:36 UTC