esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ethan Jewett <>
Subject Re: [Lift] JSON handler doesn't respond
Date Tue, 01 Sep 2009 17:31:13 GMT
I'm trying to reproduce it now (waiting). I was able to verify that if
you're running Firebug in FF3.5, it keeps a record of all the headers of all
requests since you loaded the page, so it's pretty easy to check what the
cookie and session ID looked like at the beginning and compare it to what it
looks like at the end.

On Tue, Sep 1, 2009 at 12:38 PM, Vassil Dichev <> wrote:

> I cannot reproduce the problem locally, so probably we don't need to
> do any more debugging. Anyway, you can read on if you want my detailed
> explanations of the problem.
> > I don't see that this had been mentioned before. Definitely makes it
> sound
> Well, you can't have multiple users logged in a single browser
> session. When you try to open another browser on the same machine, it
> sees the open port of the existing firefox instance, so it just sends
> a command to this existing instance to open a new window. Like you
> said- one browser, one cookie.
> >
> > Do you get the same issue intermittently when you are logged in as only
> one
> > user in a single browser?
> Yes. As I mentioned, Dick and Anne have also reproduced the problem,
> and they definitely haven't played with multiple Firefox instances.
> > Just trying to understand the problem...
> Me too. I'm not saying that this *is* the cause of the problem. David
> asked what I do to reproduce the problem. Since I've already mentioned
> that I'm using Firefox before, I decided to provide more details on
> the last scenario when I experienced this problem. This was the case
> when I was testing "resends", where you need to have 3 users, where B
> follows A, and C follows B but not A. I doubt this is relevant, but
> decided to share it, since, again, David is trying to reproduce the
> problem.
> >>
> >> I was thinking along the lines of Chrome doing something so that the
> >> session doesn't expire as easily.
> >>
> >
> > I'm not sure what Chrome could be doing differently. As far as I know
> from
> > my API hacking, the lift session is just stored as a cookie, which is
> then
> > sent in the header of every subsequent request to the site. Either the
> > cookie is being sent or it's not. If it is being sent but not recognized
> on
> > the Lift side, then that would be an ESME issue. If it is not being sent
> > correctly, then that is a browser issue.
> I'm not sure, but I think long polling has some specifics for
> different browsers. If for some reason the session expires more easily
> on one browser, but not on the other, this could be relevant. Since
> long polling relies on renewing the request after a timeout, that
> could make the browser keep the session without expiring it. Of
> course, that's just hypothetical.
> At least, I'm trying to reproduce the problem with Chrome on the old
> Stax instance and so far I cannot, and I can with Firefox.
> Vassil

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message