Subject: [http-state] One last attempt to get y'all to like the idea of a non-inclusive Set-Cookie design

From: Paul James Hammant <[email-masked]>
Date: Thu, 18 Nov 2010 13:54:24 -0600

Refer - http://paulhammant.com/blog/not-path-cookies.html

It is a modification to my proposal last month; Better this time based
on the comments in this mail list when I last proposed it. I also
reference the Michal Zalewski blog posting critical of cookies

I think it is even more relevant given the
http://www.eff.org/pages/how-deploy-https-correctly posting from three
days ago where the EFF suggests no more mixed content (see below).

-Paul

>From the EFF blog entry:

** Mixed Content **

When hosting an application over HTTPS, there can be no mixed content;
that is, all content in the page must be fetched via HTTPS. It is
common to see partial HTTPS support on sites, in which the main pages
are fetched via HTTPS but some or all of the media elements,
stylesheets, and JavaScript in the page are fetched via HTTP.

This is unsafe because although the main page load is protected
against active and passive network attack, none of the other resources
are. If a page loads some JavaScript or CSS code via HTTP, an attacker
can provide a false, malicious code file and take over the page’s DOM
once it loads. Then, the user would be back to a situation of having
no security. This is why all mainstream browsers warn users about
pages that load mixed content. Nor is it safe to reference images via
HTTP: What if the attacker swapped the Save Message and Delete Message
icons in a webmail app?

You must serve the entire application domain over HTTPS. Redirect HTTP
requests with HTTP 301 or 302 responses to the equivalent HTTPS
resource.

Some site operators provide only the login page over HTTPS, on the
theory that only the user’s password is sensitive. These sites’ users
are vulnerable to passive and active attack.

---

From: Mark Pauley <[email-masked]>
Date: Thu, 18 Nov 2010 13:00:00 -0800

Honestly, while we've discussed this idea before (that we are wasting resources sending a server state for a stateless resource), I think that adding complexity to the cookies design is not a great way to go.

There's a saying that I think is applicable here: You've got a problem, so you try to solve it using regular expressions.  Now you have two problems.

Why not partition your site either into two domains (one with static content, one without) or into two directories.

/static
/dynamic

- set the cookies for these two paths and you'll get your same result tomorrow instead of whenever your RFC addition is approved.

Here's my best argument: nobody can even get the current cookie RFC's implemented correctly.  Why would adding a complicated 'not-path' semantic work?  Let's just stick with codifying the current lowest-common-denominator behavior of all major browsers and pickle cookies going forward.  If we need to do something cookies can't do, use it as an opportunity to kill cookies.

My advice for you right now is to set minimal cookies and make all of the smarts on your backend where you have control.

On Nov 18, 2010, at 11:54 AM, Paul James Hammant wrote:

> _______________________________________________
> http-state mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-state

_Mark
[email-masked]

---

From: Paul James Hammant <[email-masked]>
Date: Thu, 18 Nov 2010 15:21:53 -0600

So my follow up blog entry isn't suggesting regex (and its 'two
problems') anymore, it is a comma separated bang (!) prefixed
expression that looks like the current path concept.

Also the follow-up blog entry is about pitching the need of mom and
pop sites who are not going to get into the business of CDNs.

Lastly, in terms of URLs dynamic resources are nearly always mounted
at root: examples.com/buyIt?.. rather than in a directory like
examples.com/dynamic/buyIt  because the end users see this URL (at
least if they are reasonably technical and gaze up).

I'm not going to respond to the implicit suggest that the cookie spec
should be parked broken forever :-P

Well thanks for listening anyway :)

- Paul

-- 
Regards,
  - Paul Hammant

Principal Consultant, ThoughtWorks
Cell: 415 999 4637

---

From: Mark Pauley <[email-masked]>
Date: Thu, 18 Nov 2010 14:47:02 -0800

> Well thanks for listening anyway :)

Totally!  It's just that I have never heard anyone clamoring for this before. 

Most small websites would do better to not set large cookies in general.  A minimal cookie is just a primary key for your session table in the application database.  As Adam mentioned earlier, 12 bytes is probably great for that a session key.  Therefore:

Cookie: s=123456789012

I don't really think it's a big deal compared to the fundamental problems of the cookie protocol / mechanism.  I would rather not spend time spit-polishing a beater here.  Most browsers probably waste more space in their user-agent string than that whole header would require.

_Mark
[email-masked]