[ic] mv_no_session idea (best of both worlds)
kevin at cursor.biz
Fri Jul 13 03:52:32 EDT 2007
Grant <emailgrant at gmail.com> wrote:
> > My advice would be to use "ScratchDefault mv_no_session_id 1" and to
> > forget all about the "mv_no_session" scratchpad variable.
> This is tricky. It's a balancing act between server load,
> functionality, and clean URLs for new/altered spiders and links
> pointing to the site.
Search engine spiders are pretty much covered by the Robot*
configuration directive. Recognised spiders will not be shown
session IDs in any of the in your pages.
You can get the latest robots.cfg file from here:
(Scroll down to find and download the robots.cfg file.)
Once you have that file, you can do one of two things:
1. (recommended) Throw the file into the "etc" directory, found
under your Interchange installation's home directory, and
then modify your interchange.cfg (1) to "include etc/robots.cfg",
and (2) to remove any existing Robot* directives.
2. Replace any existing Robot* and NotRobot* directives in
your interchange.cfg file with the content of the new
Either of the above methods will work, but the first method will
make it easier for you to keep the file up to date. Just replace
the file whenever a new version is available.
Note that new new configuration will not be used until you restart
Please send suggestions for new Robot* directive entries either to
me, or to this mail list. I will review the suggestions, and add
them to the file if I decide that it is correct to do so.
Links pointing to the site (including bookmarks) are not a
problem. If a session ID is specified in a link then that session
will only be valid if (1) the session has not expired and (2) if the
user's IP address or hostname matches the values stored in the
session. If the session is found to be invalid then a new session
will be silently created, with a different ID, and all links on the
initial page will be created to point at the new ID.
> If I just set mv_no_session, a new session will be created for each
> request if the browser doesn't accept cookies right?
Correct. A new session with every request will effectively mean that
no session is maintained at all, but with the added overhead of creating
wasted session files. You will probably also need to increase the
length of your session ID string to increase the number of session IDs
that can be created.
CPU time will be wasted in maintaining these unused sessions, disk
space and inodes will be wasted by these unused session files, and
further CPU time and disk load will be wasted while Interchange looks
for an unused session ID with every request.
Session IDs are created at random. If you have a lot of "used" session
IDs then the random ID might be a duplicate. Interchange has to check
and allocate a new ID if required, and keep doing that in a loop until
an unused ID is found. This takes time.
I must admit that I'm struggling to see the problem that you're trying
to solve here.
_/ _/ _/_/_/_/ _/ _/ _/_/_/ _/ _/
_/_/_/ _/_/ _/ _/ _/ _/_/ _/ K e v i n W a l s h
_/ _/ _/ _/ _/ _/ _/ _/_/ kevin at cursor.biz
_/ _/ _/_/_/_/ _/ _/_/_/ _/ _/
More information about the interchange-users