Subject: [http-state] draft-ietf-httpstate-cookie-23 needs addition of mandatory Version field

From: xor <[email-masked]>
Date: Sat, 26 Mar 2011 20:54:33 +0100

Hello,

I was informed about the following draft which is designed to replace RFC 2109 
and RFC 2965.
http://tools.ietf.org/html/draft-ietf-httpstate-cookie-23

Firefox 4 seems to apply the draft to cookies which were created to conform 
with RFC 2109 which yields to invalid interpretation of the cookies according 
to the bug tracker entry:
https://bugzilla.mozilla.org/show_bug.cgi?id=610218
Short summary: RFC 2109 allowed the Value in Key=Value pairs to be quoted.
The new draft does not allow quotes in the Path and therefore Firefox 4 
misinterprets the Path="Value" which is generated by RFC 2109 servers as the 
"-characters being part of the value.

After having had a look at draft-ietf-httpstate-cookie-23 it seems like it 
does not require a Version=version key/value pair to be specified in Set-
Cookie.
See section 3.1.: A valid cookie is specified there as:

Set-Cookie: SID=31d4d96e407aad42

Given that the draft does not seem to be designed to be able to correctly 
interpret cookies which are RFC2109-compliant it seems to be absolutely 
necessary that a Version=new-version Key/Value pair must be added as mandatory 
for cookies which are generated under the rules of the new draft.

Otherwise this will cause browsers to misinterpret cookies as shown in the 
above Firefox bug tracker entry.

Greetings,
        xor, Freenet project developer

---

From: xor <[email-masked]>
Date: Sat, 26 Mar 2011 21:29:00 +0100

On Saturday 26 March 2011 21:06:21 you wrote:
> On Sat, 26 Mar 2011, xor wrote:
> > Firefox 4 seems to apply the draft to cookies which were created to
> > conform with RFC 2109 which yields to invalid interpretation of the
> > cookies according to the bug tracker entry:
> As has been discussed many times, here and elsewhere, RFC2109 is hardly
> ever implemented or followed.
>
> This WG has worked to produce a spec of how cookies is actually used today.

Can you prove this with statistics?

And even if true, why does the fact that some servers produce bogus outputs 
justify the INVALID parsing of output which is absolutely well-formed and even 
defines the Version of the format it uses?
 
> > it seems to be absolutely necessary that a Version=new-version Key/Value
> > pair must be added as mandatory for cookies which are generated under the
> > rules of the new draft.
> 
> No. We document how HTTP servers and clients use cookies on the internet
> today, and the fact is that very few use Version. 

No, you don't document that unless you can prove it by numbers as said above.

And even if you can, then you still effectively document how to misinterpret 
cookies which are generated by servers whose developers took the effort to 
actually be standard compliant to RFC2109.
- If a server author took the effort to actually read your previous standard 
and implement it correctly he is punished by your new draft which will cause 
clients to consider his output as invalid.

People who did not take the effort to read and instead just wrote bogus servers 
are rewarded by successful parsing. Great.

> We certainly cannot say
> that it is mandatory, as that would be a lie.

The draft defines what shall be considered as a cookie which follows the draft.
I.e. it DEFINES those cookies. 
The core attribute of a definition is that it *assigns* a meaning to something
How can a definition, which is a value assignment, be a lie? This makes no 
sense at all.

> > Otherwise this will cause browsers to misinterpret cookies as shown in
> > the above Firefox bug tracker entry.
> 
> That's because you wrongly assumed that many browsers or HTTP clients in
> general speak RFC2109. An understandable mistake, but still a mistake.

Let me sum up what you just wrote here: So the draft-23 specification as-is 
causes the misinterpretation of RFC2109 cookies BECAUSE I personally did 
assume something.

How can a document which defines a protocol cause a misinterpretation of a 
different protocol because someone said something on a mailing list?

- The draft 23 specification can only cause misinterpretation of RFC2109 due to 
its very own contents!

---

From: xor <[email-masked]>
Date: Sat, 26 Mar 2011 21:57:21 +0100

As there still seem to be people who do not understand the dimension of the 
problem - on of them being a person who says he wrote the said draft - I would 
like to elaborate what this is all about:

