 |
 |
 |
Understanding Web Technologies and URL Sequences
Web based transactions are an increasingly important part of the Internet and essential to e-commerce. You can use SiteScope's URL Sequence Monitor to monitor the availability and function of a sequence of Web pages that are used in transactions. The URL Sequence Monitor is flexible to simulate a range of sequence types and navigation. Given the number of technologies used in e-commerce, it is impractical to try to anticipate the many different implementations used in Web page sequences. Having a general knowledge of key Web technology concepts is useful in building SiteScope URL Sequence Monitors. This primer is intended to provide you with a introduction to several concepts that will help you set up Web page sequence monitoring.
Topics that are covered in this section include:
- Client-Server Communication on the World Wide Web
- URL Sequences and Client Side Programs
- Other Elements of URL Sequences
Client-Server Communication on the World Wide Web
Communication on the World Wide Web (WWW) is, by definition, the exchange of information using the Hypertext Transfer Protocol (HTTP). Most exchanges involve a client sending a request to a server which in turn responds to the request. The Web browser, as the client, sends an HTTP request over the Internet where it is routed to a Web server associated with the domain name in the browser's request. The Web server receives the request and responds with the content of a specially formatted file which makes its way back to the client. The following outlines some of the different ways that this exchange might be handled in the context of Web page sequences.
Static HTML Sequences
The basic HTTP exchange on the World Wide Web is the exchange of static Hypertext Markup Language (HTML) documents. Static HTML documents often contain hyperlinks on one page that generate a request another document from the same or different server. While this is an exchange of information, the exchange tends to be unilateral in the direction of the client and is not very useful for e-commerce. As illustrated in the figure below, the exchange of information is relatively limited.
Figure UTP-1. Example of a client request and server response for static HTML Web pages.
In some cases, a hyperlink URL may contain a Common Gateway Interface (CGI) request which triggers a server side program. The execution of this program often creates another Web document in response to the requested URL. This concept is discussed more below.
HTML Forms and CGI (Common Gateway Interface)
To improve the versatility of the World Wide Web it became clear that a technique was need to enable better exchange of information between the client and the server. The addition of the HTML FORM and its related INPUT elements to the HTML specification along with corresponding developments in Web server software allowed data entered by a user to be transmitted to the server as part of an HTTP request. The Web server can then pass this information off to another application record and respond based on the information entered by the user. This makes use of what is called the Common Gateway Interface (CGI). Web pages containing HTML forms normally use this technology to pass information entered by the user to the server.
The HTML FORM tag normally includes an action attribute that specifies a server side program or script that is called when the form's SUBMIT button is pressed. This often looks something like http://www.company.com/cgi-bin/program.pl, http://www.company.com/cgi-bin/program.exe, or http://www.company.com/cgi-bin/serverscript.asp. A form's METHOD attribute determines how information from the form is transmitted to the server specified in the action attribute. The most widely used methods are GET and POST. The data submitted to the server using CGI is sent as a series of name-value pairs representing the names of the different input features contained in the form associated with the values entered by the user. Using the GET method, these name-value pairs are appended to the URL request string or address. The POST method passes the name value pairs in a special section of the HTTP request header.
For example, we will suppose a Web page includes a search feature with a text box and a button labeled Search. The search text box and the button are contained within an HTML FORM tag. For this example, the action attribute for the form is http://www.company.com/cgi-bin/search.pl and the method is get. The Search button is actually the submit input element for the form with a value attribute of Search. The text box also has a name attribute which, for this example we give the value of find
Supposing that the user enters the word "monitoring" in the search text box and presses the Search button, the form would send the following CGI request to the server as a URL string:
http://www.company.com/cgi-bin/search.pl?find=monitoring
This particular example requests the execution of a CGI program called "search.pl" on the company.com server.
URL Sequences using CGI Programs
Using the example of the Web page with the search feature, we can look at the basic process of a Web-based CGI transaction.
When the browser sends the URL request to the server, the server reads the URL in order to decide how to respond. In this case, since the URL contains the string cgi-bin, the server is configured to send a system command to run the program called search.pl rather than retrieving an HTML document named search.pl. Using the Common Gateway Interface, the program, search.pl, has access to all of the information included in the HTTP request. This includes the name-value pair of find=monitoring. Search.pl can then parse this data and perform an operation based on this user input. In this case, it would query a database to look for entries containing the string "monitoring". The program would then return the results of its search, along with the necessary HTML tags to form a Web page, to the server which in turn sends it back to the browser. Figure UTP-2 diagrams this transaction.
Figure UTP-2. Example of a URL transaction using HTML forms and a CGI application.
Server Side Includes
Server Side Includes (SSI) are a limited alternative to CGI transactions. Server Side Includes can be used to execute server side programs though this is usually not very interactive. Enabling SSI's on a Web server is also considered a security problem and consequently are not widely used. HTML pages that include SSI code are usually identified as Web pages with a file extension of .shtml or .shtm. One challenge for constructing SiteScope URL Sequence Monitors for Web pages with SSI's is that the SSI code is processed by the server and the instructions are not visible in the client browser. This obstacle also applies to most other transactions involving server side processing.
Server-side Scripting
An alternative to CGI programming is server side scripting. Generally, server side scripting involves creating Web pages with special script language markup embedded in them. Examples of this include Active Server Pages using Microsoft's special Visual Basic scripting, Cold Fusion pages using Allaire's ColdFusion Markup Language, or PHP pages (originally known as "Personal Home Page Tools") with PHP markup.
Figure UTP-3. Example of a URL transaction using HTML forms and ASP scripting.
Server side scripting technology is generally designed to be more efficient with server resources that separate CGI applications. Although similar in effect to CGI programming, the script is contained in an individual document and is executed as the server processes the requested document.
Documents that contain server-side scripts are usually designated with the following extensions to the filename in the URL : *.asp for Active Server Pages, *.cfm or *.cfml for ColdFusion, *.php, *.php3, or *.phtml for PHP pages.
Servlets
Comparable to server side scripting are Java servlets. Servlets can be invoked as separate CGI applications or they may be invoked by code embedded in a document which is processed by the server as the document is parsed in response to a client request (similar to ASP, CFML, or SSI). An example of Web documents that contain embedded Java code is Java Server Pages (JSP). Documents that use this technology usually have a file extension of *.jsp.
URL Sequences and Client Side Programs
An HTML page containing one or more forms that also includes client side scripts that manipulate data submitted by the form. The most common client side scripting is in Javascript (a.k.a. Dynamic HTML or ECMAscript) though client side scripts may be VBscript or Perlscript. In many cases, client side scripts are used to determine which browser the client is running or to create interactive visual effects on the Web page in the browser. Examples of this are mouseover image changes on menu lists and buttons.
Other examples of client side programs include Java applets and Active X controls. These are generally embedded programs that are executed within the client's browser environment. In many cases these types of programs are used to produce graphical effects in the browser window. They may also be used to perform interactive calculations on data that the customer has entered. Large and complicated applets or Active X controls can add significantly to URL download times. In most cases this is reserved for video and graphic effects rather than manipulation of user data so it is normally not a concern for SiteScope URL sequences.
Other Elements of URL Sequences
There are some other elements used in Web page design that influence SiteScope URL Sequences. These include HTML Frames, client "Cookies", transaction Session ID's, and redirections using an HTML META tag instruction.
HTML Frames
Frames are useful in organizing the display of Web content and allow more than one Web page to be displayed at a time. A common use for frames is to display a common site navigation menu at the top or left side of the screen while the content of different pages on the site are displayed in the main portion of the screen.
While the use of frames is often not noticeable to visitors to a Web site, they are significant in processing URL sequences. In the case mentioned above, where frames are used to display a navigation menu in one frame and various Web pages in another frame, it may be necessary to switch between the content of the two frames in order to complete an online transaction. This is seemingly transparent to user but not to the browser.
When viewing a Web site that uses frames, the Web page sent to the browser is a page containing a FRAMESET and frames rather than the actual content of the navigation menu or other content. In processing the frames, the browser retrieves the content for each frame by reference, as it were, and the actual content is not directly accessible to SiteScope. This means that if you view the source code for a page with frames using the browser, you will not see the markup for all of the text, images, or hyperlinks that may be displayed on the screen. Accessing hyperlinks and FORM elements that are displayed in a frame requires that SiteScope retrieve the URL referenced by the frame that physically contains those transaction elements. Therefore, stepping from a frame page to the specific URL referenced by the frame requires a distinct step in SiteScope URL sequences.
Cookies and Session ID's
Communication on the World Wide Web is, by default, stateless. This is to say that normally each client request to a server is treated as a unique and one-time event. From the client side it is easy to take it for granted that your browser appears to be the only client making requests of a particular server. In fact, the server may be processing a dozen other requests in the time it takes you to read a Web page or complete a form on a page you have received. When you send your next request to the same server, the server responds without knowing if your request is from a new visitor or from someone who was already served another page. Client requests are received by the server, the server sends the response and then the interaction is effectively forgotten by the server. This results in limitations in trying to perform on-line transactions where one step is dependent on what was done in a previous step.
One solution for this for the server to send a unique code to each client which can be used to track the interaction between the server and client. The two commonly used techniques for this are "Cookies" and the use of Session ID's. The two may be used separately or together depending on the design of the Web application.
Browser cookies are small pieces of information that a server sends to a browser to be stored on the client machine. How and where the data is stored depends on the client browser. Generally, a cookie-enabled browser will check it is cookie storage for cookies that match the domain that the user is requesting. If there is a match , the browser will send the cookie data in the HTTP request header to the server. The server can then use this cookie data to process a customized response based on the cookie data. This may include cross referencing cookies data with customer data in a back-end database. The cookie may also be used to track a transaction session with a particular user. Cookies remain stored on the client machine until they are scheduled to "expire".
A Session ID, as the name implies, is another way for a server to keep track of interactions with different users. Session ID's differ from Cookies in that they normally only exist for the duration of a transaction or "session" with a server. A server may reset or clear a session ID issued to a client when a transaction is complete or if the client is no longer making requests of the server after a certain time out period.
Another difference with session ID's is that session ID's are usually part of the Web page sent to the client browser rather than being written to file on the client machine. This means that they may be included in hidden input fields as part of a form or added to the CGI ACTION attribute of a form. They may also appear in the HTTP GET request string shown in the address bar of the browser. The objective is to have this same session ID returned to the server when the user makes his or her next request. The figure below diagrams the concept of session ID's to keep track of transactions between two users.
Figure UTP-4. Example of a URL transaction using Session ID to track the progress of multiple users.
Redirection using the HTML META tag
Redirecting a browser client from one URL to another is a technique used by some sites that present visitors with a introductory splash screen graphic or video before proceeding to the main Web content. This redirection is usually set to happen within several seconds of when visitors downloads the initial page.
This redirection can be done with a special HTML META tag in the page containing the splash screen. META tags are found in the HEAD section of a Web page. These META tags can contain several different types of information including a reference to what software was used to create the page and a description of the content for indexing by Web search engines. The META tag that controls a redirection is sometimes called a Refresh tag and generally has the following syntax <META HTTP-EQUIV="Refresh" CONTENT="nn,URL=nextpage.html">
Copyright © 2004 Mercury Interactive Corporation.
All rights reserved.
|
|
|