W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2009

[whatwg] Worker feedback

From: Drew Wilson <atwilson@google.com>
Date: Tue, 31 Mar 2009 11:27:01 -0700
Message-ID: <f965ae410903311127l35ab50f7nb017c8842dd99fa@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:47:49 GMT