Active Server Page Processing and the World Wide Web
Certainly in the area of web development there are times when the behaviour of the application will seem rather weird. The main reason for this weirdness is the way that the browser interacts with the server and the journey that web pages take between the two.
We will take a look at the structure / behaviour of an ASPX page and examine how it is passed between the browser and the server.
In looking at the ASPX page we will look at some of the facilities it provides and look briefly at the underlying HTML.
The Internet and TCP/IP
The internet is a huge network of interconnected computers that communicate with each other using a protocol called TCP/IP (Transmission Control Protocol / Internet Protocol). It was developed as a result of defence research in the 1960s.
TCP/IP became the standard in 1982 and allows a program on one computer to communicate with a program on another.
It is worth highlighting this point – it allows programs to talk to each other.
Rather than connecting every computer to every other computer on the network individual computers are connected to a local network and the local network has a single access point connecting it to the internet.
In this sense the internet is a network of networks.
In order for the network protocol to work, each machine on the network is allocated an IP address. An IP address is a unique 32 bit number made up of four 8 bit numbers separated by a full stop.
For example if you visit http://209.85.227.105/
You will find yourself at the following page...
Since that is (one of) the IP addresses for Google.
An organisation is often assigned blocks of IP addresses.
For example www.dmu.ac.uk has an IP address of 146.227.160.79
www.cse.dmu.ac.uk has an address of 146.227.57.2
G677 (my server) has an address of 146.227.53.94
Note the 146.227 which is common to the DMU machines.
Since http://209.85.227.105/ is not obviously www.google.com there is also a system for machines to have a name.
The translation of names to IP addresses is handled by software systems called name servers using the Domain Name System (DNS).
Ports
Remember that TCP/IP allows programs on machines to communicate. If the machine has an IP address then how do we identify the specific program on the machine?
This is achieved by allocating ports to the programs running on the machine.
When one machine wants to use a service on another it uses the IP address to identify the machine and makes a connection on a port number.
There is no law that states a specific port must be used for a service however there are certain ports that traditionally provide services.
· 80 HTTP (web pages)
· 21 FTP (File transfers)
· 119 NNTP (Network News Transfer Protocol)
· 443 HTTPS (secure web pages)
If we consider the IP address of my server 146.227.53.94
If we connect to port 80 then we are attempting to initiate a connection using the Hypertext Transfer Protocol (HTTP)
If we connect to the same machine specifying port 21 we are attempting to make a File Transfer Protocol (FTP) connection.
The World Wide Web
Up until about 1989 the Internet existed quite happily without the World Wide Web. People used a range of software and protocols to transfer data and communicate.
· File Transfer Protocol (FTP) was used if you wanted to share a file
· Telnet was used to log in remotely to control another machine
· Usenet was used to share information via news groups (one of the oldest parts of the internet!)
The World Wide Web added another set of programs and protocols and has become so successful that we tend to use internet and web interchangeably. (Incorrectly)
The Client Server Model
When computers communicate over a network in many cases one acts as a client (requesting services) and the other as a server (providing services). The web operates on this client server basis.
The simplest and most obvious example of client and server is our experience of using a web browser.
We start the browser of our choice (Firefox / Internet Explorer).
Most browsers are configured to open a start page (for example Google).
At start-up the browser sends an HTTP request to the remote (Google) server on port 80.
In this case it connects to http://www.google.com
The Google web server receives the request. In the absence of a request for a specific page the default Google homepage is transmitted along the network.
(The URL may also refer to a specific page or program on the server.)
The browser receives the page and renders the HTML as the Google homepage you see.
So if I am Using Visual Studio where is the Web Server?
The final point I want to make is this question. “Where is the web server when I am developing a web site in Visual Studio?”
When you compile and run your site in Visual Studio the environment starts up an instance of the development server.
The development server is visible here...
The server uses the IP address of the machine you are working on and is allocated a port number by the IDE (In this case 49527). This port number is normally allocated dynamically by Visual Studio but if you wish you may specify your own.
Visual Studio then starts the browser with the URL on the development server. This URL contains the port number it needs to connect to the server on...
http://localhost:49527/delme1/Default.aspx
http: indicates the protocol to use
localhost indicates this computer
:49527 is the port number to connect on
By means of the development server Visual Studio makes your computer “talk to itself” such that it becomes both client and server.
Server v Client Side Code
The above scenario becomes quite simplistic as soon as we start adding some sort of processing into the system.
Code may be added at either end of the process.
Client side code involves code embedded in the web page that runs in your browser typically using Action Script (Flash), JavaScript or VBScript. We are not really interested in client side scripting within the scope of this module.
Server side processing involves code that is processed at the server.
With this kind of processing we are adding an extra element to the above diagram.
What this means that rather than the server returning a simple page, some code is executed on the server that generates the page dynamically.
When the browser makes a request to the server, additional data is sent. This data is typically captured by a web form.
For example the FaceBook login...
When you press “Log in” a request is made to the FaceBook server and the Email and Password is sent with the request.
The FaceBook server receives the request from the browser and examines the data that is carried with it.
The server runs a program (in the case of FaceBook written in PHP) that checks that the email and password are correct and then dynamically constructs your home page. This page is then sent to your browser.
XHTML Forms GET and POST
The screen shot below is the layout for a simple HTML form...
The functionality is fairly obvious. When a first and last name is entered and the submit button is pressed the form is sent to the server which displays the data entered in the form.
So...
Produces...
Just to prove that the data is being passed to the server.
The HTML for the form looks like this...
Notice the line of code at the top
<form action="http://g519-md.ad.cse.dmu.ac.uk/Request/" method="post">
This tells the form where the data in the form is to be sent. In this case a program that lists the data in the form.
It also tells the form how the data is to be sent. In this case “post”.
If we modify the form to change the way that the data is sent from “post” to “get” when we press submit we see the following effect.
http://g519-md.ad.cse.dmu.ac.uk/Request/?txtFirstName=Matthew&txtLastName=Dean&Submit1=submit
Notice how the data is now visible within the URL. By using “get” rather than “post” we are able to see the query strings within the URL.
This illustrates the way that data is passed between browser and server and is also a quick introduction to XHTML forms.
Active Server Pages (ASPX)
In the previous example we used a form that runs on the browser and is sent across the network in the HTTP request.
Web forms / Active Server Pages operate in a different manner to XHTML forms as they run only on the server.
Events & Event Procedures
Web forms follow an event driven model. An event is something that happens to the interface.
This may be something the user does by interacting with a control on the web form. An event may also be something that happens at a system level not directly triggered by the user.
Examples of user triggered events are
Click triggered when a user presses a button
Selected Index Changed activated when the user selects an item off a drop down list
Examples of system generated events are
Load runs when the ASPX page is loaded by the server
Typically used to initialise the web form
Unload runs when the ASPX page is unloaded from the server
Typically used to save data
With an event you associate code via event procedures. These sections of code are executed whenever the associated event takes place.
Anatomy of an ASPX Page
The code below shows the XHTML of a simple web form.
At the top of the file is the Page directive which instructs the server how to process the web form.
For example in this case the language is C# and there is an associated code file called Default.aspx.cs
It is quite possible to embed code directly into the web form as in the following example.
Here we can see the event procedure for the click event of the button btnDemo.
However it is more common to separate the XHTML from the code as it makes using the same web form with a different language a possibility.
Active Server Controls
Active server controls may be typed in as code within the code view of the page or (more commonly) handled by the visual designer.
In this example a text box called txtDemo and a button btnGo have been added in code view. Both active server controls.
Notice how the controls are marked up using the <asp tag.
The web form looks like this in the visual designer.
Server Side Processing of an ASPX Page
One issue you will need to understand at some point is the nature of post back and web forms.
Post back is either true or false and indicates if this is the first time an HTTP request has been made for this page.
Page Processing When Post Back is False
We need to now understand what happens when a browser makes an initial request for this ASPX page.
· The browser sends the request to the server for the page
· The server runs the page load event
· The server runs page unload event
· ASPX converted to HTML and sent to the requesting browser
Now take a look at what the browser receives from the server
There is a lot of extra code we are not interested in however notice that the asp text box and button at the server are now an XHTML text box and button at the browser.
The server has taken the code we created in the web form and converted it into XHTML which is readable on pretty much any browser.
In this first request, post back is false as this is the first time the page has been requested.
Page Processing When Post Back is True
The browser is now displaying a page that contains the following form.
If we enter some data in the form and press “Go”...
...the XHTML page is sent back to the server. More specifically the XHTML form is posted back to the ASPX form so that it may up-date itself with the new state of the data in the form.
· The browser sends the request to the server
· The server runs the page load event
· The server runs other events (in this case the click event of the Go button)
· The server runs the page unload event
· All asp controls changed into suitable HTML controls and sent back to the requesting browser
Because this is the second round trip for the web form it is being “posted back” so in this case the state of post back is true.
(When we reach the point of using post back in our code it makes life a lot easier if you understand what is going on with the processing of the web forms.)
The Problem of State
We have seen the following points
· The web follows a client server mode of operation
· The ASPX page is rendered on the server and sent to the browser as HTML
· The page is rendered in two modes
o PostBack = False
(The first time the page is requested, Load – Unload events)
o PostBack = True
(Subsequent renderings of the page, Load – Other Events – Unload)
The thing to note in all of this messing about is that the settings of the page are not automatically remembered on each round trip.
The web is referred to as stateless.
So how is this problem addressed?