[whatwg] Worker feedback

Robert O'Callahan robert at ocallahan.org
Tue Mar 31 18:25:00 PDT 2009

On Wed, Apr 1, 2009 at 7:27 AM, Drew Wilson <atwilson at google.com> wrote:

> 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.

We know for sure it's possible to write scripts with racy behaviour, so the
question is whether this ever occurs in the wild. You're claiming it does
not, and I'm questioning whether you really have that data.

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.

We don't know how much (if any) performance must be sacrificed, because
no-one's tried to implement parallel cookie access with serializability
guarantees. So I don't think we can say what the correct tradeoff is.

In this case, I think the spec should describe the current implementation of
> cookies, warts and all.

You mean IE and Chrome's implementation, I presume, since Firefox and Safari
do not allow cookies to be modified during script execution AFAIK. Do we
know exactly what IE7, IE8 and Chrome guarantee around parallel cookie

"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090401/7e51e90f/attachment-0002.htm>

More information about the whatwg mailing list