Click Here!
home account info subscribe login search My ITKnowledge FAQ/help site map contact us


 
Brief Full
 Advanced
      Search
 Search Tips
To access the contents, click the chapter and section titles.

Platinum Edition Using HTML 4, XML, and Java 1.2
(Publisher: Macmillan Computer Publishing)
Author(s): Eric Ladd
ISBN: 078971759x
Publication Date: 11/01/98

Bookmark It

Search this book:
 
Previous Table of Contents Next


Which Servers and Browsers Support Cookies?

Although other ways of Web programming, such as CGI and special server interfaces, require that the server as well as the browser understand cookies, only the browser matters to JavaScript. This means, in general, that you can use JavaScript with impunity as long as you know your clients are JavaScript-capable.

Many JavaScript Web applications probably mix the language with other development tools, however, which would require the server to understand cookies. Because new servers and browsers are coming to the net so quickly, it is impossible for a printed book to keep up with the latest software.

ON THE WEB
You can find cookie information at the following locations on the Web:
Netscape cookie spec page (referenced previously in this chapter): http://www.netscape.com/newsref/std/cookie_spec.html
Browsers supporting cookies: http://www.research.digital.com/nsl/formtest/stats-by-test/NetscapeCookie.html
Cookie Central: http://www.cookiecentral.com/
Robert Brooks’s Cookie Taste Test: http://www.geocities.com/SoHo/4535/cookie.html
Article about tracking cookies at the HotWired Web site: http://www.arctic.org/~dgaudet/cookies
Netscape World cookie article: http://www.netscapeworld.com/netscapeworld/nw-07-1996/nw-07-cookies.html

Other State Maintenance Options

As mentioned earlier in this chapter, a few drawbacks exist to using cookies. Perhaps you would rather just avoid the controversy and find some other way to maintain state from one page to the next. Two ways of doing this are available. Which one you use depends on how you, the developer, will have the users get from one page to the next.

The main limitation of these methods is that they work only from one page to the page immediately following. If state information is to be maintained throughout a series of pages, these mechanisms must be used on every single page.

Query String

If most of your navigation is done through hypertext links embedded in your pages, you can add extra information to the end of the URL. This is usually done by adding a question mark (?) to the end of your Web page URL, followed by information in an encoded form, such as that returned by the escape method. To separate one piece of information from another, place an ampersand (&) between them.

If you want to send the parameters color=blue and size=extra large along with your link, for example, you use a link such as this:

<A HREF=“MyPage.htm?color=blue&size=extra+large”>XL Blue</A>

This format is the same as the format used when submitting forms using the get method. A succeeding page can read this information by using the search property of the location object. This property is called search because many Internet search engines use this part of the URL to store their search criteria.

The following is an example of how to use the location.search property. In this example, the name of the current page is sent as a parameter in a link to another page. The other page reads this property through the search property and states where the browser came from. Listing 22.6 shows the first page that contains the link.

Listing 22.6 Where1.htm—You Can Include Extra Parameters in the HREF to Pass State Information


<HTML>
<HEAD>
<TITLE>Where Was I? (Page 1)</TITLE>
</HEAD>
<BODY>
<H1>Where Was I? (Page 1)</H1>
<HR>
This page sets information which will allow the page it is linked
to figure out where it came from. It uses values embedded in the link
URL in order to do this
<P>
We’ll assume that any URL parameters are separated by an ampersand.
<P>
Notice that there doesn’t need to be any JavaScript code in this page.
<P>
And now...
<A HREF=“Where2.htm?camefrom=Where1.htm&more=needless+stuff”>
   ON TO PAGE 2!!!
</A>
<HR>
<ADDRESS>
Jim O’Donnell, <A HREF=“mailto:odonnj@rpi.edu”>odonnj@rpi.edu</A>
</ADDRESS>
</BODY>
</HTML>

Listing 22.7 shows the second page, which demonstrates how to use location.search to find where the browser came from.

Listing 22.7 Where2.htm—Access HREF Information Using the window.location.search Property


<HTML>
<HEAD>
<TITLE>Where Was I? (Page 2)</TITLE>
</HEAD>
<BODY>
<H1>Where Was I? (Page 2)</H1>
<HR>
This page reads information which allows it to figure out where it
came from.
<P>
<SCRIPT LANGUAGE=“JavaScript”>
<!-- Hide script from incompatible browsers!
//
// WhereWasI - Reads the search string to figure out what link
//             brought it here.
//
function WhereWasI() {
//
// start by storing our search string in a handy place (so we don’t
// need to type as much)
//
   var handyString = window.location.search;
//
// find the beginning of our special URL variable
//
   var startOfSource = handyString.indexOf(“camefrom=”);
//
// if it’s there, find the end of it
//
   if (startOfSource != -1) {
      var endOfSource = handyString.indexOf(“&”,startOfSource + 9);
      var result = handyString.substring(startOfSource + 9,
                                         endOfSource);
   }
   else
      var result = “Source Unknown”;
   return result;
}
if (WhereWasI() != “Source Unknown”)
   document.write(“You just came from <B>” + WhereWasI() + “</B>...”)
else
   document.write(“Unfortunately, we don’t know where you came from...”);
//   Hide script from incompatible browsers! -->
</SCRIPT>
<HR>
<ADDRESS>
Jim O’Donnell, <A HREF=“mailto:odonnj@rpi.edu”>odonnj@rpi.edu</A>
</ADDRESS>
</BODY>
</HTML>

Figures 22.5 and 22.6 show the two Web pages, demonstrating that the first was able to pass information to the second.


FIGURE 22.5  Extra information can be included in a hypertext link using the ? and # characters.


FIGURE 22.6  By including extra information in your hypertext links, you can enable some state information to be passed among pages in your Web site.

Hidden Form Variables

The method used in the preceding section works fine as long as the user navigates from one page to another using links. To do the same thing with forms, you can use hidden form variables rather than the location.search parameter.

Hidden form variables have the following format:

<INPUT TYPE=HIDDEN NAME=“HiddenFieldName” VALUE=“HiddenFieldValue”>

You can specify whatever you like for HiddenFieldName and HiddenFieldValue.

Using hidden fields does not necessarily require the use of JavaScript code. They are defined, instead, in the INPUT tag of normal HTML documents. You do, however, need to have some sort of server-based script, such as a CGI program or a server API program, to read the values of these hidden fields. The form containing the hidden variables is submitted to a server script, which spills out everything it knows about your browser on to a single Web page, including the form’s field information. You find your hidden field information listed at the bottom of the page.


Previous Table of Contents Next


Products |  Contact Us |  About Us |  Privacy  |  Ad Info  |  Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc.
All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.