[http-state] Goals for the UA conformance section (was Re: Updated draft)

[Adam Barth <[e-mail]>]

Daniel, I feel like we're having a some trouble communicating here.
Maybe we have different goals for the user agent conformance section.
Here is my goal:

* If I were to implement a new user agent as prescribed by the user
agent conformance section, that user agent would interoperate well
with existing servers.

Ideally, we would know precisely what compatibility trade-offs we're
making with each decision by knowing how many servers would break if
we made a different decision.  In practice, that's difficult to
measure, so we look at popular user agents to estimate how servers
behave.

In this case, the vast majority of user agents by usage / popularity /
market share (to wit, Internet Explorer, Firefox, Safari, Chrome, and
Opera) all behave the same way: they sort cookies in descending order
of path length.  If I were to implement a new user agent today, I
would certainly match these implementations and sort the header in the
same way.  Therefore, it seems clear that's what the user agent
conformance section should say.

Do you have a different goal for the user agent conformance section?

Adam


On Tue, Aug 18, 2009 at 12:13 AM, Daniel Stenberg<[e-mail]> wrote:
> On Mon, 17 Aug 2009, Dan Winship wrote:
>
>>> I've browsed the Cookie: code for curl, wget, libsoup, pavuk, lftp and
>>> aria2. If I didn't miss anything, none of these cookie implementations
>>> sort the cookies as the browsers.
>>
>> You missed this in soup-cookie-jar.c:
>>
>>        /* FIXME: sort? */
>
> Actually I didn't. It instead convinced me that libsoup doesn't sort which
> was what I was curious about (and you hadn't mentioned). So I could in no
> time whip up six (6!) HTTP clients that support cookies that don't sort them
> in the Cookie: header. I think taken together they do represent a fair
> amount of current usage.
>
> FIXMEs or TODOs can be fixed in future releases for most software, that
> doesn't really change what is in use today, right now.
>
>> Be liberal in what you accept (clients MUST accept all date formats,
>> servers MUST accept cookies in any order) and conservative in what you send
>> (clients MUST send cookies in the recommended order, servers MUST send dates
>> in the recommended format).
>
> I think that servers MUST accept them in any order, but clients only SHOULD
> send them sorted like that (path len first then creation date).
>
> Uhm, come to think of it on the matter of creation dates: the older
> Firefox/Mozilla/Netscape cookie file format doesn't save the creation dates
> of cookies, only expiration dates. So surely they won't be able to send
> cookies in the correct order after a restart?
>
> --
>
>  / daniel.haxx.se
>