Click here to Skip to main content
11,481,822 members (63,999 online)
Click here to Skip to main content

Discover ISAPI. Working with Cookies.

, 15 Jul 2002 88.9K 624 17
Rate this:
Please Sign up or sign in to vote.
This article presents a way to send cookies to client browser from an ISAPI extension.

Sample Image

Introduction

This article presents a way to send some cookie to client browser from an ISAPI extension. An easy way to retrieve and visualize the cookies are also provided.

What is cookie? A small packet of information used to store persistent state information on the user’s computer. Cookies are the means by which, under HTTP protocol, a server or a script can maintain state information on the client workstation.

The Cookie header is included with any HTTP request that has a cookie whose domain and path matches the request.

HTTP cookies provide the server with a mechanism to store and retrieve state information on the client application's system. This mechanism allows web-based applications, the ability to store information about selected items, user preferences, registration information, and other information that can be retrieved later.

Cookie-Related Headers

There are two HTTP headers, Set-Cookie and Cookie, that are related to cookies. The Set-Cookie header is sent by the server in response to an HTTP request, which is used to create a cookie on the user's system. The Cookie header is included by the client application with an HTTP request sent to a server, if there is a cookie that has a matching domain and path.

Set-Cookie Header

The Set-Cookie response header uses the following format:

Set-Cookie: <name>=<value>[; <name>=<value>]...
[; expires=<date>][; domain=<domain_name>]
[; path=<some_path>][; secure]

One or more string sequences (separated by semicolons) that follow the pattern <name>=<value> must be included in the Set-Cookie response header. The server can use these string sequences to store data on the client's system.

The expiration date is set by using the format expires=<date>, where <date> is the expiration date in Greenwich Mean Time (GMT). If the expiration date is not set, the cookie expires after the Internet session ends. Otherwise, the cookie is persisted in the cache until the expiration date. The date must follow the format DAY, DD-MMM-YYYY HH:MM:SS GMT, where DAY is the day of the week (Sun, Mon, Tue, Wed, Thu, Fri, Sat), DD is the day in the month (such as 01 for the first day of the month), MMM is the three-letter abbreviation for the month (Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec), YYYY is the year, HH is the hour value in military time (22 would be 10:00 P.M., for example), MM is the minute value, and SS is the second value.

Specifying the domain name, using the pattern domain=<domain_name>, is optional for persistent cookies and is used to indicate the end of the domain for which the cookie is valid. Session cookies that specify a domain are rejected. If the specified domain name ending matches the request, the cookie tries to match the path to determine if the cookie should be sent. For example, if the domain name ending is .microsoft.com, requests to home.microsoft.com and support.microsoft.com would be checked to see if the specified pattern matches the request. The domain name must have at least two or three periods in it to prevent cookies from being set for widely used domain name endings, such as .com, .edu, and co.jp. Allowable domain names would be similar to .microsoft.com, .someschool.edu, and .someserver.co.jp. Only hosts within the specified domain can set a cookie for a domain.

Setting the path, using the pattern path=<some_path>, is optional and can be used to specify a subset of the Uniform Resource Locators (URLs) for which the cookie is valid. If a path is specified, the cookie is considered valid for any request that matches that path. For example, if the specified path is /example, requests with the paths /examplecode and /example/code.htm would match. If no path is specified, the path is assumed to be the path of the resource associated with the Set-Cookie header.

The cookie can also be marked as secure, which specifies that the cookie can be sent only to HTTPS servers.

Cookie Header

The Cookie header is included with any HTTP request that has a cookie whose domain and path matches the request. The Cookie header has the following format:

Cookie: <name>=<value> [;<name>=<value>]...

One or more string sequences, using the format <name>=<value>, contain the information that was set in the cookie.

Sample Cookie Header

"Set-Cookie:Test=test_value; expires=Sat, 01-Jan-2000 00:00:00 GMT; path=/;"

Storing Cookies

Netscape Navigator stores cookies in a different fashion from Internet Explorer, though it captures the same material from the server. Instead of storing each cookie in its own file, as Internet Explorer does (see for yourself, as your cookies are typically stored in a directory named Temporary Internet Files in your Windows system folder),

