W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2016

Re: Proposal: Cookie Priorities

From: Matthew Kerwin <matthew@kerwin.net.au>
Date: Mon, 7 Mar 2016 13:29:18 +1000
Message-ID: <CACweHNDTeO1w1gnVvC3JMcOXnvHkye-PEd_URiKex7Awm7dfKw@mail.gmail.com>
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On 7 March 2016 at 12:28, Amos Jeffries <squid3@treenet.co.nz> wrote:

>
> My take has been from the beginning that we should start pruning away
> pieces of Cookie to prevent bad usages a much as possible.
>
> This particular baindaid proposal looks like it might double as a nice
> way to allow any recipient or relay to proactively prune away the
> low-priority Cookies in traffic when bandwidth gets overloaded. Can it
> be the beginning of an efficient Cookie deletion mechanism?
>
>
‚ÄčMaybe, but I have reservations...

Regarding "Priority=High": Currently cookies are often used on the critical
path, and these existing cookies don't have a "Priority" attribute. We
can't define a new spec that retroactively mandates that implementers have
to add the attribute, so I imagine we would probably want to define it so
that "no Priority" is as high as "High Priority." (Unless we're proposing
to define a new supe..uh..'more important' cookie.) So all the existing
dead wood remains, and the path of least resistance for implementers who
want to comply with the spec is: don't do anything. Thus it's not a
valuable addition.

Regarding "Priority=Low": this allows/encourages people to add even more
cookies, because "they're low priority, so they're less harmful." Telling
people to add a bunch of fluffy cookies because 'they can be pruned if
there are too many' doesn't seem like an improvement to me. Better advice
would be: don't send so much cruft in cookies.

(At the risk of sounding idealistic:) Do we want to make it easier for
middleboxen to cover up the abuses of pathological web applications?

Cheers
-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/
Received on Monday, 7 March 2016 03:29:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 22 March 2016 12:47:11 UTC