- From: Drew Wilson <atwilson@google.com>
- Date: Tue, 31 Mar 2009 11:27:01 -0700
On Mon, Mar 30, 2009 at 6:45 PM, Robert O'Callahan <robert at ocallahan.org>wrote: > > We have no way of knowing how much trouble this has caused so far; > non-reproducibility means you probably won't get a good bug report for any > given incident. > > It's even plausible that people are getting lucky with cookie races almost > all the time, or maybe cookies are usually used in a way that makes them a > non-issue. That doesn't mean designing cookie races in is a good idea. > So, the first argument against cookie races was "this is the way the web works now - if we introduce cookie races, we'll break the web". When this was proven to be incorrect (IE does not enforce exclusive access to cookies), the argument has now morphed to "the web is breaking right now and nobody notices", which is more an article of faith than anything else. I agree that designing cookie races is not a good idea. If we could go back in time, we might design a better API for cookies that didn't introduce race conditions. However, given where we are today, I'd say that sacrificing performance in the form of preventing parallel network calls/script execution in order to provide theoretical "correctness" for an API that is already quite happily race-y is not a good tradeoff. In this case, I think the spec should describe the current implementation of cookies, warts and all. -atw -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090331/53be64cb/attachment.htm>
Received on Tuesday, 31 March 2009 11:27:01 UTC