[whatwg] Worker feedback

Drew Wilson atwilson at google.com
Tue Mar 31 11:27:01 PDT 2009

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090331/53be64cb/attachment-0002.htm>

More information about the whatwg mailing list