Turned out to be Sarafi's support of the <audio> tag being less then perfect. I put wireshark on the connection and noticed that Safari was prematurely terminating the connection. This (via some end of session code in the web sever) was starting a new session, which was in turn creating the new cookie. So you were absolutely on the right trail. Best - J
On Mon, Aug 13, 2012 at 9:14 AM, Mark A. Stratman <strat...@gmail.com> wrote: > On Aug 11, 2012, at 9:56 AM, jeff robinson wrote: >> This hand off causes a change in the user agent that is >> reported to Catalyst, which in turn cause the Session to be reset. > > Are you sure that's the reason? If you haven't already you may want to turn > on debugging and take a close look at your logs. The session plugin outputs > a message when it deletes the session data. > > And if it is, in fact, an issue with the user agent, can you verify the > configuration is being properly read? > Hopefully that gets you a step closer to figuring out what's going on. > > > _______________________________________________ > List: Catalyst@lists.scsys.co.uk > Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst > Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ > Dev site: http://dev.catalyst.perl.org/ _______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