Basic computer science.
The computers which we write software for are language processors upon finite 
character sets.
To be able to correctly interpret a text (= a cookie) the software must know 
which language it is spoken in.
As the character set (plain text / UTF) is shared among different languages 
here (RFC2109, 2965, draft-23), it cannot be used to identify the language and 
therefore there must be a magic string at the beginning of each text (each 
cookie) to allow parsers to identify which language shall be used. 

RFC 2109 specifies "Set-Cookie: " as its language marker , draft-23 specifies 
the same marker. RFC 2109 further requires "Version=1" to be present in the 
cookie to allow future modifications to the language.

Parsers which parse draft-23 are bound to interpret cookies which are written 
in the language of RFC2109 as if they were actually of the draft-23 language 
because the draft-23 language uses the "Set-Cookie" marker as well and 
draft-23 parsers will ignore the existing Version attribute which COULD be 
used to identify RFC2109 cookies.

This is a problem because the RFC2109 language has different semantics than 
draft-23, for example as described in the Firefox bug tracker:
Path="/" in RFC2109 means that the path is /
Path="/" in draft-23 means that the path is "/", which is invalid.

So draft-23 is broken because parsers which implement it will accept input of 
a different language than they were designed for.
As said, basic computer science failure.

Also, at a higher level of evaluation I would consider it as a software 
engineering failure  because the past has shown millions of times over decades 
that any software and in this case language specification will have bugs and 
therefore all file formats should contain a format version to be able to 
compensate bugs in old formats in the future.

---

From: xor <[email-masked]>
Date: Sat, 26 Mar 2011 22:13:23 +0100

On Saturday 26 March 2011 22:00:15 you wrote:
> No I can't,

If you cannot provide numbers your argument about majorities and minorities is 
invalid.

> but we've checked out how the major browsers and a large amount
> of cookie implementations work by testing. Feel free to read up and see for
> yourself.

"major browsers" and "large amount" are completely undefined and subjective 
terms. Where is your documentation of it which I should read up myself?

> > And even if true, why does the fact that some servers produce bogus
> > outputs justify the INVALID parsing of output which is absolutely
> > well-formed and even defines the Version of the format it uses?
> 
> Just because you implemented cookies using RFC2109 doesn't mean that
> everyone else in the world did.

As said above:
If you cannot provide numbers your argument about majorities and minorities is 
invalid.

Further, pretending that your argument was valid:
So you say that INVALID parsing of existing standard compliant documents is 
okay because not everybody else in the world parses them correctly?
So we are free to parse things however we want to? 

Would you be okay with a judge doing this with the constitution of your 
country?

- Really I don't understand why we even have to go to this level of ridiculous 
argumentation.
It has been showing way too often that non-standard-compliant browsers, 
servers, etc. are BAD. Look at the history of Internet Explorer. 

And now a draft for a standard is made which is incompatible to pre-existing 
standards. This is unacceptable.

> Your example here is a perfect reason why the work on this spec has been so
> important.

The specification is important because it breaks backwards-compatibility with 
existing servers which are compliant to existing standards?
 
> > - If a server author took the effort to actually read your previous
> > standard and implement it correctly he is punished by your new draft
> > which will cause clients to consider his output as invalid.
> 
> Such a server author would already suffer from that problem if said server
> for example have users that are using a few of the major browsers, as they
> don't implement RFC2109. Exactly like you experienced with Firefox.

So the bug is in the browsers, not in the server.
Firefox 3.6 *WAS* (partially, there were some glitches in it as well) 
compliant to RFC2109. They completely broke it with Firefox 4.

---

From: Adam Barth <[email-masked]>
Date: Sat, 26 Mar 2011 14:46:21 -0700

I find this thread very confusing.  Who are you replying to?

Adam

On Sat, Mar 26, 2011 at 2:13 PM, xor <[email-masked]> wrote:
> _______________________________________________
> http-state mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-state
>
>

---

From: xor <[email-masked]>
Date: Sat, 26 Mar 2011 23:05:14 +0100

> I find this thread very confusing.  Who are you replying to?

