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

[Mark Pauley <[e-mail]>]

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:

> 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.
> _______________________________________________
> http-state mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/http-state

_Mark
[e-mail]