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:

<input NAME=WOState.0 TYPE=hidden VALUE="<040b7374 7265616d 74797065 6481e803 84014084 8484134e 534d7574 61626c65 44696374 696f6e61 72790084 840c4e53 44696374 696f6e61 72790084 84084e53 4f626a65 63740085 84016901 92848484 084e5353 7472696e 67009596 1884055b 3234635d 00000000 05000000 0c000000 53656c65 63746564 43617273 86928493 96029284 97961484 055b3230 635d0000 00000500 00000700 00006361 72734944 73008692 8484840e 4e534d75 7461626c 65417272 61790084 84074e53 41727261 79009596 01928484 840e4e53 56616c75 65446563 6f646572 00958401 2a849696 3d868692 84979628 84055b34 30635d00 00000005 00000019 00000063 6172734f 72646572 696e6741 74747269 62757465 4e616d65 00000086 92849796 18980000 00000500 00000900 00006261 73655072 69636500 00008686 86>">

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


Server Response from: ETNASC01