Netscape Navigator stores every cookie inside a single file called cookies.txt. (If you're using Nav3, cookies.txt is typically in the C:\Program Files\Netscape\Nav3 directory; Nav4 stores its cookies according to the registered computer user file, in my case C:\Program Files\Netscape\Users\user.)

Functionality

The default method loads on the browser, a simple form where the user is able to put what cookie name/value pair it wants. All job is done in GetCookie method. To be able to write the cookie values on the client machine, we must inform the IIS server to not write its own headers:

   //Turn off sending header by MFC.
   pCtxt->m_bSendHeaders = FALSE;

The headers which will contain the cookies will be written on the client computer by our program using the ServerSupportFunction HTTP function:

   // Send our own headers.
   if (!pCtxt->ServerSupportFunction (HSE_REQ_SEND_RESPONSE_HEADER, 
         NULL, &dwSize, (LPDWORD ) szHeaders))
   {  
      ISAPITRACE1 ("ServerSupportFunction failed: %d\n", 
               GetLastError()); // Report an error.
      return;
   }

The parameter values from the HTML form will be received into GetCookie method using the POST HTTP data transfer, and written after that on the client.

//add the user input cookie
//attention, the entry name in 
//vector collection is "DATA"
bstrToken = L"DATA"; 
index = vecServerCtx.Find(bstrToken);
if (index > -1)
{
    //get a map list from the POST data values
    map = vecServerCtx[index].GetValueAsMap(); 
    if(!map.empty())
    {
        //get the current parameter name
        bstrFormCookieName = map[L"FormCookieName"]; 
        //get the current parameter value
        bstrFormCookieValue = map[L"FormCookieValue"];

        wsprintf(szHeader, "Set-Cookie: %s=%s\r\n", 
            (LPCTSTR)bstrFormCookieName, 
            (LPCTSTR)bstrFormCookieValue);
        //add that cookie to the header list
        strcat(szHeaders, szHeader);
    }
}

For example considerations, in the GetCookie method are written another 2 cookies, one simple and one with time expiration.

All the time on the browser will appear the actual client cookie values from the server context vector collection,

the cookies separate, individual values from the cookies map collection,

and the POST data received from the form. Again the map collection is used to access individual parameter values.

Finally the HTML form is written again to the browser, giving the user the possibility to input/modify the cookie.

//output again the form to input another cookie
   dwLen = strForm.GetLength();
   pCtxt->WriteClient( (void*)(LPCTSTR)strForm, &dwLen, 0);

This article provides also a function to make a server redirect.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here

Share

About the Author

Adrian Bacaianu
Web Developer
Romania Romania
I make programming for over 4 years and extensive experience in C++, ASP, Pascal, MFC, COM+, ATL, TCP/IP, HTTP protocols, XML, XSL, SOAP and SQL.
For the last 2 years i working extensively at the background of financial sites (databases, n tier architecture).

I’m available for contracts and/or outsourcing (adrian_bacaianu@yahoo.com).

Comments and Discussions

 
GeneralHeader format Pin
sanpee20-Mar-07 20:02
membersanpee20-Mar-07 20:02 
Generalhelp Pin
Anonymous25-Oct-03 23:35
sussAnonymous25-Oct-03 23:35 
GeneralStrange problem with cookies and ISAPI Pin
mirakesh10-Feb-03 2:49
sussmirakesh10-Feb-03 2:49 
GeneralWebService ISAPI (VS6) Pin
Anonymous8-Oct-02 6:15
sussAnonymous8-Oct-02 6:15 
Generalbad link for source code Pin
Anonymous15-Jul-02 20:26
sussAnonymous15-Jul-02 20:26 
GeneralRe: bad link for source code Pin
Adrian Bacaianu15-Jul-02 22:54
memberAdrian Bacaianu15-Jul-02 22:54 
GeneralRe: bad link for source code Pin
riverstone16-Jul-02 16:39
memberriverstone16-Jul-02 16:39 
GeneralRe: bad link for source code Pin
Adrian Bacaianu16-Jul-02 22:07
memberAdrian Bacaianu16-Jul-02 22:07 
GeneralRe: bad link for source code Pin
Alexpro22-Jul-02 23:13
memberAlexpro22-Jul-02 23:13 
GeneralRe: bad link for source code Pin
Adrian Bacaianu23-Jul-02 0:25
memberAdrian Bacaianu23-Jul-02 0:25 
GeneralRe: bad link for source code Pin
Alexpro23-Jul-02 0:33
memberAlexpro23-Jul-02 0:33 
GeneralRe: bad link for source code Pin
Adrian Bacaianu23-Jul-02 0:42
memberAdrian Bacaianu23-Jul-02 0:42 
GeneralRe: bad link for source code Pin
Alexpro23-Jul-02 1:35
memberAlexpro23-Jul-02 1:35 
GeneralRe: bad link for source code Pin
Anonymous23-Jul-02 2:04
sussAnonymous23-Jul-02 2:04 
GeneralRe: bad link for source code Pin
Anliz28-Jul-02 16:58
memberAnliz28-Jul-02 16:58 
GeneralRe: bad link for source code Pin
Adrian Bacaianu28-Jul-02 22:25
memberAdrian Bacaianu28-Jul-02 22:25 
GeneralRe: bad link for source code Pin
Anonymous26-Aug-02 9:29
sussAnonymous26-Aug-02 9:29 
GeneralRe: bad link for source code Pin
Anonymous26-Aug-02 21:59
sussAnonymous26-Aug-02 21:59 
GeneralRe: bad link for source code Pin
Anonymous8-Sep-04 19:05
sussAnonymous8-Sep-04 19:05 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Terms of Use | Mobile
Web03 | 2.8.150520.1 | Last Updated 16 Jul 2002
Article Copyright 2002 by Adrian Bacaianu
Everything else Copyright © CodeProject, 1999-2015
Layout: fixed | fluid