On Tue, Apr 7, 2009 at 1:53 AM, Darin Fisher <span dir="ltr"><<a href="mailto:darin@chromium.org">darin@chromium.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="gmail_quote"><div>OK... so if I am building an API, the consumer of my API might not realize that I have stuck a sync XHR in the middle of it. (People often do that so that their API can work during unload.) So the consumer of such an API now has to deal with the cookie lock being released?</div>
</div></blockquote><div><br>Yes. If sync XHR spins up a subsidiary event loop, the cookie lock is the least of your worries, because event handlers may run and mutate arbitrary script/DOM state. (We're actually tightening up what is allowed to run during sync XHR in Gecko, but I don't know the details and I don't know what other browsers do.)<br>
<br>APIs that can cause reentrancy, or block, or yield, need to be carefully documented. That's why we want to minimize them...<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="gmail_quote"><div></div><div class="im">
<div><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="gmail_quote"><div><div></div></div>When deciding how to handle cookies in Chrome, we did not worry about the problem being debated here. Our concerns were allayed by recognizing that IE does not try to solve it (and IE6 is multi-process just like Chrome with a shared network stack), so clearly web developers must already have to cope.</div>
</blockquote></div><div><br>You mean IE8.<br></div></div></blockquote><div><br></div></div><div>No, IE6,7,8 (maybe older versions too?) ... you can launch multiple IE6 processes, and those share cookies. You can also programmatically access the same cookies via WinInet from any application. It is not uncommon for a separate application to be mucking around with cookies for <a href="http://intranet.com" target="_blank">intranet.com</a>.<br>
</div></div></blockquote><div><br>OK, that's interesting.<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote">
<div> <br></div><div class="im">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote"><div>How would Web developers cope? There's no way to synchronize. I doubt more than a handful of Web developers even know this problem could exist.<br>
</div></div></blockquote><div><br></div></div><div>You can synchronize through the origin server...</div><div><br></div><div>What I meant was that they "cope" by not expecting document.cookie to return the same results each time it is called. I'd imagine it is not uncommon for users to login to a site in multiple windows and perform similar operations in each browser window. That scenario seems like it could trigger what we have here.</div>
</div></blockquote><div><br>Many sites, such as my bank, detect that and attempt to prohibit it by refusing to let more than one window work. I wonder if they use a race-vulnerable cookie protocol to detect it...<br> </div>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote"><div></div><div class="im">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote"><div><br></div><div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="gmail_quote">I think it would be best to specify that document.cookie returns a snapshot. I think that is consistent with existing implementations including IE, Firefox, and Chrome.</div></blockquote></div><div>
<br>
Not at all. In Firefox, cookies don't change while a script is running, as long as it doesn't call the handful of blocking DOM APIs (such as alert() or sync XHR); we satisfy the current spec.</div></div></blockquote>
<div><br></div></div><div>I don't understand why the sync XHR exception is taken so lightly. As I mention above, that is most frequently used as a transparent-to-the-rest-of-the-application way of communicating with the server (usually because some APIs cannot be easily changed or need to be available during unload). Yet, here we are saying that that cannot be transparent because of this locking issue.</div>
</div></blockquote><div><br>Yes. Making sync-XHR "transparent" by reducing all consistency guarantees to what we can provide around sync-XHR is the wrong direction to go IMHO.<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="gmail_quote"><div></div><div class="im">
<div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote"><div>The insidious part is that almost all the time, IE and Chrome will also be observed to obey the spec; when a quick cookie-read-modify-write script runs, it is very unlikely cookies will change underneath it. (Is it possible people don't write such scripts?)</div>
</div></blockquote><div><br></div></div><div>I'm sure people write cookie-read-modify-write scripts and don't realize the potential problems. But I suspect the incidents of problems related to two scripts doing so are extremely low as to not matter enough to application developers. They can just say: opening our webmail program in two browser tabs at the same time is not supported.</div>
</div></blockquote><div><br>If they're not aware of the problem, why would they say that?<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="gmail_quote"><div></div><div class="im">
<div><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote"><div>Maybe we need dynamic race detection for Web browsers. After a script reads document.cookie, stall for a while to give network transactions or scripts running in other threads a chance to change the cookies so the original script carries on with wrong data.<br>
</div></div><div><div></div><div></div></div></blockquote><div><br></div></div><div>Sounds interesting, but what happens when the script writes cookies? Now there is a merging problem :(</div></div></blockquote><div> </div>
</div>Oh, dynamic race detection is only good for finding bugs more easily, not fixing them :-).<br clear="all"><br>Rob<br>-- <br>"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 53:5-6]<br>