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

From: Adam Barth <[email-masked]>
Date: Tue, 18 Aug 2009 00:27:52 -0700

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<[email-masked]> 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
>

---

From: Daniel Stenberg <[email-masked]>
Date: Tue, 18 Aug 2009 09:40:57 +0200 (CEST)

On Tue, 18 Aug 2009, Adam Barth wrote:

> 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.

Yes, I disagree with this sentiment.

Internet Explorer, Firefox, Safari, Chrome, and Opera are all web browsers. 
Those five pretty much represent 99.99% of the user market. (exact numbers 
don't matter)

HTTP and cookies are however not reserved for web browsers. Lots and lots of 
applications are written to automate things, to run backends or whatever and 
they too use HTTP and cookies. They typically use _other_ HTTP 
implementations.

So even if you with the 5 browsers have almost 100% of the browser usage, they 
do not represent anywhere near 100% of the HTTP+cookie usage going on in the 
world.

> 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.

But we're documenting _existing practices_. And I've shown you clearly how 
many existing practises don't sort. How can you then say a fair description of 
current clients implies a MUST sort?

I too agree with you that if I were to implement a cookie engine now, it would 
most probably sort the outgoing cookies. And I wouldn't be surprised if 
libsoup and curl (and others) sort the outgoing cookies in a (near) future. 
But that doesn't change my stand-point that an awful lot of current clients 
don't sort, and I don't think it is our job to specify them as non-compliant 
in this spec.

I think that is a small move into the next phase: how to start fix the current 
situation into a better one.

-- 

  / daniel.haxx.se

---

From: "Anne van Kesteren" <[email-masked]>
Date: Tue, 18 Aug 2009 09:50:32 +0200

On Tue, 18 Aug 2009 09:40:57 +0200, Daniel Stenberg <[email-masked]> wrote:
> I think that is a small move into the next phase: how to start fix the  
> current situation into a better one.

FWIW in my opinion that step should be part of this specification. I work  
on XMLHttpRequest and initially the idea was to just describe existing  
implementations, but given all the little differences they have that was  
just not worth the effort. To be valuable to implementors a draft should  
prescribe the behavior for all cases in my opinion even if that renders  
some existing implementations non-conforming.

More concretely, if Opera disagrees with other implementations in some  
detail I would very much prefer for this specification to indicate that  
Opera is non-compliant and that we would be required to change something  
in order to conform than that the behavior would be left undefined. And  
watering such things down with a "SHOULD" would wrong in my opinion since  
the intent is that every client does in fact implement that in the end.

-- 
Anne van Kesteren
http://annevankesteren.nl/

---

From: Daniel Stenberg <[email-masked]>
Date: Tue, 18 Aug 2009 09:59:25 +0200 (CEST)

On Tue, 18 Aug 2009, Anne van Kesteren wrote:

> Opera is non-compliant and that we would be required to change something in 
> order to conform than that the behavior would be left undefined. And 

Point taken.

I think that makes sense to a very large extent, and I could very well agree 
to work with that slightly modified focus. With such a mindset I agree that 
the sorting could very well be phrased as a MUST.

-- 

  / daniel.haxx.se

---

From: Julian Reschke <[email-masked]>
Date: Tue, 18 Aug 2009 10:03:20 +0200

Daniel Stenberg wrote:
> ...
> But we're documenting _existing practices_. And I've shown you clearly 
> how many existing practises don't sort. How can you then say a fair 
> description of current clients implies a MUST sort?
> 
> I too agree with you that if I were to implement a cookie engine now, it 
> would most probably sort the outgoing cookies. And I wouldn't be 
> surprised if libsoup and curl (and others) sort the outgoing cookies in 
> a (near) future. But that doesn't change my stand-point that an awful 
> lot of current clients don't sort, and I don't think it is our job to 
> specify them as non-compliant in this spec.
> 
> ...

+1

If the charter says "document existing practice" then do just that.

If many of today's client implementations do not sort, then it 
apparently is *not* required to be interoperable with the vast majority 
of servers.

On the other hand it is ok to point out that there are broken servers 
out there expecting sorted cookies, but making those clients that do not 
sort non-compliant is *not* "documenting existing practice" anymore.

BR, Julian

---

From: "Anne van Kesteren" <[email-masked]>
Date: Tue, 18 Aug 2009 10:28:19 +0200

> If the charter says "document existing practice" then do just that.

Is the charter final already? I would like to propose that we change it then so that we can actually make a useful specification within the compatibility constraints we have.

---

From: Dan Winship <[email-masked]>
Date: Tue, 18 Aug 2009 08:34:10 -0400

> If the charter says "document existing practice" then do just that.

Well, we don't have a charter yet, but the most recent proposal does
talk about providing recommendations for how to be interoperable, as an
outgrowth of the documenting existing practice.

> apparently is *not* required to be interoperable with the vast majority

Right, there's no debate on that point. The number of servers that care
about cookie sorting is microscopic. But one of them is your bank. (For
suitable values of "your" and "bank".)

> sort non-compliant is *not* "documenting existing practice" anymore.

As I see it, we are not "making those clients non-compliant"; they have
always been non-compliant. Of course, that all depends on what spec
we're talking about compliance with. Curl is compliant with the
imaginary "How To Interoperate With 99.9% Of Cookies In The World" spec,
but I don't think it's worth our time to bother writing that spec; lots
of people (including Daniel and I) have already figured out what it says
without too much difficulty. What I want to see is the "How To
Interoperate With >99.999% Of Cookies In The World" spec. And right now,
the major browsers are compliant with that spec, and curl and libsoup
and other smaller implementations aren't.

-- Dan

---

From: Julian Reschke <[email-masked]>
Date: Tue, 18 Aug 2009 14:42:22 +0200

> outgrowth of the documenting existing practice.

Understood. But recommendations would be just that, not normative 
requirements.

BR, Julian

---

From: "Anne van Kesteren" <[email-masked]>
Date: Tue, 18 Aug 2009 14:49:38 +0200

> Understood. But recommendations would be just that, not normative  

RECOMMENDED is actually normative, though I'd prefer if we just use MUST for most of these things since they are requirements if you want to be interoperable.

---

From: Adam Barth <[email-masked]>
Date: Tue, 18 Aug 2009 08:13:59 -0700

> the sorting could very well be phrased as a MUST.

A rule of thumb that seemed to work well when the ECMAScript working
group was working on ES5 was a "3 out of 4" browser rule, which meant
that they felt that interoperability between 3 out of 4 major browsers
was sufficient to consider including a feature as "existing practice."
 I'm not sure whether that particular rule is appropriate for us.  It
might be better to work through a few cases before settling on such a
rule.

Adam

---

From: Bil Corry <[email-masked]>
Date: Tue, 18 Aug 2009 10:27:54 -0500

Anne van Kesteren wrote on 8/18/2009 3:28 AM: 
> Is the charter final already? I would like to propose that we change
> it then so that we can actually make a useful specification within
> the compatibility constraints we have.

The charter isn't final and I don't believe it will be until we form an official WG.

Below is the most current wording regarding what we are producing; suggestions welcomed:

---8<---
The working group will create a new RFC that obsoletes RFC 2965 and
specifies Cookies as they are actually used in existing
implementations and deployments.  Where differences exist among the
most common implementations, the working group will document the
variations and provide a recommended choice for updates and new 
implementations.  This will also facilitate interoperability among
existing implementations if they so choose.
--->8---

- Bil

---

From: "Anne van Kesteren" <[email-masked]>
Date: Tue, 18 Aug 2009 22:37:57 +0200

> The charter isn't final and I don't believe it will be until we form an  

Thanks for the clarification!

> existing implementations if they so choose.

Does documenting the differences between existing implementations have to  
be done formally (i.e. publishing some kind of RFC) or is mailing list  
discussion and linked research sufficient? Since we want implementations  
to converge spending too much time on documenting "now" does not really  
seem worth it to me. (Though if we have a volunteer I suppose all is good.)

Maybe we could make it a little stronger than just providing a recommended  
choice. What I would like for the Cookie specification is to define  
exactly how to implement them to interoperate with as many existing  
clients and servers as possible. I would also like the cookie  
specification to not leave things undefined when not all clients agree,  
but rather define what we think the clients with which implementation we  
do not agree with should do instead. Perhaps something like:

    Where differences exist among the most common implementations,
    the working group will document the variations and define in
    the specification what implementations are to converge on
    going forward. What implementations are to converge on will be
    based on what is expected to give the most compatibility with
    deployed clients and servers.

I think that removing the ability to define new functionality on top of  
Cookie/Set-Cookie from the charter was the wrong move. It's nice to have a  
little flexibility if e.g. all implementors agree a particular new feature  
makes sense. Having to wait a long time for a new WG and a new RFC would  
be a pity, in my opinion.

And last, but not least, I think it would be good to add a requirement to  
the charter for a test suite and a minimum of two implementations that  
pass it. (Preferably also require two of those implementations to be Web  
browsers given that the compatibility risk is the highest there.) If we  
get that done it is even more clear that this is finally a good cookie  
specification.

---

From: Ian Hickson <[email-masked]>
Date: Wed, 19 Aug 2009 06:02:45 +0000 (UTC)

On Tue, 18 Aug 2009, Daniel Stenberg wrote:
> 
> Internet Explorer, Firefox, Safari, Chrome, and Opera are all web 
> browsers. Those five pretty much represent 99.99% of the user market. 
> (exact numbers don't matter)
> 
> HTTP and cookies are however not reserved for web browsers. Lots and 
> lots of applications are written to automate things, to run backends or 
> whatever and they too use HTTP and cookies. They typically use _other_ 
> HTTP implementations.

FWIW, when I write tools that use cookies, I'd like them to do the same as 
the Web browsers.

In general, specs should be specific about what the output should be. We 
shouldn't leave things undefined or up to the implementation if it affects 
other implementations (such as servers), because otherwise we will find 
authors end up relying on the market leader's behaviour. So we have to 
define the sort order whatever we do. It makes sense to pick the sort 
order used by the browsers, IMHO.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

---

From: Ian Hickson <[email-masked]>
Date: Wed, 19 Aug 2009 06:20:23 +0000 (UTC)

On Wed, 19 Aug 2009, Daniel Stenberg wrote:
> On Wed, 19 Aug 2009, Ian Hickson wrote:
> > 
> > In general, specs should be specific about what the output should be. 
> > We shouldn't leave things undefined or up to the implementation if it 
> > affects other implementations (such as servers), because otherwise we 
> > will find authors end up relying on the market leader's behaviour. So 
> > we have to define the sort order whatever we do. It makes sense to 
> > pick the sort order used by the browsers, IMHO.
> 
> But again you're not focusing on how things ACTUALLY are already right 
> now. You're talking about how we should document (future) things to be.
> 
> If we're documenting how cookies are used in the wild today, we cannot 
> claim that 99.9% are sorted in path lenght order. That's a fact.
> 
> If we're documenting how cookies should work tomorrow with improved 
> interoperability and a minimum of changes, then sorting cookies by path 
> length seems like a good bet since a large amount of clients clearly 
> already do it.

We're documenting (or should be documenting, IMHO) what all 
implementations are going to converge on. That means describing what they 
do when they do the same thing, and considering differences to be bugs for 
which we are to find solutions that are acceptable to implementors.

---

From: Daniel Stenberg <[email-masked]>
Date: Wed, 19 Aug 2009 08:15:56 +0200 (CEST)

On Wed, 19 Aug 2009, Ian Hickson wrote:

> define the sort order whatever we do. It makes sense to pick the sort order 
> used by the browsers, IMHO.

But again you're not focusing on how things ACTUALLY are already right now. 
You're talking about how we should document (future) things to be.

If we're documenting how cookies are used in the wild today, we cannot claim 
that 99.9% are sorted in path lenght order. That's a fact.

If we're documenting how cookies should work tomorrow with improved 
interoperability and a minimum of changes, then sorting cookies by path length 
seems like a good bet since a large amount of clients clearly already do it.

-- 

  / daniel.haxx.se

---

From: Dan Winship <[email-masked]>
Date: Wed, 19 Aug 2009 10:23:13 -0400

> claim that 99.9% are sorted in path lenght order. That's a fact.

We can't say that 99.9% of cookie implementations sort by path length,
but we can probably say that 99.9% of Cookie headers that go across the
internet are sorted by path length (since the major browsers make up a
disproportionately large percentage of web traffic).

But anyway, I'm thinking we need to reorganize the spec to something
like this:

    - Normative grammar (MUST)
        - Set-Cookie
        - Cookie

    - Server recommendations (SHOULD)
        - more-conservative Set-Cookie generation grammar
        - more-liberal Cookie parsing grammar

    - Client recommendations (SHOULD)
        - more-liberal Set-Cookie parsing grammar
        - more-conservative Cookie generation grammar

So, eg, the normative Set-Cookie grammar would specify a limited range
of Expires syntaxes that we consider reasonable for servers to send
(possibly something like the grammar I sent before, minus mystery-date),
and servers would be conforming if they used one of those syntaxes, and
clients would be conforming if they could parse all of those syntaxes.
But then the server recommendations section would say that servers
SHOULD only send rfc1123-date (or netscape-spec-date?), and the client
recommendations section would say that clients SHOULD accept
asctime-date and other date formats.

Likewise, the normative Cookie grammar would not specify much about
sorting (except possibly in the case where there are two cookies with
the same name but different path/domain?), and so clients that did not
sort cookies, and servers that did not care about sorting, would be
conforming. But the server grammar would say that sites SHOULD NOT use
cookies with the same name in different paths/domains, and the client
grammar would say that clients SHOULD sort cookies by path length.

(Because it definitely seems true from the RFC 2119 definition of
"SHOULD" ("the full implications must be understood and carefully
weighed before choosing a different course") that "clients SHOULD sort
cookies by path length". The "full implications" here being that a tiny
fraction of sites require sorting. But if after "careful weighing" you
decide it's not worth it to make your code more complicated just to
support that tiny fraction of sites, then it's acceptable to ignore the
recommendation.)

-- Dan

---

From: Daniel Stenberg <[email-masked]>
Date: Wed, 19 Aug 2009 16:37:59 +0200 (CEST)

On Wed, 19 Aug 2009, Dan Winship wrote:

> But then the server recommendations section would say that servers SHOULD 
> only send rfc1123-date (or netscape-spec-date?), and the client 
> recommendations section would say that clients SHOULD accept asctime-date 
> and other date formats.

+1. Possibly the server SHOULD send "one of these formats".

> But the server grammar would say that sites SHOULD NOT use cookies with the 
> same name in different paths/domains, and the client grammar would say that 
> clients SHOULD sort cookies by path length.

+1

-- 

  / daniel.haxx.se

---

From: Adam Barth <[email-masked]>
Date: Wed, 19 Aug 2009 09:08:27 -0700

>        - more-conservative Cookie generation grammar

This organization is certainly esthetically appealing, but I have a
few reservations:

1) On the client side, once you decide that you're going to accept a
more liberal Set-Cookie parsing grammar, you actually end up with a
more liberal Cookie grammar too.  The reason is you're forced to
accept crazy characters in cookie names and values that you need to
send back to the server.

2) It's unclear to me what the difference between section 1 and 2 will
be.  You mention date, which is a good example, but there is there
anything else one which these two will differ?  Did you have something
in mind for the more liberal Cookie parsing grammar?  In general, if
you stick to a sane Set-Cookie header, the existing user agents send
back virtually identical Cookie headers.

3) I need to study the MUST / SHOULD distinction is more detail.  It's
unclear to me what benefits are for using one or the other.

In any case, I'm willing to give this organization a try.  If come up
with something better later, we can change again.

Adam

---

From: Dan Winship <[email-masked]>
Date: Wed, 19 Aug 2009 13:54:43 -0400

> accept crazy characters in cookie names and values that you need to

Yeah... hm... so the conformance criteria for clients would have to say
that they only have to obey the normative Cookie grammar when they are
responding to servers that obey the normative Set-Cookie grammar. And
then the client recommendation section should clarify that the
NAME=VALUE in the Cookie header should be identical to what it was in
the Set-Cookie header, even if that violates the Cookie grammar.

> back virtually identical Cookie headers.

I didn't really have any specifics in mind yet other than the ones I
gave. It's possible that we don't need a more-liberal
Cookie-header-parsing grammar.

-- Dan