Good guess, but nope, because the first connection to my server wasn't to that lowercased copy of an old URL, but rather to the proper entry point URL. It's like they started in a new series of transactions and then in the middle, switched and started replaying (incorrectly) an old series of transactions.
Although using key.id() would have not run into the lowercase error, it just would have run into a more bizarre issue, because it was reusing an old session, who's resources had already been returned to the free pool. I think I prefer the error I got! -Joshua On Aug 5, 2011, at 2:47 PM, Robert Kluin wrote: > Maybe someone IMed there buddy in Japan a link to your app? > > The changing of query params case would be a pretty serious concern. > Looks like it is time to use key.id() :) > > > > > > On Fri, Aug 5, 2011 at 14:09, Joshua Smith <[email protected]> wrote: >> On Aug 5, 2011, at 12:23 PM, Simon Knott wrote: >> >> Can you tell how long the session keys are being cached for? >> >> Excellent question. To figure that out, I need to deduce what that session >> key really was. >> >> ag5tZXNvbnN0cmVhbWluZ3IVCxIMU2Vzc2lvbk1vZGVsGMDh1AIM >> >> ag5tzxnvbnn0cmvhbwluz3ivcximu2vzc2lvbk1vzgvsgj3p1aim >> >> Comparing the keys, it appears that the only differences other than >> capitalization are j3p vs. MDh >> If we assume the suffix has not changed, we see there are 4 possible >> capitalizations for the j & p, and of these, only 1 is a real session key. >> Various things (such as bandwidth test results) match between that session >> key and the connect URL hit, so I'm quite certain I found the session key >> which had been cached. >> The real session was created Aug. 4, 2011, 8:04 p.m. and this weird event >> happened at Aug. 4, 2011, 10:54 p.m. >> So it appears that the cached copy was just under 3 hours old. >> But it gets stranger! I log the user IP in the session, and the IP of the >> cached session was initiated from Calgary, Canada, whereas the strange event >> was initiated from either Japan or San Jose (IP geo databases disagree about >> where this IP really is). >> And the original session had this UA: >> >> Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR >> 1.1.4322; .NET CLR 2.0.50727; InfoPath.2; .NET4.0C; .NET4.0E; .NET CLR >> 3.0.4506.2152; .NET CLR 3.5.30729) >> >> That's nothing like the browser that exhibited the weird behavior. >> Proxy server maybe? >> The more I look into this, the stranger it gets. >> -Joshua >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Google App Engine" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/google-appengine?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/google-appengine?hl=en. > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