Daniel Stenberg, who replied directly to me with the list on CC.
I don't know why the list is not delivering?

---

From: Mark Pauley <[email-masked]>
Date: Mon, 28 Mar 2011 16:42:55 -0700

No, we don't need a mandatory Version field.

What follows is my own personal manifesto as an engineer that is familiar with the vagaries of HTTP client code.

I'm an author and maintainer of the cookies implementation of a major browser and I think that this standard is just fine.  I've gone and implemented RFC2109 support and I assure you: nobody cares. When this draft is finalized and approved it will obsolete RFC2109, I will delete the RFC2109 handling source code I wrote before, implement this standard and almost certainly never look back.  Nobody uses the Version= attribute, unfortunately it wasn't there in the beginning and well... nobody really uses it.

The double-quotes issue you mention is a red herring. If a value is given to my code in double quotes, I'll have to give it back with double quotes to be sure that I'm not sending invalid characters unquoted.  As the new draft is written, the double quotes are completely superfluous.  You as a web server author can't actually use any characters inside of the double quotes that you would have liked to use because of some broken client implementations, or you would not work with <browser x>.  A standard isn't really a standard unless everybody correctly implements that standard.

Anyhow, like I said: I am the author and maintainer of a cookies implementation and I will gladly forget RFC2109 ever happened because nobody uses it anyhow. How do I know?  I have not ever gotten one bug filed on my implementation.  Not one.  I'm okay at programming, but nobody's that good.  Nobody has filed bugs because nobody expects browsers to be RFC2109 compliant.

I hope every other major browser switches to this RFC as well and we can all just forget about cookie parsing from here on out.  Because seriously... we're all copying each other at this point.  How many bugs does Mozilla have in it's DB that say "Such and such works on <browser x>"?  I know that nearly all of the cookies bugs I've fixed are of this form.

So forget about "Computer Science" for a minute and realize that most programmers just connect pipes from one component to another one.  I don't feel like plumbing houses that nobody uses. In fact, adding more functionality in this case is downright dangerous. Making the parsers more complex just opens clients up to attack. I think that the quoted value thing and the Version= thing aren't useful, nobody relies on them right now and we don't need to talk about them. Sorry.

The mechanism outlined in the draft won't break cookies that currently work on all browsers... i.e. the cookies that a web app developer could actually use and expect the app to work for all browsers.  What the draft is attempting to do is define the set space of those cookies: the ones that will work on all (or effectively all) browsers so that: 1) new client authors can support all cookies in this set space and 2) new server authors don't rely on features outside of this set space.  I sincerely hope this comes to be, and I will personally do my part in this by dropping support for any cookies outside of the aforementioned set.

Manifesto over, in summary:

This draft cannot by nature add anything to the Lowest Common Denominator of cookies and be successful. This draft can only trim the loose ends that cause problems and clear up any confusions with cookies in the wild as they are right now with suggestions.

---

From: Daniel Stenberg <[email-masked]>
Date: Sat, 26 Mar 2011 22:00:15 +0100 (CET)

> Can you prove this with statistics?

No I can't, but we've checked out how the major browsers and a large amount 
of cookie implementations work by testing. Feel free to read up and see for 
yourself.

> justify the INVALID parsing of output which is absolutely well-formed and 
> even defines the Version of the format it uses?

Just because you implemented cookies using RFC2109 doesn't mean that everyone 
else in the world did.

> clients to consider his output as invalid.

Such a server author would already suffer from that problem if said server for 
example have users that are using a few of the major browsers, as they don't 
implement RFC2109. Exactly like you experienced with Firefox.

-- 

  / daniel.haxx.se

---

From: Daniel Stenberg <[email-masked]>
Date: Sat, 26 Mar 2011 21:06:21 +0100 (CET)

> https://bugzilla.mozilla.org/show_bug.cgi?id=610218

As has been discussed many times, here and elsewhere, RFC2109 is hardly ever 
implemented or followed.

No. We document how HTTP servers and clients use cookies on the internet 
today, and the fact is that very few use Version. We certainly cannot say that 
it is mandatory, as that would be a lie.

-- 

  / daniel.haxx.se