
January 28th, 2006, 08:14 PM
|
 |
Certified Abuser
|
|
Join Date: Jan 2005
Location: Line 73 ---^
|
|
heres a post from microsoft geek to geek that explains quite well the downsides of cookie munger and good way to work around them
Quote: | Originally Posted by Microsoft Geek to Geek
GEEK It seems like Internet Information Server (IIS) doesn't accommodate browsers that don't handle cookies or cases where users have set their browser to not accept cookies. The only solution is to use the Cookie Munger. Why can't there be an option within IIS that takes care of this? For example, if it finds that the user won't accept cookies, write the cookie to a temporary database and use the information from there. Do I have to accept the use of cookies?
GEEK One problem with the Web and HTTP is that there is no notion of a session built into it, meaning that there isn't any (easy) way for the server to keep track of the start-to-finish travels of the user without client-side cookies or some method of server-side tracking based on data passed via URL. The closest thing the HTTP headers provide for this is that one of the header elements identifies what URL the user came from.
Client-side cookies provide a very clean and easy way to fix this problem. The client can maintain a cookie element that identifies the user so that the server can maintain things like shopping carts that are directly associated with the user and can easily be returned to at any time in the future.
There are ways to maintain such information without client-side cookies, but they are cumbersome and usually need to be customized to the specific design of the Web site. It traditionally involves embedding some form of identification into the URL. There are many different ways to accomplish this, but the main problem is that every anchor on every page must be altered to reflect the session ID that needs to travel around with the user. This is precisely what the Cookie Munger that you mention does. (The Cookie Munger comes with the Microsoft Internet Information Server Resource Kit.) As you no doubt have determined, this can impose a heavy processing penalty onto every Web page.
For sites that really need to deal with non-cookie-enabled browsers, testing the user coming into the site for support of cookies is the best way to handle this. If the browser supports it, then continue on to the normal site; if it doesn't, then switch the user over to a mirror copy of the site, but with the Cookie Munger installed. This way, only the cookieless users will be affected by the processing overhead.
|
link to original geek to geeks faq ist
Last edited by werD : January 28th, 2006 at 08:16 PM.
|