<br><br><div class="gmail_quote">On Mon, Mar 30, 2009 at 6:45 PM, Robert O'Callahan <span dir="ltr"><<a href="mailto:robert@ocallahan.org">robert@ocallahan.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br></div><div class="gmail_quote"><div>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.<br>
<br>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.<br>

</div></div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>In this case, I think the spec should describe the current implementation of cookies, warts and all. </div><div><br></div><div>-atw</div><div> </div></div>