A Sip From The Firehose: Tuesday, September 3, 1996

By: David Intersimone

Abstract: Fat URL - the Secretary of State for the Internet

Tuesday, September 3, 1996
Scotts Valley, CA

Fat URL - the Secretary of State for the Internet

Summer vacation is over, school is back in session and the Sip from the Firehose is back! I took part of the summer off, attended the Borland Developer Conference, went to the beach and surfed the web. I apologize for the summer hiatus in writing my column.

Have you been noticing what is happening to those simple, easy to recognize, and short URLs that used to appear in location edit box of your favorite web browser? What is going on with URLs these days? They've put on weight. Why?

As developers and users of software, databases and transactions we have been used to the idea that a live connection is made between software and data, between user and application. The state of the application was kept on the client side in the application, the database engine middleware and on the server.

Using the Internet and a web browser we were used to getting a document, reading it, hyperlinking to another document, or retrieving some other information. There was very seldom a need to remember work that was done before or what was currently opened. With the advent of search engines and client/server database applications came the requirement to remember the state of the connection to help decide what work the server needed to do next (retrieve the next 10 search entries, go to the next customer record).

In order to keep track of the state of the connection something was needed on both the client and the server side. A few of several possible solutions for state based Internet connections include:

Fat URLs - keep the state information as parameters in the URL
Hidden Fields - keep state information in hidden fields on form based documents
HTTP Cookies - store state infomation in a special file on the client computer

Fat URLs
A simple solution to preserving state is to store the state information as parameters in the URL. This is the solution that most Internet search engines use. Take a look at the parameters added to the URL when using Alta-Vista:

http://www.altavista.digital.com/cgi-bin/query?pg=q&what=web&stq=10&fmt=.&q=firehose

When working with client/server Internet or Intranet applications it is especially important to remember the state of database application connection. I visited the NeXT Computer WebObjects test drive area. One of their sample applications is the New Dodge Virtual Showroom. When I selected my car search criteria I got back a generated HTML document with the following URL:

http://wofapps2.next.com/cgi-bin/WebObjects/DodgeDemo:3@wofapps2/Main.wo:42.1178642600.293$Main.1.3.7.

That's definitely a fat URL, of course I've seen even fatter.

Hidden Fields
When using HTML forms you see the fields and buttons. Behind the scenes for the fields are HTML tags that define the NAME and VALUE pairs for each filed. There is also a TYPE for each field. One of the types can be HIDDEN. This allows hidden fields to be part of the form but not displayed on the user screen. Several client/server Internet applications take advantage of this hidden field capability to store state information for the session and transactions. Looking at the source for the generated page from the NeXT WebObjects demo finds the following as a hidden field for the state:

The WebObjects application software has placed a text representation of a large block of session state data that will be sent back to the server when the user clicks on a button or graphic. Borland's recently announced product, IntraBuilder, also stores state information in hidden fields on HTML forms.

HTTP Cookie File
Cookies is a file on your client machine that is used by server side software as a place to store and retrieve state information. State objects (a "Cookie") are stored on the client computer with a set-cookie command that is part of the HTML header sent from the server application to the Netscape Navigator or Microsoft Internet Explorer browser client. A Cookie has a Name and Value pair, an expiration date, domain name that the Cookie is valid for, and a set of URLs that the cookie is valid for and can include SECURE to limit the command to only work if a secure connection has been established to the server. The format of the Set-Cookie command is:

  Set-Cookie: NAME=VALUE; expires=DATE; path=PATH;
      domain=DOMAIN_NAME; secure

Internet Explorer 3.0 stores cookies in the WindowsCookies directory on my Windows 95 client computer. I recently installed Netscape Navigator version 3.0 on my machine. Cookies are stored in the navigator directory in the COOKIES.TXT file. The contents of the file last week was:

# Netscape HTTP Cookie File
# http://www.netscape.com/newsref/std/cookie_spec.html
# This is a generated file!  Do not edit.
  .netscape.com  TRUE / FALSE  946684799  NETSCAPE_ID  1000e010,12286ed9
  .boston.com    TRUE / FALSE  946684799  INTERSE      dintersimone.borland.com6218841789863522

A preliminary specification for HTTP Cookies is available from Netscape's web site at http://home.netscape.com/newsref/std/cookie_spec.html. Should we be worried about Internet applications storing information on our local computer? Could someone use numerous browser as a local backup for their hard drive? The Cookies specification lists limitations on how many cookies are allowed and how big each cookie can be (300 total cookies, 4 kilobytes per cookie, 20 cookies per server or domain).

URLs on a Diet or on Steroids?
I hope our URLs don't get too fat - can you imagine an URL that is thousands of bytes long, stores loads of information in hidden fields, and stores more data in Cookies on your hard drive? The best design is to keep as much state information on the server where it belongs, and only keep a minimal amount of state information on the client side to for use in local processing or for retransmission back to the server as needed.

davidi@inprise.com

Published on: 9/3/1996 12:00:00 AM

Server Response from: ETNASC04