Subject: [http-state] IETF process clarifications wrt drafts, specs, etc (was: git repository for spec)

From: =JeffH <[email-masked]>
Date: Fri, 07 Aug 2009 16:04:23 -0700

Adam wrote:
 > To get the ball rolling on creating a specification, I've created a
 > git repository to help us collaborate. ...
 > If you have changes you would like to make in the draft,
 > please send patch files to this email list.  We can discuss them and
 > then land them in the repository as appropriate.

So at this point, in the IETF context, we don't (yet) have a WG, and even if we 
did, the WG participants would have to reach rough consensus (per RFC2418) as 
to whether to accept any particular document as a working group item.

Thus the spec that Adam is working on (what's its filename? "cookie.xml" ?) is 
effectively at this time an "individual item". As we move to hold a BoF and 
create a WG, if participants here like what they see in that spec as it 
evolves, then there's a reasonable chance for it to become a WG item after WG 
formation (but no promises).

It'd perhaps be good for Adam, once his individual spec draft is at a 
demonstrable stage of development, to anoint it with a filename such as 
"draft-barth-http-cookie-reality-00" or somesuch, and submit it (submit both 
.xml and .txt) as an Internet-Draft (I-D) such that it gets into the I-D 
repository and is more easily referenced (e.g. apparently I can't get to his 
git repository from the office due to our firewall, sigh) and has a more 
meaningful filename. (see also <http://www.ietf.org/ietf-ftp/1id-guidelines.html>)

thanks,

=JeffH

---

From: Adam Barth <[email-masked]>
Date: Fri, 7 Aug 2009 16:23:36 -0700

On Fri, Aug 7, 2009 at 4:04 PM, =JeffH<[email-masked]> wrote:
> Thus the spec that Adam is working on (what's its filename? "cookie.xml" ?)
> is effectively at this time an "individual item". As we move to hold a BoF
> and create a WG, if participants here like what they see in that spec as it
> evolves, then there's a reasonable chance for it to become a WG item after
> WG formation (but no promises).
>
> meaningful filename. (see also
> <http://www.ietf.org/ietf-ftp/1id-guidelines.html>)

Done.  I've uploaded the current draft as an individual submission:

http://www.ietf.org/id/draft-abarth-cookie-00.txt

I'd certainly prefer if we form a working group and that document can
be become a working group item.

Adam

---

From: Daniel Stenberg <[email-masked]>
Date: Sat, 8 Aug 2009 22:20:33 +0200 (CEST)

> http://www.ietf.org/id/draft-abarth-cookie-00.txt

I only did a quick first read, but here's my first comments:

1 - nice work to see it this far along already!

2 - section 4.2.1

   "The origin server effectively ends a session by
    sending the client a Set-Cookie header with Max-Age=0."

I would prefer to keep with "expires", as max-age is an artifact of a later 
RFC that was never really used. In my eyes, using max-age is mostly a weird 
mix.

   "Note that an intervening gateway could fold multiple such
    headers into a single header"

I believe the current HTTPbis draft explicitly mention cookies and how the 
Set-Cookie: header is non-standard and thus should (or must?) not be attempted 
to get folded.

3 - section "4.2.2"

   "Comment" "=" value

Really? I've never seen a cookie sent with that, and funnily enough libcurl 
does not support it. I don't think we need to include it there.

   "NAME=VALUE"

I'm curious about the maximum length a cookie value can have in actual 
browsers... I figure we should have a recommended minimum length a client 
should support. If possible.

4 - section "4.3.2"

   "[TODO: Need to interact with public suffix list!]"

I just need to get back to this. Support of that list simply isn't widely 
enough so that we can say it is an implied or defacto standard. It is one way 
to limit what domains a cookie can set, but clearly we need to be more

(I'll follow up with more comments later on.)

-- 

  / daniel.haxx.se

---

From: Daniel Stenberg <[email-masked]>
Date: Sat, 8 Aug 2009 22:36:14 +0200 (CEST)

On Sat, 8 Aug 2009, Daniel Stenberg wrote:

> enough so that we can say it is an implied or defacto standard. It is one 
> way to limit what domains a cookie can set, but clearly we need to be more

Uhm, right I didn't finish that sentense... :-) I think the missing word would 
be "generic", or at least I was attempting to say that we need to express that 
in a way that says clients MAY use additional means to limit what cookies that 
are sent in request in order to minimize security problems or "leakage" of 
cookies between unrelated sites/domains.

-- 

  / daniel.haxx.se

---

From: Adam Barth <[email-masked]>
Date: Sat, 8 Aug 2009 13:36:40 -0700

> 1 - nice work to see it this far along already!

Thanks!

> RFC that was never really used. In my eyes, using max-age is mostly a weird

My understanding is that Max-Age is both widely implemented and used,
but we should write a test and find out.  :)

> Set-Cookie: header is non-standard and thus should (or must?) not be
> attempted to get folded.

Fixed.

> does not support it. I don't think we need to include it there.

I've added this note to the spec.  This is a hot candidate for
deletion.  Is there some test we could write to detect whether a user
agent supports this attribute?  From reading the spec, there doesn't
seem to be a way as there are no requirements on what to do with the
value.

> should support. If possible.

Go ahead and gather data on this point and report back.

Adam

---

From: Adam Barth <[email-masked]>
Date: Sat, 8 Aug 2009 13:38:54 -0700

On Sat, Aug 8, 2009 at 1:36 PM, Daniel Stenberg<[email-masked]> wrote:
> Uhm, right I didn't finish that sentense... :-) I think the missing word
> would be "generic", or at least I was attempting to say that we need to
> express that in a way that says clients MAY use additional means to limit
> what cookies that are sent in request in order to minimize security problems
> or "leakage" of cookies between unrelated sites/domains.

Let's table this issue for now.  I've added a list of tabled items to
the end of the document.  We have a lot to do before getting bogged
down in this issue.

Adam

---

From: Daniel Stenberg <[email-masked]>
Date: Sat, 8 Aug 2009 23:23:32 +0200 (CEST)

> Go ahead and gather data on this point and report back.

I just went ahead and wrote a CGI script that redirects to itself and grows a 
cookie and stores its length in a URL field like "cookie.cgi?len=200" until 
the length in the URL and the actual cookie length no longer matches.

Here's a few results from various browsers:

Firefox 3.0.12:         4000
Firefox 3.5:            4000
curl 7.19.5:	        4999
IE 8:                   5000
Opera 10.00 beta:       4000
Android 1.5 browser:    4000
Chrome 3.0.195.6:       4000
Wget 1.11.4:            7000[*]
mobile safari (iphone): 8000
lynx 2.8.7dev.9:        4000

I think we can safely say that most browsers support at least 4000 characters 
cookie contents.

[*] = this reports "500 Internal Server Error" on 8000, which I don't 
understand why but haven't bothered much more about.

The test is live here: http://daniel.haxx.se/test/longcookie.cgi Feel free to 
use it if you want to try out other browsers, without torturing it of course!

And the perl script that runs it looks like this:

require "CGI.pm";

$len = CGI::param('len');
$c = CGI::cookie('data');

print "Content-Type: text/html\n";

if($len == length($c)) {
     $c .= "A" x 1000;
     $len += 1000;
     print "Set-Cookie: data=$c\n";

     print "Location: longcookie.cgi?len=$len\n";
     print "\nmoo\n";
}
else {
     printf "\nMax cookie length: %d\n", length($c);
}

-- 

  / daniel.haxx.se

---

From: Adam Barth <[email-masked]>
Date: Sat, 8 Aug 2009 14:33:58 -0700

Thanks Daniel.  This is very useful data.  I've added your mail to the
notes directory.  I'll add 4000 as a recommended length in the draft.

Adam

On Sat, Aug 8, 2009 at 2:23 PM, Daniel Stenberg<[email-masked]> wrote:
> I just went ahead and wrote a CGI script that redirects to itself and grows
> a cookie and stores its length in a URL field like "cookie.cgi?len=200"
> until the length in the URL and the actual cookie length no longer matches.
>
> I think we can safely say that most browsers support at least 4000
> characters cookie contents.
>
> The test is live here: http://daniel.haxx.se/test/longcookie.cgi Feel free
> to use it if you want to try out other browsers, without torturing it of
> course!
>
> _______________________________________________
> http-state mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-state
>

---

From: Daniel Stenberg <[email-masked]>
Date: Sat, 8 Aug 2009 23:42:42 +0200 (CEST)

On Sat, 8 Aug 2009, Adam Barth wrote:

> Thanks Daniel.  This is very useful data.  I've added your mail to the notes 
> directory.  I'll add 4000 as a recommended length in the draft.

Which seems to be another proof of RFC2109-ignorance! :-) Quoted from section 
"6.3  Implementation Limits":

        * at least 4096 bytes per cookie (as measured by the size of the
         characters that comprise the cookie non-terminal in the syntax
         description of the Set-Cookie header)

-- 

  / daniel.haxx.se

---

From: Adam Barth <[email-masked]>
Date: Sat, 8 Aug 2009 14:56:58 -0700

On Sat, Aug 8, 2009 at 2:42 PM, Daniel Stenberg<[email-masked]> wrote:
> Which seems to be another proof of RFC2109-ignorance! :-) Quoted from
> section "6.3  Implementation Limits":
>

>From your Perl script, it seems like you're assuming the length limit
is on the cookie value.  Can you test what happens if you make the
cookie name as well?  Also 2109 seems to count the attributes in the
length.  Can you test whether the attribute lengths have any affect?

Thanks,
Adam

---

From: Daniel Stenberg <[email-masked]>
Date: Sun, 9 Aug 2009 00:31:44 +0200 (CEST)

On Sat, 8 Aug 2009, Adam Barth wrote:

> From your Perl script, it seems like you're assuming the length limit is on 
> the cookie value.

Yes, my primary curiosity was about the value part.

> Can you test what happens if you make the cookie name as well?

I did some tests with cookie name lengths, but I'm not yet happy with how they 
work (the tests) so I haven't yet made any wider testing on different browsrs. 
The name tests are trickier since they create a new cookie for each new 
length, so I have to expire the previously tested one etc.

curl has a different limit for the name part (1000 characters), while Firefox 
3.0.x seems to have ~4000 (I haven't measured the exact size but it can't deal 
with 4050).

Also, if I try to set the VALUE part of the cookie to be 4000 bytes long (as 
previously tested to be a common max), I can't send a 4000 bytes long NAME 
part (that also cancels the 3000 bytes cookie) as the entire request becomes 
larger than my apache 2 server likes! ;-/

> Also 2109 seems to count the attributes in the length.  Can you test whether 
> the attribute lengths have any affect?

Well, it gets a bit tricky to figure out what limits what with that number of 
different variables.

I'll see if I get some energy to do some further tests another day.

-- 

  / daniel.haxx.se