There's no point putting in an expired cookie.
Expired cookies should only be used to signal cookie deletion when a session is destroyed or no longer valid.
The right answer is fixing the session keyword (and possibly the session accessor in Context) so that checking a session value when a session doesn't exist returns undef without creating a new session.
It's a trivial patch. Just no one has written it yet.
return unless context->has_session
How about less complaining and more contributing?
David
That sounds like it's working correctly. You got a new empty session anda cookie for it. I don't think it's expected that you won't get a cookieif your session is empty.So Rik, what's the point of getting a new empty session and cookie forit, instead of just a "negative" cookie (a set-cookie header withnegative time)Yeah you're right. It is probably better to put a "negative" cookie there if the session is non-existent/empty. I think I was going with a "that sounds like more code/more complexity than it's worth", but the privacy concerns (I've never cared about what cookies sites are throwing at me, for better or for worse) are fair enough I suppose.and no session at all to waste space on the db?A smart session engine should probably not bother put any entries in the DB if the session is empty, but I take your point.On Sunday, 3 March 2013 at 22:47, Punter wrote:
On 03/03/2013 05:55 PM, Rik Brown wrote:That sounds like it's working correctly. You got a new empty session anda cookie for it. I don't think it's expected that you won't get a cookieif your session is empty.So Rik, what's the point of getting a new empty session and cookie forit, instead of just a "negative" cookie (a set-cookie header withnegative time) and no session at all to waste space on the db?_______________________________________________dancer-users mailing list
_______________________________________________
dancer-users mailing list
dancer-users@dancer.pm
http://lists.preshweb.co.uk/mailman/listinfo/dancer-users