Re: cookie retrieval problem

[inman]

Things to know about cookies:

The server requests that a cookie be set - Your server application has no control over whether a cookie has been set. Your app will only know when the user requests the next page. Features such as session tracking can be handled using non-cookie means such as URL re-writing.

The browser makes the rules - Your app can only request that a cookie be stored. It is up to the browser settings (as dictated by the user, sys policy etc.) whether to cooperate with a set-cookie request. The decision depends on the security and privacy settings implemented by the browser.

The rules are changing - It used to be the case that browsers had a config option to turn cookies on or off. Then there came 'security zones' which divided the network up into internet, intranet and trusted zones. A different cookie policy could be enforced for all. Now the cookie settings are more associated with privacy and things such as third-party cookies and cookies that contain identifiable information are normally turned off. A new feature is the P3P policy of a server. This is a method that the site owners have of declaring their cookie usage policy such that it can be enforced by the browser.

Bug Fixing

• Cookies are limited in size. Try and store anything larger than 4kb per cookie and expect not to see it again (or if you do it may be truncated).
• The number of cookie per site is limited. They are cleaned out on an oldest loses basis. This is to stop a website from filling up your hard disk. You can fall foul of this problem if your site is a portal and there are a number of applications that want to set cookies using the same portal URL. Setting cookies that incorporate a path element is useful.
• You may not get back what you were expecting. A conflict between cookies set at the domain level and those set at the host level can leave you with the wrong cookies. I ran into this with java session IDs (all called JSESSIONID) being set by a number of different web app servers in the same domain. The browser will send what it thinks is the best cookie based on domain, host and path matching.
• Cookies can get lost in transit if any part of the cookie handling mechanism doesn't work. I was loosing cookies because a web server filter had a fixed buffer size for HTTP header handling. When you debug you need to confirm that the cookies are being sent and retrieved at different stages in the pipeline.
• There are cookie related issues that affect one browser and not another. Mozilla will work OK with cookies from a host name that contains an embedded underscore; IE6 will not. Check that your application works with different browsers and browser versions.

I find that working with Mozilla gives me the flexibility that I need when debugging cookie related issues. Just set your preferences to 'always ask' about cookies so that you can watch the cookie setting process. There is also an addin that allows you to watch the HTTP headers (I forget what it's called but I am sure that another monk will help out).

[thraxil]

I find that working with Mozilla gives me the flexibility that I need when debugging cookie related issues. Just set your preferences to 'always ask' about cookies so that you can watch the cookie setting process. There is also an addin that allows you to watch the HTTP headers (I forget what it's called but I am sure that another monk will help out).

it's called live HTTP headers and it rocks.

[b10m]

Besides Live HTTP Headers there is also a nice extension called Web Developer, which has a "Cookie information" function that will show you *tada* Cookie information. Might be helpful here too.