Cookies Collection

Manages all cookies transmitted by AFP to the client together with the response. The collection allows you to create and delete cookies and to set cookie attributes.

Syntax

Response.Cookies(cName)

Description

The collection Cookies is not available in the VFP 7 Engine (EXE7). Accessing this collection in VFP 7 triggers an error. Since the Cookies collection is based on the Visual FoxPro base class Collection, all methods of that class are available. This lets you delete a cookie named CustID that has been added to the collection, through the following lines:

Response.Cookies.Remove("CustID")

In the same fashion you can obtain the number of cookies:

lnCount = Response.Cookies.Count

Originally, Cookies were developed by Netscape (now a member of the Time Warner Group). The HTTP protocol is a protocol without status. The client – normally a browser – sends a request. The server transmits the response that the client will display e.g. as a document. As far as the server is concerned, that matter is finished, and it forgets about the client. If the client sends a new request, the server is unable to determine if there has been previous contact with that client, whether this contact was made recently or a long time ago, and of course it won't remember the context in which this contact was made.

When designing the HTTP protocol, the declared goal was the ability to link up freely available static documents. To execute this task there is no need for the client to register or for the server to track the documents that were retrieved. Also, a "status-less" implementation is far simpler.

To manage a status not only need you be able to determine which user logs in at what time, there also needs to be a notification as soon as a user logs out again. Additionally, all users currently logged in must be managed by the server. This requires additional resources which at the beginning of the Nineties were still limited.

The increasing penetration of the Internet and especially the growth of interactive offerings like web shops increased the need to reproduce entire processes. Recognizing a user across multiple pages is a basic requirement of this; otherwise the user wouldn't be able to put an item in a shopping basket and proceed to the check-out.

There are in principle two options to manage a shopping basket. One option would be to keep track of it on the server, e.g. in a file. The ID of the shopping basket is passed on to the client who hands it in the next time the shopping basket is called up. Transmission of the ID could be effected by either attaching it to the URL as a parameter or through the development of a method that would allow the transmission of this data in a manner transparent to the user.

The first method would have the manifest advantage that no extensions are needed and that it could have been implemented with the then valid standards HTTP 1.0 and HTML 2.0. Netscape, however, decided to use a different method to manage the shopping basket. The method was to keep the shopping basket on the server rather than on the client.

If the basket is then transmitted to the server through the URL, the data volume of up to 1 KB may be too big for the URLs of many browsers. In addition, Netscape regarded the ability to save this data permanently as a good idea. The user should be allowed to put an item in the basket, suspend the procedure and continue, say, the following day.

Whilst in the case of purely temporary baskets the demands on the server would be high but still justifiable, permanently storing movement data over days or weeks would have far exceeded the resources of a web server in 1994. It was this resource constraint that led to the idea of depositing the data on the client. That was when the idea of cookies was born.

Meantime, saving a larger amount of data in a cookie is only important in the context of personalization. Web pages store non-critical data in it, e.g. the preferred colour, the sequence of dynamic elements etc. Since cookies are saved on the client computer they cannot be protected against manipulation. That is why in the meantime no data pertaining to the security will be deposited there. Neither will AFP save all session variables in a cookie, only the session ID that will allow you to locate and load the data.

Cookies turned out to be specially suited for providers of banner ads. As cookies are only transmitted to those web pages from which they originated they cannot create substantial movement profiles. These can only be created inside a web page.

Providers of banner ads, however, are integrated in quite diverse web pages. These providers then receive only those cookies that they sent out themselves but not the cookies of the page where their banner is integrated. They learn, however, into which page their ad has been integrated. If providers of banner ads combine their own IDs that have been saved in their own cookies with these addresses, then the bigger the diversity of the web pages that integrate their banner ads, the higher the quality of the movement profiles created. This practice has led to a widespread refusal to accept cookies.