Re: Proposal: Cookie Priorities

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/