Cookies can be blocked, whereas an embedded sessionid in urls will be portable across every browser known to man (even lynx), and still offers security, particularly if web pages check the sessionid against the incoming IP address..

an embedded sessionid in urls... still offers security, particularly if web pages check the sessionid against the incoming IP address.

I believe this to be an oversimplification. Different users can have the same apparent IP address thanks to proxy servers. Additionally, as described in "Writing Apache Modules with Perl and C", URLs with session data can leak out to other sites via the HTTP Referer (sic) header if your site links to external resources or if a visitor leaves your site for another.

MSDN Magazine has an document on maintaining session state that points out, "[Embedding session IDs in URLs] is discouraged from the security perspective because cookieless IDs lend themselves better to discovery and spoofing, and to injection by link posting or phishing attacks".

As I see it, there's a balance to be struck between alienating users who don't want to accept cookies and accepting the somewhat heightened risk of using session IDs embedded in URLs in the absence of cookies.

        $perlmonks{seattlejohn} = 'John Clyman';

Manually? CGI.pm? Apache::Cookie? A search on cpan.org shows up 701 results for Cookie, surely one of them will let you get/set them.