[http-state] Summary of discussion of Ticket 5 (Cookie ordering)

[Adam Barth <[e-mail]>]

For reasons I don't entirely understand, the order cookies are
presented in the Cookie header is somewhat controversial.  The
discussion seems to have quieted down to some extent, so I thought now
might be a good time to summarize what's been said thus far.

== General Principles ==

Daniel Stenberg suggests that we should specify only what needs to be
specified and leave the rest to the implementors.  In particular, we
should specify and document what needs to be done in order to work
with the vast majority of sites, where he takes the "vast majority of
sites" to be all (except three or more) of the top 500 sites.  He
appears unwilling to specify a behavior if it's a very rare assumption
that we can declare a server bug.  However, if sufficiently many
servers assume that clients behave in a certain way, then we ought to
specify that behavior.

In the absence of evidence about what servers require, Adam Barth
argues that we should specify the most specific behavior that is
deployed by the most commonly used implementations.

== Technical Details ==

Daniel Stenberg	agrees that the "most specific" version of two cookies
with the same name should be sent first.  He agrees that the
"sort-them-all" approach is the easiest to implement.  Based on this
experience implementing libcurl, he doesn't think the creation-time of
a cookie is relevant.

Dan Winship supports specify the ordering, but mostly on general
principles rather than specific implementation experience.

Maciej Stachowiak would like a breakdown of which user agents employ
which sorting algorithms.  He agues that not specifying the sort order
isn't viable.

Anne van Kesteren supports specify the ordering.

Yngve Pettersen suggests that we continue to specify the ordering, at
least for path.  Later, he recommends sorting on domain and path,
ignoring creation-time (because creation-time is less predictable).
He notes that Opera sorts based on domain first, path second, and
creation-time third.

Dan Witte confirms that Firefox sorts by path length and then by
creation-time.  When Firefox dropped the creation-time sorting in
2004, at least one site broke, prompting Firefox to reinstate
creation-time sorting.  He would be willing to change Firefox to match
IE because he dislikes creation-time sorting (but implemented it
because of compatibility issues).

Paul E. Jones is skeptical that servers will be able to rely on user
agent sorting behavior and would prefer that user agents never send
two cookies with the same name.

Achim Hoffmann notes that the cookie sequence is really important.  He
is aware of some serious attacks (miss)using the order of cookies.  He
recommends a specific sorting based on seven factors.

== Specification Changes ==

I've added this requirement to the server conformance section:

[[
          <t>Although cookies are serialized linearly in the Cookie header,
          servers SHOULD NOT rely upon the serialization order. In particular,
          if the Cookie header contains two cookies with the same name,
          servers SHOULD NOT rely upon the order in which these cookies appear
          in the header.</t>
]]

== Action Items ==

1) Adam Barth will generate the compatibility matrix requested by
Maciej Stachowiak.

Adam